<div dir="ltr">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. <div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Mar 21, 2016 at 10:06 AM Ryan Beisner <<a href="mailto:ryan.beisner@canonical.com">ryan.beisner@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Mar 20, 2016 at 3:21 PM, roger peppe <span dir="ltr"><<a href="mailto:roger.peppe@canonical.com" target="_blank">roger.peppe@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">If the released Juju 2.0 uses v5 of the charmstore API (which it will<br>
soon hopefully anyway when my branch to support the new publishing<br>
model lands), then there's a straightforward solution here, I think:<br>
change v4 of the charmstore API to refuse to serve min-juju-version<br>
charm archives to clients. Since the only v4-using clients should be<br>
old juju versions, this could provide a reasonably cheap to implement<br>
and straightforward solution to the problem.<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>To re-confirm:  Would that be <i>"don't serve up a charm for 1.25.x clients when min-juju-verison is defined at all"</i> -or- <i>"cleverly interpret the min-juju-version server-side and selectively refuse to deliver the charm when client version is less than the min version?"</i></div><div><br></div><div>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).</div><div><br></div><div>If the latter, brilliant!  :)</div><div><br></div><div>Rationale and use case:</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Thanks again!</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div><br>
On 18 March 2016 at 09:49, Uros Jovanovic <<a href="mailto:uros.jovanovic@canonical.com" target="_blank">uros.jovanovic@canonical.com</a>> wrote:<br>
> We’re looking in how we can identify 1.x Juju client/server in such a way<br>
> that at the same time we don’t block access to charms for other clients<br>
> using our HTTP API.<br>
><br>
><br>
> On Fri, Mar 18, 2016 at 9:34 AM, Mark Shuttleworth <<a href="mailto:mark@ubuntu.com" target="_blank">mark@ubuntu.com</a>> wrote:<br>
>><br>
>> On 17/03/16 22:34, Nate Finch wrote:<br>
>> > Yes, it'll be ignored, and the charm will be deployed normally.<br>
>> ><br>
>> > On Thu, Mar 17, 2016 at 3:29 PM Ryan Beisner<br>
>> > <<a href="mailto:ryan.beisner@canonical.com" target="_blank">ryan.beisner@canonical.com</a>><br>
>> > wrote:<br>
>> ><br>
>> >> This is awesome.  What will happen if a charm possesses the flag in<br>
>> >> metadata.yaml and is deployed with 1.25.x?  Will it gracefully ignore<br>
>> >> it?<br>
>> >><br>
>><br>
>> I wonder if there is a clean way for us to have Juju 1.x reject the<br>
>> charm very early in the process, giving an error that would essentially<br>
>> amount to the "not understood"? Or if we could have the charm store<br>
>> refuse to serve up the charm to a 1.x Juju client / server?<br>
>><br>
>> Mark<br>
>><br>
>> --<br>
>> Juju mailing list<br>
>> <a href="mailto:Juju@lists.ubuntu.com" target="_blank">Juju@lists.ubuntu.com</a><br>
>> Modify settings or unsubscribe at:<br>
>> <a href="https://lists.ubuntu.com/mailman/listinfo/juju" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a><br>
><br>
><br>
><br>
> --<br>
> Juju mailing list<br>
> <a href="mailto:Juju@lists.ubuntu.com" target="_blank">Juju@lists.ubuntu.com</a><br>
> Modify settings or unsubscribe at:<br>
> <a href="https://lists.ubuntu.com/mailman/listinfo/juju" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a><br>
><br>
<br>
--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com" target="_blank">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a><br>
</div></div></blockquote></div></div></div>
--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com" target="_blank">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a><br>
</blockquote></div>