Hi folks
It’s an anti-pattern to require config of a charm which describes a connection to another service. Connections to services are much better modelled as a relation.
It’s quite common for services to want to know where they should pull Docker images. What I see at the moment is some ugly config on these charms for the registry to be used. It would be much nicer if these charms instead had an integration endpoint that could be related to a registry, or multiple registries, and that you would specify the registry with that relation in the model.
Now, if the registry is not deployed with Juju, how would a charm relate to it?
The answer is to have a proxy charm, which has the config of a registry and which can be related just like a registry. Instead of driving the service natively, the proxy charm just represents the service in the application graph. It can hand out the appropriate details, just like an actual registry charm can hand out details, so it looks just like a native registry.
I could deploy the image-registry proxy charm and configure that with my private registry details, then relate all the different applications that need registry details to that image-registry charm. The advantage of this is that I can update the config of the image-registry once, and it can tell every related application about the update automatically. This is much better than me having to go and update the config on each application which is using that registry.
The work required is to think through the ideal elements of an ‘image-registry’ relation. What does the application need to know in order to talk to the registry? What different scenarios are there for username/password handling? For example, do I want to have an image-registry which represents a single-user perspective (I configure image-registry with a specific set of credentials and then when I relate to it the application it always uses those credentials)?
The idea of proxy charms is really powerful, especially in environments where there is a lot of existing software that isn’t going to get charmed and redeployed. Proxy charms let us deploy new stuff and relate to something that is a twin of the underlying deployed infrastructure. What else would be really useful to have as a proxy charm? LDAP?