New feature for charmers - min-juju-version

[Rick Harding]

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 <ryan.beisner at canonical.com>
wrote:

> On Sun, Mar 20, 2016 at 3:21 PM, roger peppe <roger.peppe at 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.jovanovic at 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 <mark at 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.beisner at 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 at lists.ubuntu.com
>> >> Modify settings or unsubscribe at:
>> >> https://lists.ubuntu.com/mailman/listinfo/juju
>> >
>> >
>> >
>> > --
>> > Juju mailing list
>> > Juju at lists.ubuntu.com
>> > Modify settings or unsubscribe at:
>> > https://lists.ubuntu.com/mailman/listinfo/juju
>> >
>>
>> --
>> Juju mailing list
>> Juju at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160321/57d2be42/attachment.html>