<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div>Hi Marco,</div>
<div><br>
</div>
<div>What happens if I have a multi series/OS bundle:</div>
<div><br>
</div>
<div>```</div>
<div>series: trusty</div>
<div>services:</div>
<div> nova-compute:</div>
<div> charm: ./nova-compute</div>
<div> num_units: 2</div>
<div> nova-hyperv:</div>
<div> series: win2012hvr2 # is there a series override per charm ?</div>
<div> charm: ./nova-hyperv # this can run on win2012, win2012hvr2, win2012hv, win2016, win2016nano</div>
<div> num_uints: 2</div>
<div><br>
</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Gabriel</div>
<div><br>
</div>
<div><br>
</div>
<div>On Vi, 2016-03-04 at 12:51 +0000, Marco Ceppi wrote:</div>
<blockquote type="cite">
<div dir="ltr">Hi Ian,
<div><br>
</div>
<div>We were just having a discussion about this for charm development. We currently recommend the following setup for layered charms:</div>
<div><br>
</div>
<div>LAYER_PATH=$JUJU_REPOSITORY/layers</div>
<div>INTERFACE_PATH=$JUJU_REPOSITORY/interfaces</div>
<div><br>
</div>
<div>So you typically get</div>
<div><br>
</div>
<div>
<div>charms</div>
<div>├── deps</div>
<div>│ ├── interface</div>
<div>│ └── layer</div>
<div>├── interfaces</div>
<div>│ └── mongodb</div>
<div>├── layers</div>
<div>│ ├── mongodb</div>
<div>│ └── vpe-router</div>
<div>└── trusty</div>
<div> └── vpe-router</div>
</div>
<div><br>
</div>
<div>We opened this <a href="https://github.com/juju/charm-tools/issues/115">https://github.com/juju/charm-tools/issues/115</a> to discuss moving the built charm artifact outside of the series directory but we're not sure where.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>I'm a +1</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>```</div>
<div>series: trusty<br>
</div>
<div>services:</div>
<div> nova-compute:</div>
<div> charm: ./nova-compute</div>
<div> num_units: 2</div>
<div>```</div>
<div><br>
</div>
<div>Marco<br>
<br>
<div class="gmail_quote">
<div dir="ltr">On Fri, Mar 4, 2016 at 12:55 AM Ian Booth <<a href="mailto:ian.booth@canonical.com">ian.booth@canonical.com</a>> wrote:<br>
</div>
<blockquote type="cite">Hi folks<br>
<br>
TL;DR we want to remove support for old style local charm repositories in Juju 2.0<br>
<br>
Hopefully everyone is aware that Juju 2.0 and the charm store will support<br>
multi-series charms. To recap, a multi-series charm is one which can declare<br>
that it supports more than just the one series; you no longer need to have a<br>
separate copy of the charm for precise vs trusty vs xenial. Note that all series<br>
must be for the same OS so you'll still need separate charm sources for Windows<br>
vs Ubuntu vs Centos.<br>
<br>
Here's a link to the release notes<br>
<a href="https://jujucharms.com/docs/devel/temp-release-notes#multi-series-charms" rel="noreferrer" target="_blank">https://jujucharms.com/docs/devel/temp-release-notes#multi-series-charms</a><br>
<br>
Juju 2.0 will also support deploying bundles natively<br>
<a href="https://jujucharms.com/docs/devel/temp-release-notes#native-support-for-charm-bundles" rel="noreferrer" target="_blank">https://jujucharms.com/docs/devel/temp-release-notes#native-support-for-charm-bundles</a><br>
<br>
So, with multi-series charm support, local charm deployment is now also a lot<br>
easier. Back in Juju 1.x, to deploy local charms you needed to set up a<br>
so-called charm repository, with a proscribed directory layout. The directory<br>
layout has one directory per series.<br>
<br>
_ mycharms<br>
|_precise<br>
|_mysql<br>
|_trusty<br>
|_mysql<br>
|_bundle<br>
|_openstack<br>
<br>
You deployed using a local URL syntax:<br>
<br>
$ juju deploy --repository ~/mycharms local:trusty/mysql<br>
<br>
$ juju deploy --repository ~/mycharms local:bundle/openstack<br>
<br>
The above structure was fine for when charms were duplicated for each series.<br>
But one of the limitations is that you can't easily git checkout mycharm and<br>
deploy straight from the vcs source on disk.<br>
<br>
Juju 2.0 supports deploying charms and bundles straight from any directory,<br>
including where you've checked out your launchpad/github charm source.<br>
<br>
$ juju deploy ~/mygithubstuff/mysql<br>
<br>
$ juju deploy ~/mygithubstuff/openstack/bundle.yaml<br>
<br>
So the above combined with the consolidation of charms for many series into the<br>
one source tree means that the old local repo support is not needed.<br>
<br>
Will anyone complain if we drop local repos in Juju 2.0? Is there a use case<br>
where it's absolutely required to retain this?<br>
<br>
<br>
<br>
<br>
<br>
<br>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">
https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
<br>
</blockquote>
</div>
</div>
</div>
<pre>--
Juju-dev mailing list
<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a>
</pre>
</blockquote>
</body>
</html>