On 4 September 2014 14:26, John Meinel <j...@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.bis...@canonical.com> -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
