Re: New feature for charmers - min-juju-version

[Ryan Beisner]

On Wed, Mar 30, 2016 at 1:30 AM, Martin Packman <
martin.pack...@canonical.com> wrote:

> On 23/03/2016, Ryan Beisner  wrote:
> >
> > To summarize:
> > If we do nothing with regard to juju 1.25.x or the various tools, and if
> a
> > relevant charm grows a series list in metadata, a load of existing
> > validation and demo bundles will no longer be deployable with 1.25.x
> > because `juju deploy` on 1.25.x traces when receiving a list type as a
> > metadata series value.  These type of bundles often point at gh: and lp:
> > charm dev/feature branches, so the charm series metadata is as it is in
> the
> > dev charm's trunk (unmodified by the charm store).
>
> I've landed a change on the 1.25 branch that accepts a list of series
> in charm metadata and takes the first value as the default series.
>
> 
>
> Charm authors will still need to that that kind of multi series charm
> and place it in named-series-directories under $JUJU_REPOSITORY to
> deploy with 1.X but I think this is fine for your use case?
>

Indeed, that directly addresses the issue and opens us up for cross-1.x-2.x
charm dev and testing.  Many thanks!



>
> Martin
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: New feature for charmers - min-juju-version

[Martin Packman]

On 23/03/2016, Ryan Beisner  wrote:
>
> To summarize:
> If we do nothing with regard to juju 1.25.x or the various tools, and if a
> relevant charm grows a series list in metadata, a load of existing
> validation and demo bundles will no longer be deployable with 1.25.x
> because `juju deploy` on 1.25.x traces when receiving a list type as a
> metadata series value.  These type of bundles often point at gh: and lp:
> charm dev/feature branches, so the charm series metadata is as it is in the
> dev charm's trunk (unmodified by the charm store).

I've landed a change on the 1.25 branch that accepts a list of series
in charm metadata and takes the first value as the default series.



Charm authors will still need to that that kind of multi series charm
and place it in named-series-directories under $JUJU_REPOSITORY to
deploy with 1.X but I think this is fine for your use case?

Martin

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: New feature for charmers - min-juju-version

[Ryan Beisner]

On Wed, Mar 23, 2016 at 1:03 PM, roger peppe 
wrote:

> On 23 March 2016 at 15:06, David Ames  wrote:
> > On 03/21/2016 06:54 PM, Stuart Bishop wrote:
> >>
> >> On 22 March 2016 at 11:42, Rick Harding 
> >> wrote:
> >>>
> >>> I believe that went out and is ok Stuart. The charmstore update is
> >>> deployed
> >>> and when you upload a multi-series charm to the charmstore it creates
> >>> separate charms that work on older clients. If you hit issues with that
> >>> please let me know.
> >>
> >>
> >> Its only fixed for charms served from the charm store. CI systems and
> >> such test branches, for example ensuring tests pass before uploading a
> >> release to the charm store. I suspect this is exactly what Ryan needs
> >> to do and why I mentioned the open bug. Unless 1.25 is updated to
> >> handle the different data types, CI systems will need to work around
> >> the issue by either roundtripping through the charm store (in a
> >> personal namespace to avoid mid air collisions) or munging
> >> metadata.yaml.
>
> ISTM that munging metadata.yaml could be a reasonable way
> to go here. It's not too hard. Here's a program you could use:
> http://play.golang.org/p/xl7yArJhtT
>
>
Indeed that is an option, and that approach would require additional work
on other tooling to enable metadata munging for 1.25.x use.  Such as:
 bundletester, amulet, mojo, juju-deployer.

Whereas, if it is addressed in `juju deploy` for 1.25.x, then it's
addressed in one place for every scenario that I've observed.

To summarize:
If we do nothing with regard to juju 1.25.x or the various tools, and if a
relevant charm grows a series list in metadata, a load of existing
validation and demo bundles will no longer be deployable with 1.25.x
because `juju deploy` on 1.25.x traces when receiving a list type as a
metadata series value.  These type of bundles often point at gh: and lp:
charm dev/feature branches, so the charm series metadata is as it is in the
dev charm's trunk (unmodified by the charm store).




> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: New feature for charmers - min-juju-version

[roger peppe]

On 23 March 2016 at 15:06, David Ames  wrote:
> On 03/21/2016 06:54 PM, Stuart Bishop wrote:
>>
>> On 22 March 2016 at 11:42, Rick Harding 
>> wrote:
>>>
>>> I believe that went out and is ok Stuart. The charmstore update is
>>> deployed
>>> and when you upload a multi-series charm to the charmstore it creates
>>> separate charms that work on older clients. If you hit issues with that
>>> please let me know.
>>
>>
>> Its only fixed for charms served from the charm store. CI systems and
>> such test branches, for example ensuring tests pass before uploading a
>> release to the charm store. I suspect this is exactly what Ryan needs
>> to do and why I mentioned the open bug. Unless 1.25 is updated to
>> handle the different data types, CI systems will need to work around
>> the issue by either roundtripping through the charm store (in a
>> personal namespace to avoid mid air collisions) or munging
>> metadata.yaml.

ISTM that munging metadata.yaml could be a reasonable way
to go here. It's not too hard. Here's a program you could use:
http://play.golang.org/p/xl7yArJhtT

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: New feature for charmers - min-juju-version

[Rick Harding]

Thanks for the feedback. I've asked the Juju team to investigate what
effort would be required to make it 'not broken' and see what we can do to
help this transition.

On Wed, Mar 23, 2016 at 11:06 AM David Ames 
wrote:

> On 03/21/2016 06:54 PM, Stuart Bishop wrote:
> > On 22 March 2016 at 11:42, Rick Harding 
> wrote:
> >> I believe that went out and is ok Stuart. The charmstore update is
> deployed
> >> and when you upload a multi-series charm to the charmstore it creates
> >> separate charms that work on older clients. If you hit issues with that
> >> please let me know.
> >
> > Its only fixed for charms served from the charm store. CI systems and
> > such test branches, for example ensuring tests pass before uploading a
> > release to the charm store. I suspect this is exactly what Ryan needs
> > to do and why I mentioned the open bug. Unless 1.25 is updated to
> > handle the different data types, CI systems will need to work around
> > the issue by either roundtripping through the charm store (in a
> > personal namespace to avoid mid air collisions) or munging
> > metadata.yaml.
>
> This is correct. OpenStack charms will be affected. For much of our CI
> before publishing to the charm store we pull from branches both git and
> bzr. Using 1.25 we will either have to delay implementing series in the
> metadata.yaml or we will have to work around and alter metadata.yaml on
> disk.
>
> Having a juju solution for Bug#1545686 would greatly help our testing.
>
> --
> David Ames
>
>  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.
> >>>
> >>> Bug #1545686 will cause you issues too, unless you are always testing
> >>> charms served from the store rather than local branches. 'series' is
> >>> more involved than min-juju-version, as the data type change to the
> >>> existing setting causes old versions to fail.
> >
> >
> >
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: New feature for charmers - min-juju-version

[David Ames]

On 03/21/2016 06:54 PM, Stuart Bishop wrote:

On 22 March 2016 at 11:42, Rick Harding  wrote:

I believe that went out and is ok Stuart. The charmstore update is deployed
and when you upload a multi-series charm to the charmstore it creates
separate charms that work on older clients. If you hit issues with that
please let me know.


Its only fixed for charms served from the charm store. CI systems and
such test branches, for example ensuring tests pass before uploading a
release to the charm store. I suspect this is exactly what Ryan needs
to do and why I mentioned the open bug. Unless 1.25 is updated to
handle the different data types, CI systems will need to work around
the issue by either roundtripping through the charm store (in a
personal namespace to avoid mid air collisions) or munging
metadata.yaml.


This is correct. OpenStack charms will be affected. For much of our CI 
before publishing to the charm store we pull from branches both git and 
bzr. Using 1.25 we will either have to delay implementing series in the 
metadata.yaml or we will have to work around and alter metadata.yaml on 
disk.


