Hi Marco,
What happens if I have a multi series/OS bundle:
```
series: trusty
services:
nova-compute:
charm: ./nova-compute
num_units: 2
nova-hyperv:
series: win2012hvr2 # is there a series override per charm ?
charm: ./nova-hyperv # this can run on win2012, win2012hvr2, win2012hv,
win2016, win2016nano
num_uints: 2
Cheers,
Gabriel
On Vi, 2016-03-04 at 12:51 +0000, Marco Ceppi wrote:
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
<[email protected]<mailto:[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?
--
Juju-dev mailing list
[email protected]<mailto:[email protected]>
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
--
Juju-dev mailing list
[email protected]<mailto:[email protected]>
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
--
Juju-dev mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
