On Sun, Mar 20, 2016 at 3:21 PM, roger peppe <roger.pe...@canonical.com> wrote:
> If the released Juju 2.0 uses v5 of the charmstore API (which it will > soon hopefully anyway when my branch to support the new publishing > model lands), then there's a straightforward solution here, I think: > change v4 of the charmstore API to refuse to serve min-juju-version > charm archives to clients. Since the only v4-using clients should be > old juju versions, this could provide a reasonably cheap to implement > and straightforward solution to the problem. > To re-confirm: Would that be *"don't serve up a charm for 1.25.x clients when min-juju-verison is defined at all"* -or- *"cleverly interpret the min-juju-version server-side and selectively refuse to deliver the charm when client version is less than the min version?"* If the former, OpenStack charms may have to defer utilization of min-juju-version until such time as 1.x is fully deprecated (or fork 27+ charms and maintain two separate sets of charms, which is naturally not our desire). If the latter, brilliant! :) Rationale and use case: A single Keystone charm supports deployment (thereby enabling continued CI & testing) of Precise, Trusty, Wily, Xenial and onward. It is planned to have a min-juju-version value of 1.25.x. That charm will support >= 1.25.x, including 2.x, and is slated to release with 16.04. This is representative of all of the OpenStack charms. Note: I've raised a feature request bug against charm tools for min-juju-version proof recognition. We'll need to have that in place before we can add min-juju-version metadata into the OpenStack charms as our CI gate proofs every charm change request. Thanks again! > > On 18 March 2016 at 09:49, Uros Jovanovic <uros.jovano...@canonical.com> > wrote: > > We’re looking in how we can identify 1.x Juju client/server in such a way > > that at the same time we don’t block access to charms for other clients > > using our HTTP API. > > > > > > On Fri, Mar 18, 2016 at 9:34 AM, Mark Shuttleworth <m...@ubuntu.com> > wrote: > >> > >> On 17/03/16 22:34, Nate Finch wrote: > >> > Yes, it'll be ignored, and the charm will be deployed normally. > >> > > >> > On Thu, Mar 17, 2016 at 3:29 PM Ryan Beisner > >> > <ryan.beis...@canonical.com> > >> > wrote: > >> > > >> >> This is awesome. What will happen if a charm possesses the flag in > >> >> metadata.yaml and is deployed with 1.25.x? Will it gracefully ignore > >> >> it? > >> >> > >> > >> I wonder if there is a clean way for us to have Juju 1.x reject the > >> charm very early in the process, giving an error that would essentially > >> amount to the "not understood"? Or if we could have the charm store > >> refuse to serve up the charm to a 1.x Juju client / server? > >> > >> Mark > >> > >> -- > >> Juju mailing list > >> Juju@lists.ubuntu.com > >> Modify settings or unsubscribe at: > >> https://lists.ubuntu.com/mailman/listinfo/juju > > > > > > > > -- > > Juju mailing list > > Juju@lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/juju > > > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
