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?
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.
