New feature for charmers - min-juju-version

Rick Harding rick.harding at canonical.com
Mon Mar 21 14:18:42 UTC 2016


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.


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


More information about the Juju mailing list