How to deal with optional/unsupported keys?

[PietroPasotti]

Suppose I have two charms providing the ingress interface (interoperable).
One of them adds a new feature (say, TLS), to the ingress library and make it optional so that it will still support integrating with providers or requirers using earlier versions.

• How does the ingress interface now look like?
• What should the provider do when it sees a key it doesn't recognise? Block, silently ignore (risky with TLS...), or..?
• How do we spec this in this repo? "The provider is expected to provide TLS, but only if it supports it...?"
• What does the tester do? Is it 'happy' if the charm under test does not support the optional feature, or if it does strict validation and blocks when it sees the unknown key?

[simskij]

• How does the ingress interface now look like?

It would include the new (optional) keys for this. It would likely also include a flag in the provider databag saying "tls": true or similar.

• What should the provider do when it sees a key it doesn't recognise? Block, silently ignore (risky with TLS...), or..?

Ignore. However, the requirer would check for "tls": true in the response and block if it is not present.

• How do we spec this in this repo? "The provider is expected to provide TLS, but only if it supports it...?"

• The provider is expected to tell the requirer if the connection is secured using TLS or not.

in combination with two requirer expectations:

• The requirer is expected to communicate whether it expects TLS.
• The requirer is expected to refuse using an ingress lacking TLS if it is expecting it.

• What does the tester do? Is it 'happy' if the charm under test does not support the optional feature, or if it does strict validation and blocks when it sees the unknown key?

If this is an optional feature, it would be happy without it.