Having a juju solution for Bug#1545686 would greatly help our testing.

--
David Ames


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.


Bug #1545686 will cause you issues too, unless you are always testing
charms served from the store rather than local branches. 'series' is
more involved than min-juju-version, as the data type change to the
existing setting causes old versions to fail.







--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: New feature for charmers - min-juju-version

[Stuart Bishop]

On 22 March 2016 at 11:42, Rick Harding  wrote:
> I believe that went out and is ok Stuart. The charmstore update is deployed
> and when you upload a multi-series charm to the charmstore it creates
> separate charms that work on older clients. If you hit issues with that
> please let me know.

Its only fixed for charms served from the charm store. CI systems and
such test branches, for example ensuring tests pass before uploading a
release to the charm store. I suspect this is exactly what Ryan needs
to do and why I mentioned the open bug. Unless 1.25 is updated to
handle the different data types, CI systems will need to work around
the issue by either roundtripping through the charm store (in a
personal namespace to avoid mid air collisions) or munging
metadata.yaml.


>> > 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.
>>
>> Bug #1545686 will cause you issues too, unless you are always testing
>> charms served from the store rather than local branches. 'series' is
>> more involved than min-juju-version, as the data type change to the
>> existing setting causes old versions to fail.



-- 
Stuart Bishop 

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: New feature for charmers - min-juju-version

[Rick Harding]

I believe that went out and is ok Stuart. The charmstore update is deployed
and when you upload a multi-series charm to the charmstore it creates
separate charms that work on older clients. If you hit issues with that
please let me know.

On Mon, Mar 21, 2016 at 8:39 PM Stuart Bishop 
wrote:

> On 22 March 2016 at 01:06, Ryan Beisner 
> wrote:
>
> > 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.
>
> Bug #1545686 will cause you issues too, unless you are always testing
> charms served from the store rather than local branches. 'series' is
> more involved than min-juju-version, as the data type change to the
> existing setting causes old versions to fail.
>
> --
> Stuart Bishop 
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: New feature for charmers - min-juju-version

[Stuart Bishop]

On 22 March 2016 at 01:06, Ryan Beisner  wrote:

> 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.

Bug #1545686 will cause you issues too, unless you are always testing
charms served from the store rather than local branches. 'series' is
more involved than min-juju-version, as the data type change to the
existing setting causes old versions to fail.

-- 
Stuart Bishop 

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: 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 
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 
> wrote:
>
>> On Mon, Mar 21, 2016 at 9:18 AM, Rick Harding > > 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.hard...@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.beis...@canonical.com> wrote:

> On Sun, Mar 20, 2016 at 3:21 PM, roger peppe <
> roger.pe...@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.jovano...@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 
>> 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
>> >> > 
>> >> > 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 fo

Re: 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 
wrote:

> On Mon, Mar 21, 2016 at 9:18 AM, Rick Harding 
> 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 
>> 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.beis...@canonical.com> wrote:
>>>
 On Sun, Mar 20, 2016 at 3:21 PM, roger peppe >>> > 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.jovano...@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 
> 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
> >> > 
> >> > 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@lists.ubuntu.com
> >> Modify settings or unsubscribe at:
> >> ht

Re: New feature for charmers - min-juju-version

[Ryan Beisner]

On Mon, Mar 21, 2016 at 9:18 AM, Rick Harding 
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 
> 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 
>> wrote:
>>
>>> On Sun, Mar 20, 2016 at 3:21 PM, roger peppe 
>>> 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 
 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 
 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
 >> > 
 >> > 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@lists.ubuntu.com
 >> Modify settings or unsubscribe at:
 >> https://lists.ubuntu.com/mailman/listinfo/juju
 >
 >
 >
 > --
 > Juju mailing list
 > Juju@lists.ubuntu.com
 > Modify settings or unsubscribe at:
 > https://lists.ubuntu.com/mailman/listinfo/juju
 >

 --
 Juju mailing list
 Juju@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju

