juju-core

Bug #1545686
Comment #6

Comment 6 for bug 1545686

Revision history for this message

Ryan Beisner (1chb1n) wrote on 2016-03-22:

It is great that this is handled by the charm store, but this development of charms is still blocked in that the trunk charm code may possess series metadata, and the 1.25.x client will not deploy that.

For a simple example, let's take the "ubuntu" charm, which deploys nothing, does nothing, and is expected to be functional on all currently-supported releases of Ubuntu. It is a quick and handy charm for validating tooling, and removes the OpenStack complexity from the mix.

To-date, we've synthesized in effect, a multi-series charm. Now, I want to add series metadata so that the charm store will parse and ingest the charms into the appropriate series spaces, but I will only be able to do so if I fork the charm and maintain 1.x and 2.x versions of the charm.

Here's why:

Take the ubuntu charm, add series metadata:
=== modified file 'metadata.yaml'
--- metadata.yaml 2015-04-29 15:02:11 +0000
+++ metadata.yaml 2016-03-22 15:58:49 +0000
@@ -5,3 +5,8 @@
This simply deploys Ubuntu Server.
tags:
- misc
+series:
+ - precise
+ - trusty
+ - wily
+ - xenial

## Fetch and deploy
- This works today without series metadata, but fails when series metadata exists.
- This example is Trusty, but P|T|W|X can be substituted and should be expected to work as it does today.

cd /tmp
mkdir trusty
bzr branch lp:~1chb1n/charms/trusty/ubuntu/add-series-metadata trusty/ubuntu
juju bootstrap
juju deploy --repository=. local:trusty/ubuntu

WARNING failed to load charm at "/home/ubuntu/temp/trusty/ubuntu": metadata: series: expected string, got []interface {}([]interface {}{"precise", "trusty", "wily", "xenial"})
ERROR charm not found in "/home/ubuntu/temp": local:trusty/ubuntu

## To summarize:
This simplified example is what we are faced with in the OpenStack charms: either (a) fork the charms; or (b) defer inclusion of a feature.

In my opinion, 1.25.x should gracefully ignore select metadata on which it cannot act, such as: series, min-juju-version, extra-bindings, and/or potentially other similar blockers. If it does not, we are in effect forcing the forking of all charms which wish to use any of these features.

For a simple example, let's take the "ubuntu" charm, which deploys nothing, does nothing, and is expected to be functional on all currently-supported releases of Ubuntu.  It is a quick and handy charm for validating tooling, and removes the OpenStack complexity from the mix.

To-date, we've synthesized in effect, a multi-series charm.  Now, I want to add series metadata so that the charm store will parse and ingest the charms into the appropriate series spaces, but I will only be able to do so if I fork the charm and maintain 1.x and 2.x versions of the charm.

Here's why:

Take the ubuntu charm, add series metadata:
=== modified file 'metadata.yaml'
--- metadata.yaml       2015-04-29 15:02:11 +0000
+++ metadata.yaml       2016-03-22 15:58:49 +0000
@@ -5,3 +5,8 @@
   This simply deploys Ubuntu Server.
 tags:
      - misc
+series:
+  - precise
+  - trusty
+  - wily
+  - xenial

## Fetch and deploy
 - This works today without series metadata, but fails when series metadata exists.
 - This example is Trusty, but P|T|W|X can be substituted and should be expected to work as it does today.

cd /tmp
mkdir trusty
bzr branch lp:~1chb1n/charms/trusty/ubuntu/add-series-metadata  trusty/ubuntu
juju bootstrap
juju deploy --repository=. local:trusty/ubuntu

## To summarize:
This simplified example is what we are faced with in the OpenStack charms:  either (a) fork the charms;  or (b) defer inclusion of a feature.

In my opinion, 1.25.x should gracefully ignore select metadata on which it cannot act, such as:  series, min-juju-version, extra-bindings, and/or potentially other similar blockers.  If it does not, we are in effect forcing the forking of all charms which wish to use any of these features.