New feature for charmers - min-juju-version

[Ryan Beisner]

On Mon, Mar 21, 2016 at 9:18 AM, Rick Harding <rick.harding at canonical.com>
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 <rick.harding at canonical.com>
> 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 <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/e669a7c6/attachment.html>