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
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
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
> >>>
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 charmstor
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,
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 is
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
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
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 >=
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 d
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 t
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
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 b
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.2
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
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
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 se
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
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 nor
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 P
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 gracefull
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-juj
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 c
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 sup
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 t
25 matches
Mail list logo
