On Mon, Mar 21, 2016 at 9:18 AM, Rick Harding <rick.hard...@canonical.com> 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 <m...@ubuntu.com> >>>> wrote: >>>> >> >>>> >> On 17/03/16 22:34, Nate Finch wrote: >>>> >> > Yes, it'll be ignored, and the charm will be deployed normally. >>>> >> > >>>> >> > On Thu, Mar 17, 2016 at 3:29 PM Ryan Beisner >>>> >> > <ryan.beis...@canonical.com> >>>> >> > wrote: >>>> >> > >>>> >> >> This is awesome. What will happen if a charm possesses the flag >>>> in >>>> >> >> metadata.yaml and is deployed with 1.25.x? Will it gracefully >>>> ignore >>>> >> >> it? >>>> >> >> >>>> >> >>>> >> I wonder if there is a clean way for us to have Juju 1.x reject the >>>> >> charm very early in the process, giving an error that would >>>> essentially >>>> >> amount to the "not understood"? Or if we could have the charm store >>>> >> refuse to serve up the charm to a 1.x Juju client / server? >>>> >> >>>> >> Mark >>>> >> >>>> >> -- >>>> >> Juju mailing list >>>> >> Juju@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