>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mai

Re: New feature for charmers - min-juju-version

[Rick Harding]

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 
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 
> wrote:
>
>> On Sun, Mar 20, 2016 at 3:21 PM, roger peppe 
>> 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 
>>> 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 
>>> 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
>>> >> > 
>>> >> > 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@lists.ubuntu.com
>>> >> Modify settings or unsubscribe at:
>>> >> https://lists.ubuntu.com/mailman/listinfo/juju
>>> >
>>> >
>>> >
>>> > --
>>> > Juju mailing list
>>> > Juju@lists.ubuntu.com
>>> > Modify settings or unsubscribe at:
>>> > https://lists.ubuntu.com/mailman/listinfo/juju
>>> >
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: 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 
wrote:

> On Sun, Mar 20, 2016 at 3:21 PM, roger peppe 
> 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 
>> 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 
>> 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
>> >> > 
>> >> > 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@lists.ubuntu.com
>> >> Modify settings or unsubscribe at:
>> >> https://lists.ubuntu.com/mailman/listinfo/juju
>> >
>> >
>> >
>> > --
>> > Juju mailing list
>> > Juju@lists.ubuntu.com
>> > Modify settings or unsubscribe at:
>> > https://lists.ubuntu.com/mailman/listinfo/juju
>> >
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: New feature for charmers - min-juju-version

[Ryan Beisner]

On Sun, Mar 20, 2016 at 3:21 PM, roger peppe 
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 
> 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 
> 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
> >> > 
> >> > 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@lists.ubuntu.com
> >> Modify settings or unsubscribe at:
> >> https://lists.ubuntu.com/mailman/listinfo/juju
> >
> >
> >
> > --
> > Juju mailing list
> > Juju@lists.ubuntu.com
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/juju
> >
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: New feature for charmers - min-juju-version

[Rick Harding]

Thanks Roger, can we get this to the list please and make sure/test that
the message that the client gets back is very clear and perhaps even points
the user to the documentation to the min-juju-version feature so that it's
clear.

Nate, do we have notes on the feature in the devel docs or have the planned
location/path for those?

Thanks

On Sun, Mar 20, 2016 at 7:58 PM Mark Shuttleworth  wrote:

> On 20/03/16 20:21, roger peppe 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.
> >
>
> +1, good thinking, batman :)
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: New feature for charmers - min-juju-version

[Mark Shuttleworth]

On 20/03/16 20:21, roger peppe 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.
>

+1, good thinking, batman :)

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: New feature for charmers - min-juju-version

[roger peppe]

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.

On 18 March 2016 at 09:49, Uros Jovanovic  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  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
>> > 
>> > 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@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: New feature for charmers - min-juju-version

[Rick Harding]

Thanks Nate, great stuff. I know there's a lot of folks looking forward to
this helping our charming community out as we fill out the model more and
charms get to adapt and move forward.

On Thu, Mar 17, 2016 at 6:35 PM 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 
> 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?
>>
>> On Thu, Mar 17, 2016 at 1:57 PM, Nate Finch 
>> wrote:
>>
>>> There is a new (optional) top level field in the metadata.yaml file
>>> called min-juju-version. If supplied, this value specifies the minimum
>>> version of a Juju server with which the charm is compatible. When a user
>>> attempts to deploy a charm (whether from the charmstore or from local) that
>>> has min-juju-version specified, if the targeted model's Juju version is
>>> lower than that specified, then the user will be shown an error noting that
>>> the charm requires a newer version of Juju (and told what version they
>>> need). The format for min-juju-version is a string that follows the same
>>> scheme as our release versions, so you can be as specific as you like. For
>>> example, min-juju-version: "2.0.1-beta3" will deploy on 2.0.1 (release),
>>> but will not deploy on 2.0.1-alpha1 (since alpha1 is older than beta3).
>>>
>>> Note that, at this time, Juju 1.25.x does *not* recognize this flag, so
>>> it will, unfortunately, not be respected by 1.25 environments.
>>>
>>> This code just landed in master, so feel free to give it a spin.
>>>
>>> -Nate
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: New feature for charmers - min-juju-version

