Multi-series not backwards compatible

[Stuart Bishop]

Per Juju 2.0 release notes, metadata.yaml can now list supported series as a list:

series:
       - precise
       - trusty
       - wily

This makes Juju 1.25 explode, making it impossible to use this feature without making the charm Juju 2.0 specific.

Should basic support for the list be backported to 1.25, or a different key name used?

Not being able to list multiple series may make trouble for charm store uploads.

[Richard Harding (rharding)]

This is a known bug in the charmstore. It's being updated so that it provides a backward compatible charm to previous versions of Juju. I'll check with the team where that is.

[Ian Booth (wallyworld)]

It's more than just the charm store. Local multi-series charms also have the issue.
The series metadata attribute which used to be a string in old charms is ignored by Juju 1.25. The best approach is simply adjust the parsing in 1.25 to ignore this attribute.

[Uros Jovanovic (uros-jovanovic)]

Backward compatibility for /v4 API endpoints in charm store has landed. Ian, check PRs https://github.com/juju/charmstore/pull/529 to 534 if you're interested.

This fix will be available with next charm store deploy (for now ETA end of February).

[Gui Bot (rick-harding+guibot)]

Uros can you confirm this is out and 100% please?

[Uros Jovanovic (uros-jovanovic)]

Yes, it is out and multi series charms uploaded with V5 can be used with old clients using V4.

[Ryan Beisner (1chb1n)]

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.

[Aaron Bentley (abentley)]

I don't think min-juju-version should be ignored. If it is present, the charm has declared that it is incompatible with certain juju versions, and those versions should not attempt to run it. If the jujus cannot determine whether they are compatible, it is best to assume they are incompatible. There may be some fields which are optional and can safely be ignored, but I don't think min-juju-version is one of them.

[Nate Finch (natefinch)]

FWIW,the way that Juju currently is coded, *any* unrecognized metadata in metadata.yml will be ignored. The reason series is special is because we used to have a series value, which was expected to be a string, not a list, and so that is what blows up on 1.25. min-juju-version is simply unrecognized, and so 1.25 ignores it.

Any new metadata we add will be ignored by older versions unless we specifically add code to recognize it.

[Cheryl Jennings (cherylj)]

So, would a workable solution for 1.25 be for juju deploy to ignore "series" if it is a list?

[Stuart Bishop (stub)]

@cherylj Yes, ignoring "series" if it is a list seems to be the best approach.

[Cheryl Jennings (cherylj)]

Bug #1563607 is being used to track the changes in juju-core/1.25 to handle multi series charms.