CAAS charms installing resources and secrets



I’ve been looking at CAAS charming support and one of the first use cases I like to understand is a typical ingress with a reverse-proxy in front of a service.

If I have, for example, a charmed service it will be installed in the model namespace. I need an ingress charm, nginx-ingress for example that I can relate it to to forward traffic to my service.

Different ingress controllers operate differently and my service really shouldn’t know anything about that. It should just relate to the charm that handles it. Looking at the nginx-service I need to install an Ingress Resource in the same name space as the charm requesting it.

  1. Is there already an example or production ready ingress charm to handle this common use case?
  2. Is there a way for CAAS charms to install custom resources like this Ingress resource which seems a common activity for K8s services.
  3. Is there a way for CAAS charms to create and access secrets? For example, if this ingress charm is using TLS it will need to set a secret and then provide that name in the Resource it creates.

I’ve looked through the examples, and I’m following the various service types I can declare but I was expecting to see functions to handle secretes, resources, etc similar to the set_pod_spec command and I’m not finding them. I’m not sure if it’s not yet implemented or if there is a helper library (like charmhelpers) that I’m missing. A lot of K8s configuration requires managing secretes, resources, and other objects that I would like for the charm to handle.



Pinging @wallyworld, @hpidcock, @kelvin.liu


Support for k8s charms creating secrets is in development and should land in the Juju 2.7 edge snap within the next week.

Support for custom resource definitions exists already

Support for custom resources is under development. Hopefully it will land in the next few weeks.



I’ve read through that post before and even on this pass it took me a while to find it. I didn’t even catch that there was a custom resource at the bottom of the example podspec. I’ll give this a go you might have secretes implemented before I’m ready to try it out anyway.

Just some early user feedback, even being familiar with charms already I didn’t expect for a ‘pod spec’ to contain custom resource definitions. If that’s going to remain this way, maybe pod_spec isn’t the best name for it?


We wanted a single word name for the YAML that the charms handed over to Juju that best represented the content. “PodSpec” was the best we could come up with as that best describes the majority of the context; naming stuff is hard :slight_smile:
Having said that, we’re in the middle of an iteration to the YAML handling which splits out the k8s specific stuff that we don’t (yet) model , like CustomResourceDefinitions, to a separate YAML file. That work should land in the 2.7 edge snap next week.


Makes since. Splitting non-pod yaml seems like a good idea. I’m probably well ahead of myself here but taking the above example there’s also a situation where you would need to specify the namespace to install the objects in.

As I understand it today, all charms are installed in a name space based on the model name. So with the example I was describing originally, if we had an Ingress charm and a Server charm that related to it the Ingress charm would need to install some Ingress objects when the relation is made. Those objects need to be in the namespace of the Server charm (not the Ingress charm). That means the custom objects are only valid if the Ingress charm is in the same model as the Server charm. If however, we had several models each hosting some different workloads and used a CMR to relate to the Ingress provider the Ingress provider would need to install those objects in the namespace for the Server model. This would mean an Ingress charm would need to install different objects in different name spaces, so it would need to support specifying the namespace for each object.

At least, I think that’s how it would play out today. Perhaps juju shouldn’t force an assumption about namespaces but default to the model name if not otherwise provided? This would be a lot cleaner if objects were not part of the pod spec, installing objects in different name spaces in the same yaml spec would probably be confusing as well.

Sounds like I need to find time to charm nginx-ingress so I can really understand if this plays out like I think it does.