New feature for charmers - min-juju-version

[Marco Ceppi]

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 <rick.harding at canonical.com>
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 <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/d69dd6e3/attachment.html>