New feature for charmers - min-juju-version

[Rick Harding]

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

> 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/e6425957/attachment.html>