A beginner's adventure in Charm authoring

[Stuart Bishop]

On 4 September 2014 14:26, John Meinel <john at arbash-meinel.com> wrote:

>> Deploying a local charm is needlessly complex. Why do I need to create a
>> special directory structure, move my code under there, set --repository and
>> write local:<foo> and even then it has to go scanning through the directory,
>> looking for a charm with the right name in the metadata.yaml.  Why can't I
>> just say "deploy the charm in <this> directory"? e.g.   juju deploy
>> --local=<path>  Bam, done.
>
> At the very least we need to know what OS Series the charm is targeting.
>
> Which is currently only inferred from the path. I don't particularly like
> it, and I think the code that searches your whole repository and then picks
> the "best" one is bad, as it confuses people far more often than it is
> helpful.
> (If you have $REPO, and have $REPO/precise/charm and
> $REPO/precise/charm-backup but the 'revision' number in charm-backup is
> higher for whatever reason, juju deploy --repository=$REPO charm will
> actually deploy charm-backup)
>
> I'm certainly for "deploy the charm in this directory" as long as we can
> sort out a good way to determine the series.

The only sane way I see is for the charm to declare what series it
supports, probably in its metadata.yaml. In practice, we regularly
deploy branches targetted to precise to trusty and vice versa because
one branch supports both series and the branch on the other series
just an unmaintained atavism. I think forcing a 1:1 mapping between a
branch and a series is not useful to anyone, and the series component
in the charm URL just causes confusion.

Well... it might have one use. Versioning. It gives you a way of
breaking backwards compatibility with old versions of your charm. So
for instance, the major rewrite of the Cassandra charm won't be able
to upgrade-charm from the old version, so instead we hope to push it
to trusty and leave the precise branch to rot in peace. Not ideal, but
the only way of doing charm versioning at the moment.

In fact, now I think about it the release in the URL *is* the major
version (series) of the charm. It is just unfortunate that the
possible charm versions have been hardwired to the Ubuntu releases,
because the Ubuntu release is much less important than the release of
the software I'm charming.

I think we could decouple this, allowing arbitrary supported series in
a charm and gaining a sane charm versioning concept, by redoing the
Launchpad model and changing charms from being sourcepackages on a
distribution called 'charms' to instead being products with product
series. I could then switch product-series whenever my charm chances
the set of supported Ubuntu releases, or when upgrade-charm stops
working without manual steps.


-- 
Stuart Bishop <stuart.bishop at canonical.com>