Hi Ian,
We were just having a discussion about this for charm development. We
currently recommend the following setup for layered charms:
LAYER_PATH=$JUJU_REPOSITORY/layers
INTERFACE_PATH=$JUJU_REPOSITORY/interfaces
So you typically get
charms
├── deps
│ ├── interface
│ └── layer
├── interfaces
│ └── mongodb
├── layers
│ ├── mongodb
│ └── vpe-router
└── trusty
└── vpe-router
We opened this https://github.com/juju/charm-tools/issues/115 to discuss
moving the built charm artifact outside of the series directory but we're
not sure where.
I had an entire counter point written as to why we should keep local: but I
just realized how easy it would be to type `juju deploy
$JUJU_REPOSITORY/build/charm_name`. This is way more explicit than a
local:charm_name with some magic environment variable lookup.
I'm a +1
How will bundles work which reference local charms? Will this work as
expected where nova-compute is a directory at the same level as a bundle
file?
```
series: trusty
services:
nova-compute:
charm: ./nova-compute
num_units: 2
```
Marco
On Fri, Mar 4, 2016 at 12:55 AM Ian Booth <ian.bo...@canonical.com> 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?
>
>
>
>
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
