Bundle file with a series should override what the charm says it supports

[Bryan Quigley]

You can --force override a specific charm, but not a whole bundle. This makes it harder to test bundles for the series in development (zesty in this case).

Example output today:
$ juju deploy zestybundle.yaml
ERROR cannot deploy bundle: series "zesty" not supported by charm, supported series are: xenial,trusty,yakkety

If someone goes out of their way to put the development release in a bundle, should we just respect it? - maybe with a warning?

Juju version 2.1.1

[Anastasia (anastasia-macmood)]

In general, I think we'd create more problems by allowing bundles to specify series that charms explicitly do not support.

Can we have a look at the bundle specification you are trying out? How are you specifying that your bundle uses development release of a charm?

[Bryan Quigley (bryanquigley)]

@Anastasia
It's a full openstack deployment, I'm just using https://code.launchpad.net/~ost-maintainers/openstack-charm-testing/trunk
Specifically I'm telling bundles/2.x/gen-bundle.sh to generate one for zesty.

My primary goal was to test changes on Zesty and how they affect an openstack deployment. The charm developers rightfully don't want to enable Zesty in the charms until it releases - but say it should work fine. I just want to force it to try.

I'm not pushing for the development release of the charm at all, just of Ubuntu series.

[John A Meinel (jameinel)]

Is this for some of the entries in the bundle, all of them? What granularity of overrides are you looking for?

We've talked about enabling some sort of "start with the bundle, and apply this specific mutation to the bundle for this deployment". That would potentially apply to lots of aspects of a bundle. (bundle specifies network space names, that need to be customized for this provider, or machine ids, etc).

Mostly the use case today is that you can download the bundle definition, and rewrite specific parts of it. Just specifying series seems a bit limited, as some of the charms may not have support for that series (certainly in the general case), but providing customized overrides for everything in the file also starts to feel like you're back in 'well you *can* just edit the file'. It would be good to have a feel for multiple use cases and make sure we're covering a wider expanse of them than just a 'series' override.

[Bryan Quigley (bryanquigley)]

@jameinel My bundle file has the exact series I want it to deploy on. It's the charms that don't list support for that specific series that I want to override.

Basically if we add an override flag it would just trust the bundle is correct by not checking compatibility of any of the charms themselves.

[Launchpad Janitor (janitor)]

[Expired for juju because there has been no activity for 60 days.]

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 5 years, so we're marking it Expired. If you believe this is incorrect, please update the status.