Do you use public charms as-is, or do you typically apply customisation and deploy them as private charms?

I’m interested in understanding about people’s workflows. The current instructions on our website are “here are our charms, use juju deploy to start”.

There comes a stage though where I think most people begin to make tweaks and adjustments. Is that correct? We haven’t catered for power users much on the Juju website and our docs. Perhaps we should add some more content for that audience?

By the way, @gomboli, @barry-mcgee and others are busy developing a new Juju website. It’s an open source project and you’re welcome to contribute.


So far, a mix. Both some defaults, but for most charms - customizations are needed.

Missing a way to promote charms, get a quality indicator or rate them in the charm store.


We have had some instances where modifying an upstream charm has been handy/necessary, either for custom functionality or pending upstream fixes where we didn’t want to track edge in production.

I think if you look at the community results in the charm store or on GitHub for some of the more popular charms, that it shows there are a lot of people publishing the same charms in their private namespace. Of course I am not sure how many actually have changed much (though that would be interesting in a way of who-forked-who sense).

For us a better CI/UX story for the charm store in combination of the comments of @erik-lonroth above about promoting/testing/quality/rating/ranking which most of the other popular cfg mgmt tools have. I hope these things will be included in the new store.


While customizing upstream charms is sometimes necessary, our team has the moto “Do not leave the upstream path and put effort on maintaining non-existing things upstream or the glue in between”. What we would love to see in charms is a straight forward way to add as a config option our own configuration snippets like the extraconfig option in nagios charm or the config-flags option in nova-cloud-controller charm.

Also, I totally agree with @erik-lonroth for a quality/popularity indication in charm store and I would add the necessity/ability to track “forks” of charms in a github way so as to be able easily to track changes and compare charms.


I started back in '18 sort of by accident, and when I juju deployed the first time it “just worked” … it was an ELK stack. I then saw I just had to edit a config file and it began to flow to the Kibana page!

This was a huge revelation, and I simply made notes for others in a markdown file… explaining how to juju deploy, edit the config, and move on…


Delighted to hear that everything went smoothly for you and extending your system was as simple as advertised.

If you encounter any issues, please let us know :slight_smile: