Re: Charm Store policy updates and refinement for 2.0

[Stuart Bishop]

On 19 March 2016 at 02:58, Jorge O. Castro  wrote:

> Recommendations from everyone on what we should include here would be
> most welcome, specifically our recommendations around Windows charms
> is non-existent.

I think the acceptable software sources needs to be expanded.
Launchpad PPAs should be acceptable as signing keys are securely
retrieved when using 'add-apt-repository ppa:foo/bar'. Also, 3rd party
apt repositories should be acceptable if the signing key is embedded
in the charm (PyPi could be checked similarly, but it seems rare to
find signed packages there).

In addition, any software sources not in the main Ubuntu or CentOS
archives should be listed in configuration items that can be
overridden rather than hard coded in the charm, or else the charm is
useless in network restricted environments (and yes, migrating to
resources may be a better user experience in many cases).

As examples, the PostgreSQL charm pulls non-default packages from the
upstream PostgreSQL apt repository (PGDG, which is the source which
flows to Debian and Ubuntu). The Cassandra charm pulls a required
driver from a PPA I control. It also installs packages from either the
Apache apt repository or the DataStax apt repository. Cassandra is not
available in the Debian or Ubuntu main archives, probably as it
required the Oracle JVM. Both charms use the
install_sources/install_keys config items parsed by charm-helpers and
the apt layer to make this configurable.

On a side note, it is somewhat disingenuous to block charms in the
store from pulling dependencies from untrusted sources at run time
when we happily pull dependencies from untrusted sources at build
time. I think the fix here is to do better at build time (Moving the
interfaces web site to https: and ensuring clients use that address,
only allowing https:, git+ssh: and other secure protocols for pulling
branches, and checking GPG signatures of embedded wheels are the
issues here I'm aware of)

-- 
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: Charmers application - David Ames

[David Ames]

Thank you for all the responses. Glad to be a part of the ~charmers team.

--
David Ames

On 03/21/2016 09:45 AM, Marco Ceppi wrote:

Well, an outstanding turnout, thank you everyone for your feedback. With
more than two +1 from existing charmers welcome thedac!

Thanks,
Marco Ceppi

On Mon, Mar 21, 2016 at 11:41 AM James Page 
wrote:


+1

On Mon, 21 Mar 2016 at 15:37 Chris Glass 
wrote:


Big +1 for thedac here as well.

I'm actually surprised he's not a charmer already!

On Sun, Mar 20, 2016 at 3:11 PM, Liam Young 
wrote:

tl;dr +1 for thedac

I've worked on charms with David since the ol' pyjuju days. He has made
numerous excellent contributions to the Openstack charms, charmhelpers

and

charms from the wider community. He is also an excellent reviewer and

can be

depended on to give a merge proposal a thorough dissection and offer

helpful

suggestions.

On Sat, Mar 19, 2016 at 11:38 PM, David Britton
 wrote:


Big +1 for thedac


On Saturday, March 19, 2016, James Beedy  wrote:


Team -

David played a monumental role in resolving a handful of issues I was
hitting my head on while trying to solidify my HA Openstack, also

with DVR

issues which I was experiencing prior. The issues I was experiencing

were

rather in depth and complex. David went a great deal out of his way to
identify where the bugs were in the charms that were at the root of my
issues, and ensured the issues I was experiencing were exploited and
resolved in the respective charms. By doing this, I feel David has
subsequently played a large role in solidifying the core

functionality of

the charms. It is evident that David cares a great deal about the Juju
ecosystem, producing quality artifacts, and the community in general.

It has

been a pleasure working with David, and I look forward to working

with him

in the future!

Thanks David!

~James




--
David Britton 


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




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



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


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








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

Re: Charmers application - David Ames

[Marco Ceppi]

Well, an outstanding turnout, thank you everyone for your feedback. With
more than two +1 from existing charmers welcome thedac!

Thanks,
Marco Ceppi

On Mon, Mar 21, 2016 at 11:41 AM James Page 
wrote:

> +1
>
> On Mon, 21 Mar 2016 at 15:37 Chris Glass 
> wrote:
>
>> Big +1 for thedac here as well.
>>
>> I'm actually surprised he's not a charmer already!
>>
>> On Sun, Mar 20, 2016 at 3:11 PM, Liam Young 
>> wrote:
>> > tl;dr +1 for thedac
>> >
>> > I've worked on charms with David since the ol' pyjuju days. He has made
>> > numerous excellent contributions to the Openstack charms, charmhelpers
>> and
>> > charms from the wider community. He is also an excellent reviewer and
>> can be
>> > depended on to give a merge proposal a thorough dissection and offer
>> helpful
>> > suggestions.
>> >
>> > On Sat, Mar 19, 2016 at 11:38 PM, David Britton
>> >  wrote:
>> >>
>> >> Big +1 for thedac
>> >>
>> >>
>> >> On Saturday, March 19, 2016, James Beedy  wrote:
>> >>>
>> >>> Team -
>> >>>
>> >>> David played a monumental role in resolving a handful of issues I was
>> >>> hitting my head on while trying to solidify my HA Openstack, also
>> with DVR
>> >>> issues which I was experiencing prior. The issues I was experiencing
>> were
>> >>> rather in depth and complex. David went a great deal out of his way to
>> >>> identify where the bugs were in the charms that were at the root of my
>> >>> issues, and ensured the issues I was experiencing were exploited and
>> >>> resolved in the respective charms. By doing this, I feel David has
>> >>> subsequently played a large role in solidifying the core
>> functionality of
>> >>> the charms. It is evident that David cares a great deal about the Juju
>> >>> ecosystem, producing quality artifacts, and the community in general.
>> It has
>> >>> been a pleasure working with David, and I look forward to working
>> with him
>> >>> in the future!
>> >>>
>> >>> Thanks David!
>> >>>
>> >>> ~James
>> >>>
>> >>
>> >>
>> >> --
>> >> David Britton 
>> >>
>> >>
>> >> --
>> >> 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-dev mailing list
>> juju-...@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charmers application - David Ames

[Marco Ceppi]

Well, an outstanding turnout, thank you everyone for your feedback. With
more than two +1 from existing charmers welcome thedac!

Thanks,
Marco Ceppi

On Mon, Mar 21, 2016 at 11:41 AM James Page 
wrote:

> +1
>
> On Mon, 21 Mar 2016 at 15:37 Chris Glass 
> wrote:
>
>> Big +1 for thedac here as well.
>>
>> I'm actually surprised he's not a charmer already!
>>
>> On Sun, Mar 20, 2016 at 3:11 PM, Liam Young 
>> wrote:
>> > tl;dr +1 for thedac
>> >
>> > I've worked on charms with David since the ol' pyjuju days. He has made
>> > numerous excellent contributions to the Openstack charms, charmhelpers
>> and
>> > charms from the wider community. He is also an excellent reviewer and
>> can be
>> > depended on to give a merge proposal a thorough dissection and offer
>> helpful
>> > suggestions.
>> >
>> > On Sat, Mar 19, 2016 at 11:38 PM, David Britton
>> >  wrote:
>> >>
>> >> Big +1 for thedac
>> >>
>> >>
>> >> On Saturday, March 19, 2016, James Beedy  wrote:
>> >>>
>> >>> Team -
>> >>>
>> >>> David played a monumental role in resolving a handful of issues I was
>> >>> hitting my head on while trying to solidify my HA Openstack, also
>> with DVR
>> >>> issues which I was experiencing prior. The issues I was experiencing
>> were
>> >>> rather in depth and complex. David went a great deal out of his way to
>> >>> identify where the bugs were in the charms that were at the root of my
>> >>> issues, and ensured the issues I was experiencing were exploited and
>> >>> resolved in the respective charms. By doing this, I feel David has
>> >>> subsequently played a large role in solidifying the core
>> functionality of
>> >>> the charms. It is evident that David cares a great deal about the Juju
>> >>> ecosystem, producing quality artifacts, and the community in general.
>> It has
>> >>> been a pleasure working with David, and I look forward to working
>> with him
>> >>> in the future!
>> >>>
>> >>> Thanks David!
>> >>>
>> >>> ~James
>> >>>
>> >>
>> >>
>> >> --
>> >> David Britton 
>> >>
>> >>
>> >> --
>> >> Juju mailing list
>> >> j...@lists.ubuntu.com
>> >> Modify settings or unsubscribe at:
>> >> https://lists.ubuntu.com/mailman/listinfo/juju
>> >>
>> >
>> >
>> > --
>> > Juju mailing list
>> > j...@lists.ubuntu.com
>> > Modify settings or unsubscribe at:
>> > https://lists.ubuntu.com/mailman/listinfo/juju
>> >
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Charmers application - David Ames

[James Page]

+1

On Mon, 21 Mar 2016 at 15:37 Chris Glass 
wrote:

> Big +1 for thedac here as well.
>
> I'm actually surprised he's not a charmer already!
>
> On Sun, Mar 20, 2016 at 3:11 PM, Liam Young 
> wrote:
> > tl;dr +1 for thedac
> >
> > I've worked on charms with David since the ol' pyjuju days. He has made
> > numerous excellent contributions to the Openstack charms, charmhelpers
> and
> > charms from the wider community. He is also an excellent reviewer and
> can be
> > depended on to give a merge proposal a thorough dissection and offer
> helpful
> > suggestions.
> >
> > On Sat, Mar 19, 2016 at 11:38 PM, David Britton
> >  wrote:
> >>
> >> Big +1 for thedac
> >>
> >>
> >> On Saturday, March 19, 2016, James Beedy  wrote:
> >>>
> >>> Team -
> >>>
> >>> David played a monumental role in resolving a handful of issues I was
> >>> hitting my head on while trying to solidify my HA Openstack, also with
> DVR
> >>> issues which I was experiencing prior. The issues I was experiencing
> were
> >>> rather in depth and complex. David went a great deal out of his way to
> >>> identify where the bugs were in the charms that were at the root of my
> >>> issues, and ensured the issues I was experiencing were exploited and
> >>> resolved in the respective charms. By doing this, I feel David has
> >>> subsequently played a large role in solidifying the core functionality
> of
> >>> the charms. It is evident that David cares a great deal about the Juju
> >>> ecosystem, producing quality artifacts, and the community in general.
> It has
> >>> been a pleasure working with David, and I look forward to working with
> him
> >>> in the future!
> >>>
> >>> Thanks David!
> >>>
> >>> ~James
> >>>
> >>
> >>
> >> --
> >> David Britton 
> >>
> >>
> >> --
> >> Juju mailing list
> >> j...@lists.ubuntu.com
> >> Modify settings or unsubscribe at:
> >> https://lists.ubuntu.com/mailman/listinfo/juju
> >>
> >
> >
> > --
> > Juju mailing list
> > j...@lists.ubuntu.com
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/juju
> >
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Charmers application - David Ames

[Chris Glass]

Big +1 for thedac here as well.

I'm actually surprised he's not a charmer already!

On Sun, Mar 20, 2016 at 3:11 PM, Liam Young  wrote:
> tl;dr +1 for thedac
>
> I've worked on charms with David since the ol' pyjuju days. He has made
> numerous excellent contributions to the Openstack charms, charmhelpers and
> charms from the wider community. He is also an excellent reviewer and can be
> depended on to give a merge proposal a thorough dissection and offer helpful
> suggestions.
>
> On Sat, Mar 19, 2016 at 11:38 PM, David Britton
>  wrote:
>>
>> Big +1 for thedac
>>
>>
>> On Saturday, March 19, 2016, James Beedy  wrote:
>>>
>>> Team -
>>>
>>> David played a monumental role in resolving a handful of issues I was
>>> hitting my head on while trying to solidify my HA Openstack, also with DVR
>>> issues which I was experiencing prior. The issues I was experiencing were
>>> rather in depth and complex. David went a great deal out of his way to
>>> identify where the bugs were in the charms that were at the root of my
>>> issues, and ensured the issues I was experiencing were exploited and
>>> resolved in the respective charms. By doing this, I feel David has
>>> subsequently played a large role in solidifying the core functionality of
>>> the charms. It is evident that David cares a great deal about the Juju
>>> ecosystem, producing quality artifacts, and the community in general. It has
>>> been a pleasure working with David, and I look forward to working with him
>>> in the future!
>>>
>>> Thanks David!
>>>
>>> ~James
>>>
>>
>>
>> --
>> David Britton 
>>
>>
>> --
>> 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: Charmers application - David Ames

[Chris Glass]

Big +1 for thedac here as well.

I'm actually surprised he's not a charmer already!

On Sun, Mar 20, 2016 at 3:11 PM, Liam Young  wrote:
> tl;dr +1 for thedac
>
> I've worked on charms with David since the ol' pyjuju days. He has made
> numerous excellent contributions to the Openstack charms, charmhelpers and
> charms from the wider community. He is also an excellent reviewer and can be
> depended on to give a merge proposal a thorough dissection and offer helpful
> suggestions.
>
> On Sat, Mar 19, 2016 at 11:38 PM, David Britton
>  wrote:
>>
>> Big +1 for thedac
>>
>>
>> On Saturday, March 19, 2016, James Beedy  wrote:
>>>
>>> Team -
>>>
>>> David played a monumental role in resolving a handful of issues I was
>>> hitting my head on while trying to solidify my HA Openstack, also with DVR
>>> issues which I was experiencing prior. The issues I was experiencing were
>>> rather in depth and complex. David went a great deal out of his way to
>>> identify where the bugs were in the charms that were at the root of my
>>> issues, and ensured the issues I was experiencing were exploited and
>>> resolved in the respective charms. By doing this, I feel David has
>>> subsequently played a large role in solidifying the core functionality of
>>> the charms. It is evident that David cares a great deal about the Juju
>>> ecosystem, producing quality artifacts, and the community in general. It has
>>> been a pleasure working with David, and I look forward to working with him
>>> in the future!
>>>
>>> Thanks David!
>>>
>>> ~James
>>>
>>
>>
>> --
>> David Britton 
>>
>>
>> --
>> Juju mailing list
>> j...@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
>
> --
> Juju mailing list
> j...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>

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

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 

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 

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: Charmers application - David Ames

[Chris Glass]

Big +1  for thedachere.

I'm actually surprised he's not a charmer already!

On Sat, Mar 19, 2016 at 9:01 PM, James Beedy  wrote:
> Team -
>
> David played a monumental role in resolving a handful of issues I was
> hitting my head on while trying to solidify my HA Openstack, also with DVR
> issues which I was experiencing prior. The issues I was experiencing were
> rather in depth and complex. David went a great deal out of his way to
> identify where the bugs were in the charms that were at the root of my
> issues, and ensured the issues I was experiencing were exploited and
> resolved in the respective charms. By doing this, I feel David has
> subsequently played a large role in solidifying the core functionality of
> the charms. It is evident that David cares a great deal about the Juju
> ecosystem, producing quality artifacts, and the community in general. It has
> been a pleasure working with David, and I look forward to working with him
> in the future!
>
> Thanks David!
>
> ~James
>
>
> --
> 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