[Nate Finch]

Yes, it'll be ignored, and the charm will be deployed normally.

On Thu, Mar 17, 2016 at 3:29 PM Ryan Beisner 
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?
>
> On Thu, Mar 17, 2016 at 1:57 PM, Nate Finch 
> wrote:
>
>> There is a new (optional) top level field in the metadata.yaml file
>> called min-juju-version. If supplied, this value specifies the minimum
>> version of a Juju server with which the charm is compatible. When a user
>> attempts to deploy a charm (whether from the charmstore or from local) that
>> has min-juju-version specified, if the targeted model's Juju version is
>> lower than that specified, then the user will be shown an error noting that
>> the charm requires a newer version of Juju (and told what version they
>> need). The format for min-juju-version is a string that follows the same
>> scheme as our release versions, so you can be as specific as you like. For
>> example, min-juju-version: "2.0.1-beta3" will deploy on 2.0.1 (release),
>> but will not deploy on 2.0.1-alpha1 (since alpha1 is older than beta3).
>>
>> Note that, at this time, Juju 1.25.x does *not* recognize this flag, so
>> it will, unfortunately, not be respected by 1.25 environments.
>>
>> This code just landed in master, so feel free to give it a spin.
>>
>> -Nate
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: New feature for charmers - min-juju-version

[Mark Shuttleworth]

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 
> 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@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

New feature for charmers - min-juju-version

[Nate Finch]

There is a new (optional) top level field in the metadata.yaml file called
min-juju-version. If supplied, this value specifies the minimum version of
a Juju server with which the charm is compatible. When a user attempts to
deploy a charm (whether from the charmstore or from local) that has
min-juju-version specified, if the targeted model's Juju version is lower
than that specified, then the user will be shown an error noting that the
charm requires a newer version of Juju (and told what version they need).
The format for min-juju-version is a string that follows the same scheme as
our release versions, so you can be as specific as you like. For example,
min-juju-version: "2.0.1-beta3" will deploy on 2.0.1 (release), but will
not deploy on 2.0.1-alpha1 (since alpha1 is older than beta3).

Note that, at this time, Juju 1.25.x does *not* recognize this flag, so it
will, unfortunately, not be respected by 1.25 environments.

This code just landed in master, so feel free to give it a spin.

-Nate
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: New feature for charmers - min-juju-version

[Mark Shuttleworth]

On 17/03/16 18:57, Nate Finch wrote:
> There is a new (optional) top level field in the metadata.yaml file called
> min-juju-version. If supplied, this value specifies the minimum version of
> a Juju server with which the charm is compatible.

Thank you! This is an oft-requested feature to enable charmers to focus
on newer Juju capabilities.

Mark

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: New feature for charmers - min-juju-version

[Ryan Beisner]

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?

On Thu, Mar 17, 2016 at 1:57 PM, Nate Finch 
wrote:

> There is a new (optional) top level field in the metadata.yaml file called
> min-juju-version. If supplied, this value specifies the minimum version of
> a Juju server with which the charm is compatible. When a user attempts to
> deploy a charm (whether from the charmstore or from local) that has
> min-juju-version specified, if the targeted model's Juju version is lower
> than that specified, then the user will be shown an error noting that the
> charm requires a newer version of Juju (and told what version they need).
> The format for min-juju-version is a string that follows the same scheme as
> our release versions, so you can be as specific as you like. For example,
> min-juju-version: "2.0.1-beta3" will deploy on 2.0.1 (release), but will
> not deploy on 2.0.1-alpha1 (since alpha1 is older than beta3).
>
> Note that, at this time, Juju 1.25.x does *not* recognize this flag, so it
> will, unfortunately, not be respected by 1.25 environments.
>
> This code just landed in master, so feel free to give it a spin.
>
> -Nate
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: New feature for charmers - min-juju-version

[Uros Jovanovic]

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  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  >
> > 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@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju