Open Stack

On Wed, Mar 9, 2016 at 4:16 PM, Doug Hellmann <doug at doughellmann.com> wrote:

> Excerpts from Armando M.'s message of 2016-03-08 15:43:05 -0700:
> > On 8 March 2016 at 15:07, Doug Hellmann <doug at doughellmann.com> wrote:
> >
> > > Excerpts from Armando M.'s message of 2016-03-08 12:49:16 -0700:
> > > > Hi folks,
> > > >
> > > > There's a feature or two that are pending to be delivered in Mitaka
> > > [1,2],
> > > > and those involve changes to both the server and client sides.
> Ideally
> > > we'd
> > > > merge both sides in time for Mitaka RC and that implies that we
> would be
> > > > able to release a new version of the client including changes [3,4].
> This
> > > > is especially important since a new client release would be
> beneficial to
> > > > improving test coverage as needed by [5].
> > > >
> > > > Considering what we released already, and what the tip of master is
> for
> > > the
> > > > client [6], I can't see any side effect that a new neutronclient
> release
> > > > may introduce.
> > > >
> > > > Having said that, I am leaning towards the all-or-none approach, but
> the
> > > > 'all' approach is predicated on the fact that we are indeed allowed
> to
> > > > release a new client and touch the global requirements.
> > > >
> > > > What's the release team's recommendation? Based on it, we may want to
> > > > decide to defer these to as soon as N master opens up.
> > >
> > > I'm a bit reluctant to start touching the requirements lists for
> > > feature work. We do have some bug fixes in the pipeline that will
> > > require library releases, but those are for bugs not new features.
> > > We also have one or two libs where feature work needed to be extended,
> > > but none of those have dependencies outside of the project producing
> > > them.
> > >
> > > The main reason to require a client release is for some *other* project
> > > to take advantage of the new feature work. Is that planned?
> > >
> >
> > Thanks for the prompt reply. Neutron would be the only consumer of these
> > additions, and no other project has pending work to leverage these
> > capabilities.
>
> In that case, I don't think we want to make an exception. Although
> Neutron is the only user of this feature, I counted more than 50 other
> projects that have python-neutronclient in a requirements file, and
> that's a lot of potential for impact with a new release.
>
> It seems like the options are to wait for Newton to land both parts of
> the feature, or to land the server side during Mitaka and release a
> feature update to the client as soon as Newton development opens.
>
> Doug
>

Yes, if anyone want's more detail, we discussed that in the
qos-meeting today [1], thank you Doug, for joining us.

I would like to ask for the inclusion of the server side, regardless
of the client bits. Fullstack would have to stay out, but I believe
the api-tests, unit tests, and functional tests included in the patch
will maintain the feature stability.

Users would have the chance to make use of the feature via direct
API calls without the client, or by bumping to neutronclient 4.2.x when
that's available. Distros would be able to backport the neutronclient
patch at their will.

I ask for it, not only for the sake of the feature, which I believe is not
critical, but because Comcast and other related contributors have been
patient enough (5-6 cycles?), learned and collaborated the U/S way to
get this finally in while helping with L2 agent extensibility and other
technical debt in the way. And because, the earlier the feature gets
used, the early we could iron out any possible bug features come with.


Best regards,
Miguel Ángel.

[1]
http://eavesdrop.openstack.org/meetings/neutron_qos/2016/neutron_qos.2016-03-09-14.03.log.html
 (around 15:37)


>
> >
> > >
> > > Doug
> > >
> > > >
> > > > Many thanks,
> > > > Armando
> > > >
> > > > [1] https://review.openstack.org/#/q/topic:bug/1468353
> > > > [2] https://review.openstack.org/#/q/topic:bug/1521783
> > > > [3] https://review.openstack.org/#/c/254280/
> > > > [4] https://review.openstack.org/#/c/288187/
> > > > [5] https://review.openstack.org/#/c/288392/
> > > > [6]
> > > >
> > >
> https://github.com/openstack/python-neutronclient/commit/8460b0dbb354a304a112be13c63cb933ebe1927a
> > >
> > >
> __________________________________________________________________________
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160309/a0cc6f7b/attachment.html>