juju deploy --edge bundle doesn't cope with charm pinning

@David Britton,
I wonder if this is related to Cory's findings in bug # 1627127...

Just for reference - are there resources in the charm?
It may be an issue on charm store side more than Juju...

Don't think it's related. And no, no resources in the haproxy charm that I know of.

Just to summarize, deploying an "--channel=edge" is asking to deploy some
charms which are *not* in channel=edge.

That sounds a bit like charmstore not supporting the
edge/beta/candidate/stable syntax where if you ask for "edge" but only
"stable" exists, then you should be given "beta".

On Thu, Mar 30, 2017 at 6:36 AM, Anastasia <email address hidden>
wrote:

> ** Tags added: deploy
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1677404
>
> Title:
> juju deploy --edge bundle doesn't cope with charm pinning
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1677404/+subscriptions
>

Should there be fall backs though?

In other words, charm foo in bundle from --edge, where foo is only in stable, then it should fallback to use the foo from stable, yes?

Taking a step back -- as a user, the most expected thing to me by running this command was to download the bundle in the edge channel, as is, and deploy it, as is:

  juju deploy --channel=edge <bundle>

Reasoning:

* As a developer, it's how I tested and crafted the bundle, as is, I then uploaded it to the edge channel and expected my users to be able to use it.

* As a developer, if I 'charm pull --channel=edge <bundle>', I get that bundle, not that bundle with all charm specs subbed out for their edge versions.

* As an operator, I have no clear way to determine what will happen if it applies --channel=edge to each charm inside the bundle.

The bundle is a tested qualified unit by itself, much as the charm is. To take it a step further, you wouldn't expect:

  juju deploy --channel=edge <charm>

to get the edge version of the charm *and* the edge version of all snaps inside of it, would you?

David Britton (davidpbritton),

From https://jujucharms.com/docs/2.1/charms-deploying, under "Channels" section where "Charm upgrades" are described, the behavior you observe seem to be expected...

"If a channel revision is older, downgrade the deployed charm to that revision"

Hi Anastasia,

I'm sorry, I don't see how that is relevant to what I said. I was not upgrading anything. This was a fresh deploy.

BTW, that page is a good starting point. It describes nothing about what the behavior should be when specifying a channel for a bundle. Bundle is mentioned just twice in passing on that page.

I think this must be fixed at three levels:

1. I agree with people believing that deploying a bundle from a channel does not mean that all charms included in that bundle must use the same channel. I don't want a candidate bundle to behave differently from the same bundle when promoted to be the stable channel. It must deploy the same charms IMHO. This fix must be made in the juju client, which uses the a csclient on which WithChannel is initially called when resolving the bundle and then never unset. With this change this bug could be technically considered addressed.

2. But we also need a way for bundles to specify the channel used for each individual charm, and possibly for all charms (similar to the series field present globally in BundleData and also specifically to each application in the ApplicationSpec. This is to be done in the charm package and propagated via bundlechanges to the juju client and to other clients as well, like the Juju GUI.

3. We could enable the missing bit of automatically fall through to the next stabler channel, maybe with some kind of warning/notification. And this is the change that must be implemented in the charm store.

What do you think?

My preference would be the following:

A) charm: "cs:mysql-20"

revision specified for charm in bundle, use that and only that.

B) channel: "beta"

This is future syntax in the bundle, like in frankban's comment #8, option 2. If combined with a revision number on the charm that doesn't match the channel specified in the bundle, a warning or an error is probably expected.

C) charm: "cs:mysql"

The revision is not specified for charm in bundle, then:

C.1) try from the requested channel on the juju command line, "stable" if not specified
C.2) try from successive "more stable" channels (edge -> beta -> stable)
C.3) fail

Can we get a status update on this? There still seems to be no way to refer to charms in different channels in bundles.

The team is currently working on some bundle improvements and this is on the docket for part of these changes this cycle.

A fix for this bug is included in the bundle improvement changes (bundles supporting per-charm channel attributes) that are expected to land on develop via https://github.com/juju/juju/pull/10480