I've updated the issue against charm-tools that Ryan opened to clarify that proof should do proper version catching as well https://github.com/juju/charm-tools/issues/141
On Mon, Mar 21, 2016 at 10:28 AM Rick Harding <[email protected]> wrote: > The thought is that we'll update the charmstore where the store will deny > the charms to the 1.25 clients. The earliest version we'd accept in that > field will be 2.0, and if the charm declares it needs 2.0, then the store > will not deliver it. > > I've copied in Marco to make sure that the charm proof tool is updated to > help with this. It should validate folks don't have the field if the > min-juju-version is < 2.0. > > On Mon, Mar 21, 2016 at 10:26 AM Ryan Beisner <[email protected]> > wrote: > >> On Mon, Mar 21, 2016 at 9:18 AM, Rick Harding <[email protected] >> > wrote: >> >>> Checked with the team and older clients don't identify themselves to the >>> charmstore so we can't tell 1.24 from 1.25. So yes, we should only take >>> advantage of this with 2.0 and greater. I'll check ot make sure we're able >>> to do this type of thing going forward though. It's something that would >>> have been nicer if we had that version info all the time. >>> >> >> Thanks, Rick. Indeed that will be useful going forward. >> >> So, will 1.25.x clients be able to deploy charms which possess >> min-juju-version and gracefully ignore that metadata? Or, will they be >> refused a charm by the store because the store knows the client version is >> less than 2.0? >> >> >> >>> >>> >>> On Mon, Mar 21, 2016 at 10:08 AM Rick Harding < >>> [email protected]> wrote: >>> >>>> Thanks Ryan, good point. I'll check with the team. I think, at least in >>>> my mind, we were very focused on 2.0 feature set, such as resources, and so >>>> anything that needed 2.0 would be in the new world order. Your desire to >>>> actually reach out into the past and implement this via the charmstore for >>>> 1.25 is interesting and we'll have to see if clients passed enough info in >>>> the past to be able to do that intelligently. >>>> >>>> >>>> >>>> On Mon, Mar 21, 2016 at 10:06 AM Ryan Beisner < >>>> [email protected]> wrote: >>>> >>>>> On Sun, Mar 20, 2016 at 3:21 PM, roger peppe < >>>>> [email protected]> 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 < >>>>>> [email protected]> 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 <[email protected]> >>>>>> 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 >>>>>> >> > <[email protected]> >>>>>> >> > 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 >>>>>> >> [email protected] >>>>>> >> Modify settings or unsubscribe at: >>>>>> >> https://lists.ubuntu.com/mailman/listinfo/juju >>>>>> > >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > Juju mailing list >>>>>> > [email protected] >>>>>> > Modify settings or unsubscribe at: >>>>>> > https://lists.ubuntu.com/mailman/listinfo/juju >>>>>> > >>>>>> >>>>>> -- >>>>>> Juju mailing list >>>>>> [email protected] >>>>>> Modify settings or unsubscribe at: >>>>>> https://lists.ubuntu.com/mailman/listinfo/juju >>>>>> >>>>> -- >>>>> Juju mailing list >>>>> [email protected] >>>>> Modify settings or unsubscribe at: >>>>> https://lists.ubuntu.com/mailman/listinfo/juju >>>>> >>>>
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
