<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 9, 2016 at 4:16 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.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">Excerpts from Armando M.'s message of 2016-03-08 15:43:05 -0700:<br>
<div><div class="h5">> On 8 March 2016 at 15:07, Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>> wrote:<br>
><br>
> > Excerpts from Armando M.'s message of 2016-03-08 12:49:16 -0700:<br>
> > > Hi folks,<br>
> > ><br>
> > > There's a feature or two that are pending to be delivered in Mitaka<br>
> > [1,2],<br>
> > > and those involve changes to both the server and client sides. Ideally<br>
> > we'd<br>
> > > merge both sides in time for Mitaka RC and that implies that we would be<br>
> > > able to release a new version of the client including changes [3,4]. This<br>
> > > is especially important since a new client release would be beneficial to<br>
> > > improving test coverage as needed by [5].<br>
> > ><br>
> > > Considering what we released already, and what the tip of master is for<br>
> > the<br>
> > > client [6], I can't see any side effect that a new neutronclient release<br>
> > > may introduce.<br>
> > ><br>
> > > Having said that, I am leaning towards the all-or-none approach, but the<br>
> > > 'all' approach is predicated on the fact that we are indeed allowed to<br>
> > > release a new client and touch the global requirements.<br>
> > ><br>
> > > What's the release team's recommendation? Based on it, we may want to<br>
> > > decide to defer these to as soon as N master opens up.<br>
> ><br>
> > I'm a bit reluctant to start touching the requirements lists for<br>
> > feature work. We do have some bug fixes in the pipeline that will<br>
> > require library releases, but those are for bugs not new features.<br>
> > We also have one or two libs where feature work needed to be extended,<br>
> > but none of those have dependencies outside of the project producing<br>
> > them.<br>
> ><br>
> > The main reason to require a client release is for some *other* project<br>
> > to take advantage of the new feature work. Is that planned?<br>
> ><br>
><br>
> Thanks for the prompt reply. Neutron would be the only consumer of these<br>
> additions, and no other project has pending work to leverage these<br>
> capabilities.<br>
<br>
</div></div>In that case, I don't think we want to make an exception. Although<br>
Neutron is the only user of this feature, I counted more than 50 other<br>
projects that have python-neutronclient in a requirements file, and<br>
that's a lot of potential for impact with a new release.<br>
<br>
It seems like the options are to wait for Newton to land both parts of<br>
the feature, or to land the server side during Mitaka and release a<br>
feature update to the client as soon as Newton development opens.<br>
<span class=""><font color="#888888"><br>
Doug<br></font></span></blockquote><div><br></div><div>Yes, if anyone want's more detail, we discussed that in the</div><div>qos-meeting today [1], thank you Doug, for joining us.</div><div><br></div><div>I would like to ask for the inclusion of the server side, regardless</div><div>of the client bits. Fullstack would have to stay out, but I believe</div><div>the api-tests, unit tests, and functional tests included in the patch</div><div>will maintain the feature stability.</div><div><br></div><div>Users would have the chance to make use of the feature via direct</div><div>API calls without the client, or by bumping to neutronclient 4.2.x when</div><div>that's available. Distros would be able to backport the neutronclient</div><div>patch at their will.</div><div><br></div><div>I ask for it, not only for the sake of the feature, which I believe is not</div><div>critical, but because Comcast and other related contributors have been</div><div>patient enough (5-6 cycles?), learned and collaborated the U/S way to</div><div>get this finally in while helping with L2 agent extensibility and other</div><div>technical debt in the way. And because, the earlier the feature gets</div><div>used, the early we could iron out any possible bug features come with.</div><div><div><br></div><div><br></div><div>Best regards,</div><div>Miguel Ángel.</div><div><br></div><div>[1] <a href="http://eavesdrop.openstack.org/meetings/neutron_qos/2016/neutron_qos.2016-03-09-14.03.log.html">http://eavesdrop.openstack.org/meetings/neutron_qos/2016/neutron_qos.2016-03-09-14.03.log.html</a>  (around 15:37)</div></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"><span class=""><font color="#888888">
</font></span><div class=""><div class="h5"><br>
><br>
> ><br>
> > Doug<br>
> ><br>
> > ><br>
> > > Many thanks,<br>
> > > Armando<br>
> > ><br>
> > > [1] <a href="https://review.openstack.org/#/q/topic:bug/1468353" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/topic:bug/1468353</a><br>
> > > [2] <a href="https://review.openstack.org/#/q/topic:bug/1521783" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/topic:bug/1521783</a><br>
> > > [3] <a href="https://review.openstack.org/#/c/254280/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/254280/</a><br>
> > > [4] <a href="https://review.openstack.org/#/c/288187/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/288187/</a><br>
> > > [5] <a href="https://review.openstack.org/#/c/288392/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/288392/</a><br>
> > > [6]<br>
> > ><br>
> > <a href="https://github.com/openstack/python-neutronclient/commit/8460b0dbb354a304a112be13c63cb933ebe1927a" rel="noreferrer" target="_blank">https://github.com/openstack/python-neutronclient/commit/8460b0dbb354a304a112be13c63cb933ebe1927a</a><br>
> ><br>
> > __________________________________________________________________________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>