Juju 2.0 and local charm deployment

[Gabriel Samfira]

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 <ian.booth at canonical.com<mailto:ian.booth at 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 at lists.ubuntu.com<mailto:Juju-dev at lists.ubuntu.com>
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev


--
Juju-dev mailing list
Juju-dev at lists.ubuntu.com<mailto:Juju-dev at lists.ubuntu.com>
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160304/3df8040b/attachment-0001.html>