On 4 March 2016 at 05:55, Ian Booth <[email protected]> wrote: > Hi folks > > TL;DR we want to remove support for old style local charm repositories in > Juju 2.0 > > Hopefully everyone is aware that Juju 2.0 and the charm store will support > multi-series charms. To recap, a multi-series charm is one which can declare > that it supports more than just the one series; you no longer need to have a > separate copy of the charm for precise vs trusty vs xenial. Note that all > series > must be for the same OS so you'll still need separate charm sources for > Windows > vs Ubuntu vs Centos. > > Here's a link to the release notes > https://jujucharms.com/docs/devel/temp-release-notes#multi-series-charms > > Juju 2.0 will also support deploying bundles natively > https://jujucharms.com/docs/devel/temp-release-notes#native-support-for-charm-bundles > > So, with multi-series charm support, local charm deployment is now also a lot > easier. Back in Juju 1.x, to deploy local charms you needed to set up a > so-called charm repository, with a proscribed directory layout. The directory > layout has one directory per series. > > _ mycharms > |_precise > |_mysql > |_trusty > |_mysql > |_bundle > |_openstack > > You deployed using a local URL syntax: > > $ juju deploy --repository ~/mycharms local:trusty/mysql > > $ juju deploy --repository ~/mycharms local:bundle/openstack > > The above structure was fine for when charms were duplicated for each series. > But one of the limitations is that you can't easily git checkout mycharm and > deploy straight from the vcs source on disk. > > Juju 2.0 supports deploying charms and bundles straight from any directory, > including where you've checked out your launchpad/github charm source. > > $ juju deploy ~/mygithubstuff/mysql > > $ juju deploy ~/mygithubstuff/openstack/bundle.yaml > > So the above combined with the consolidation of charms for many series into > the > one source tree means that the old local repo support is not needed. > > Will anyone complain if we drop local repos in Juju 2.0? Is there a use case > where it's absolutely required to retain this?
Does this mean it won't be possible to deploy old single-series charms with Juju without modifying metadata.yaml to add the supported series? -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
