What makes a charm good?

[Tom Haddon]

On 14/09/12 13:52, Jorge O. Castro wrote:
> On Fri, Sep 14, 2012 at 4:25 AM, Tom Haddon <tom.haddon at canonical.com> wrote:
>> "Charms run as root on the target instance, which means if you can
>> script it to grab your source tarball and install it, you can totally do
>> that. If your software isn't in the Ubuntu archive then this is the way
>> to go, you should only need to worry about verifying the source of the
>> binary."
> 
> Ok I've redone this bit to be less preachy and added some bullets to
> be more clear on some options.
> 
> As far as having charms pull from an external source ... that's been
> an interesting source of strong opinions, but we've not really come to
> a conclusion on best practice on that other than putting them behind
> config options and let the charm author and devop decide how best to
> do that.

Yeah, I understand this is very much an evolving document. I just think
we need to be careful about encouraging people to work around packaging
issues. I think it'd be nice if we encouraged people to try and get the
software packaged, and get it into a repo that the charm then references
and that grabbing from upstream would be a last (and hopefully short
term) resort.

We've been thinking about this in the WebOps team, as it's very possible
that software we need for a specific charm won't be in the main Ubuntu
archives, and we often get requests to backport packages to the LTS
releases we support from development releases to support production
services. As much as we can tell at the moment, the best way to support
this is for the charm to allow a "custom_repo" option so that you can
say "pull in any packages from this repo" and then you go ahead and
install packages normally.

> I'm of the opinion that organizations that operate like this will
> likely not use the charm store anyway but will instead mirror parts of
> the charm store that they want locally, and then modify/update charms
> based on their own criteria, pull from their own internal vetted
> sources, and so on.

That's possible, but kind of admits that many people will diverge from
upstream charms, which isn't going to be a great solution in the long
run, I think. If you allow the "custom_repo" option as above, and allow
users to override that with the location of their own repo, I think you
avoid the problem mostly.

>> To me this isn't "flexible", this is "easy to use". "Flexible" would be
>> "exposes every possible configuration option so you can customise the
>> service to your exact requirements".
> 
> Do you think we should just encourage people to expose every config?
> That's doable, basically pass any config flag from the juju command
> right to the service. We can make that a recommendation.

I'm not sure about what to recommend here. I know that in our (the
WebOps group) charm writing we've been taking the approach of only
exposing the config options that we actually use (i.e. set differently
from the package defaults) in production. Where possible we're also
trying to offer auto-tuning, and having specific config options be
available if you don't want to go the auto-tuning route. Time will tell
if it's better to just expose everything.