Re: [openstack-dev] [neutron][release] Releasing python-neutronclient 4.1.2?
On 9 March 2016 at 08:16, Doug Hellmann wrote: > Excerpts from Armando M.'s message of 2016-03-08 15:43:05 -0700: > > On 8 March 2016 at 15:07, Doug Hellmann 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. > Yesterday I learned in the openstack-neutron channel that Heat has a change [1] that will need a newer version of the client. I agree that landing new features and release a new client version may be risky, and may also limit our chances to have a limited impact should we release a new version for a critical bug fix. [1] https://review.openstack.org/#/c/277567/ > > 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. > I'd rather err on the side of caution, and give this more chance to bake in the master (Newton) trees. We are all too familiar with intermittent or impactful issues post-merge and we have enough critical/high fixes on our plate already. Thanks Doug! Cheers, Armando > > Doug > > > > > > > > > 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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][release] Releasing python-neutronclient 4.1.2?
On Wed, Mar 9, 2016 at 4:16 PM, Doug Hellmann wrote: > Excerpts from Armando M.'s message of 2016-03-08 15:43:05 -0700: > > On 8 March 2016 at 15:07, Doug Hellmann 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-requ...@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-requ...@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-requ...@list
Re: [openstack-dev] [neutron][release] Releasing python-neutronclient 4.1.2?
Excerpts from Armando M.'s message of 2016-03-08 15:43:05 -0700: > On 8 March 2016 at 15:07, Doug Hellmann 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 > > > > > 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][release] Releasing python-neutronclient 4.1.2?
2016-03-09 7:43 GMT+09:00 Armando M. : > > > On 8 March 2016 at 15:07, Doug Hellmann 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. The situations are: * neutron itself works with the current version of neutronclient except that new features merged in RC1 phases are not used via neutronclient. * neutron fullstack test requires a new release of neutron client. There is no need to update global-requirements.txt. neutronclient >= 2.6.0 is enough to make full features of neutron work. What we need is to have a new release of neutronclient in upper-constraints.txt for neutron testing. Can we update upper-constraints.txt only? If we have a new release of neutronclient, the version would be not 4.1.2 but 4.2.0. It has new features added to Neutron in RC1 phase. Akihiro > >> >> >> 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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][release] Releasing python-neutronclient 4.1.2?
On 8 March 2016 at 15:07, Doug Hellmann 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. > > 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][release] Releasing python-neutronclient 4.1.2?
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? 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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron][release] Releasing python-neutronclient 4.1.2?
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. 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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
