[all][neutron][neutron-fwaas] Maintainers needed
Hi,
Over the past couple of cycles we have noticed that new contributions and maintenance efforts for neutron-fwaas project were almost non existent. This impacts patches for bug fixes, new features and reviews. The Neutron core team is trying to at least keep the CI of this project healthy, but we don’t have enough knowledge about the details of the neutron-fwaas code base to review more complex patches.
During the PTG in Shanghai we discussed that with operators and TC members during the forum session [1] and later within the Neutron team during the PTG session [2].
During these discussions, with the help of operators and TC members, we reached the conclusion that we need to have someone responsible for maintaining project. This doesn’t mean that the maintainer needs to spend full time working on this project. Rather, we need someone to be the contact person for the project, who takes care of the project’s CI and review patches. Of course that’s only a minimal requirement. If the new maintainer works on new features for the project, it’s even better :)
If we don’t have any new maintainer(s) before milestone Ussuri-2, which is Feb 10 - Feb 14 according to [3], we will need to mark neutron-fwaas as deprecated and in “V” cycle we will propose to move the project from the Neutron stadium, hosted in the “openstack/“ namespace, to the unofficial projects hosted in the “x/“ namespace.
So if You are using this project now, or if You have customers who are using it, please consider the possibility of maintaining it. Otherwise, please be aware that it is highly possible that the project will be deprecated and moved out from the official OpenStack projects.
[1] https://etherpad.openstack.org/p/PVG-Neutron-stadium-projects-the-path-forwa... [2] https://etherpad.openstack.org/p/Shanghai-Neutron-Planning-restored - Lines 379-421 [3] https://releases.openstack.org/ussuri/schedule.html
Hi,
Just as a reminder, we are still looking for maintainers who want to keep neutron-fwaas project alive. As it was written in my previous email, we will mark this project as deprecated. So please reply to this email or contact me directly if You are interested in maintaining this project.
On 19 Nov 2019, at 11:26, Slawek Kaplonski skaplons@redhat.com wrote:
Hi,
Over the past couple of cycles we have noticed that new contributions and maintenance efforts for neutron-fwaas project were almost non existent. This impacts patches for bug fixes, new features and reviews. The Neutron core team is trying to at least keep the CI of this project healthy, but we don’t have enough knowledge about the details of the neutron-fwaas code base to review more complex patches.
During the PTG in Shanghai we discussed that with operators and TC members during the forum session [1] and later within the Neutron team during the PTG session [2].
During these discussions, with the help of operators and TC members, we reached the conclusion that we need to have someone responsible for maintaining project. This doesn’t mean that the maintainer needs to spend full time working on this project. Rather, we need someone to be the contact person for the project, who takes care of the project’s CI and review patches. Of course that’s only a minimal requirement. If the new maintainer works on new features for the project, it’s even better :)
If we don’t have any new maintainer(s) before milestone Ussuri-2, which is Feb 10 - Feb 14 according to [3], we will need to mark neutron-fwaas as deprecated and in “V” cycle we will propose to move the project from the Neutron stadium, hosted in the “openstack/“ namespace, to the unofficial projects hosted in the “x/“ namespace.
So if You are using this project now, or if You have customers who are using it, please consider the possibility of maintaining it. Otherwise, please be aware that it is highly possible that the project will be deprecated and moved out from the official OpenStack projects.
[1] https://etherpad.openstack.org/p/PVG-Neutron-stadium-projects-the-path-forwa... [2] https://etherpad.openstack.org/p/Shanghai-Neutron-Planning-restored - Lines 379-421 [3] https://releases.openstack.org/ussuri/schedule.html
-- Slawek Kaplonski Senior software engineer Red Hat
— Slawek Kaplonski Senior software engineer Red Hat
Hi,
We are getting closer and closer to Ussuri-2 milestone which is our deadline to deprecate neutron-fwaas project if there will be no any volunteers to maintain this project. So if You are interested in this project, please raise Your hand here or ping me on IRC about that.
On 6 Jan 2020, at 21:05, Slawek Kaplonski skaplons@redhat.com wrote:
Hi,
Just as a reminder, we are still looking for maintainers who want to keep neutron-fwaas project alive. As it was written in my previous email, we will mark this project as deprecated. So please reply to this email or contact me directly if You are interested in maintaining this project.
On 19 Nov 2019, at 11:26, Slawek Kaplonski skaplons@redhat.com wrote:
Hi,
Over the past couple of cycles we have noticed that new contributions and maintenance efforts for neutron-fwaas project were almost non existent. This impacts patches for bug fixes, new features and reviews. The Neutron core team is trying to at least keep the CI of this project healthy, but we don’t have enough knowledge about the details of the neutron-fwaas code base to review more complex patches.
During the PTG in Shanghai we discussed that with operators and TC members during the forum session [1] and later within the Neutron team during the PTG session [2].
During these discussions, with the help of operators and TC members, we reached the conclusion that we need to have someone responsible for maintaining project. This doesn’t mean that the maintainer needs to spend full time working on this project. Rather, we need someone to be the contact person for the project, who takes care of the project’s CI and review patches. Of course that’s only a minimal requirement. If the new maintainer works on new features for the project, it’s even better :)
If we don’t have any new maintainer(s) before milestone Ussuri-2, which is Feb 10 - Feb 14 according to [3], we will need to mark neutron-fwaas as deprecated and in “V” cycle we will propose to move the project from the Neutron stadium, hosted in the “openstack/“ namespace, to the unofficial projects hosted in the “x/“ namespace.
So if You are using this project now, or if You have customers who are using it, please consider the possibility of maintaining it. Otherwise, please be aware that it is highly possible that the project will be deprecated and moved out from the official OpenStack projects.
[1] https://etherpad.openstack.org/p/PVG-Neutron-stadium-projects-the-path-forwa... [2] https://etherpad.openstack.org/p/Shanghai-Neutron-Planning-restored - Lines 379-421 [3] https://releases.openstack.org/ussuri/schedule.html
-- Slawek Kaplonski Senior software engineer Red Hat
— Slawek Kaplonski Senior software engineer Red Hat
— Slawek Kaplonski Senior software engineer Red Hat
-----Original Message----- From: Slawek Kaplonski [mailto:skaplons@redhat.com] Sent: Monday, January 20, 2020 2:26 PM To: OpenStack Discuss ML Subject: Re: [all][neutron][neutron-fwaas] FINAL CALL Maintainers needed
Hi,
We are getting closer and closer to Ussuri-2 milestone which is our deadline to deprecate neutron-fwaas project if there will be no any volunteers to maintain this project. So if You are interested in this project, please raise Your hand here or ping me on IRC about that.
On 6 Jan 2020, at 21:05, Slawek Kaplonski skaplons@redhat.com wrote:
Hi,
Just as a reminder, we are still looking for maintainers who want to keep
neutron-fwaas project alive. As it was written in my previous email, we will mark this project as deprecated.
So please reply to this email or contact me directly if You are interested in
maintaining this project.
On 19 Nov 2019, at 11:26, Slawek Kaplonski skaplons@redhat.com
wrote:
Hi,
Over the past couple of cycles we have noticed that new contributions
and
maintenance efforts for neutron-fwaas project were almost non existent. This impacts patches for bug fixes, new features and reviews. The
Neutron
core team is trying to at least keep the CI of this project healthy, but we don’t have enough knowledge about the details of the neutron-fwaas code base to review more complex patches.
During the PTG in Shanghai we discussed that with operators and TC
members
during the forum session [1] and later within the Neutron team during the PTG session [2].
During these discussions, with the help of operators and TC members, we
reached
the conclusion that we need to have someone responsible for
maintaining project.
This doesn’t mean that the maintainer needs to spend full time working
on this
project. Rather, we need someone to be the contact person for the
project, who
takes care of the project’s CI and review patches. Of course that’s only a minimal requirement. If the new maintainer works on new features for
the
project, it’s even better :)
If we don’t have any new maintainer(s) before milestone Ussuri-2, which
is
Feb 10 - Feb 14 according to [3], we will need to mark neutron-fwaas as deprecated and in “V” cycle we will propose to move the project from the Neutron stadium, hosted in the “openstack/“ namespace, to the unofficial projects hosted in the “x/“ namespace.
So if You are using this project now, or if You have customers who are using it, please consider the possibility of maintaining it. Otherwise, please be aware that it is highly possible that the project will be deprecated and moved out from the official OpenStack projects.
[1] https://etherpad.openstack.org/p/PVG-Neutron-stadium-projects-the-
path-forward
[2] https://etherpad.openstack.org/p/Shanghai-Neutron-Planning-
restored -
Lines 379-421 [3] https://releases.openstack.org/ussuri/schedule.html
-- Slawek Kaplonski Senior software engineer Red Hat
— Slawek Kaplonski Senior software engineer Red Hat
— Slawek Kaplonski Senior software engineer Red Hat
I'm not a developer, rather an operator. I just thought I'd ask if the OpenStack community had thought about creating a fund for developers that may want to contribute, but can only do it for a fee. Essentially a donation bucket. I don't know if the OpenStack Foundation does this or not already. There may be adequate need for fwaas, for example, but not enough volunteer resources to do it. However there may be money in multiple operators' budgets that can be used to donate to the support of a project.
Eric
On 2020-01-20 14:54:02 -0600 (-0600), Eric K. Miller wrote: [...]
I'm not a developer, rather an operator. I just thought I'd ask if the OpenStack community had thought about creating a fund for developers that may want to contribute, but can only do it for a fee. Essentially a donation bucket. I don't know if the OpenStack Foundation does this or not already. There may be adequate need for fwaas, for example, but not enough volunteer resources to do it. However there may be money in multiple operators' budgets that can be used to donate to the support of a project.
Our community has mostly relied on commercial distribution vendors and service providers to fill that role in the past. If enough of their customers say it's a feature they're relying on, then employing developers who can help keep it maintained is their raison d'être. This is how pretty much all free/libre open source community software projects work.
Our community has mostly relied on commercial distribution vendors and service providers to fill that role in the past. If enough of their customers say it's a feature they're relying on, then employing developers who can help keep it maintained is their raison d'être. This is how pretty much all free/libre open source community software projects work. -- Jeremy Stanley
Understood. I thought there may be a way to crowd-fund something in case smaller operators had small budgets, needed some feature supported, but couldn't afford an entire employee with the small budget.
Maybe there are developer consultants interested in a gig to maintain something for a while. Not sure where the best place to go for matching operators with consultants for this type of thing.
fwaas seems like such a necessity. We would love to offer it, but it is unusable with DVR. We just don't have the budget to hire someone specifically for development/support of this.
Eric
On Mon, Jan 20, 2020 at 4:46 PM Eric K. Miller emiller@genesishosting.com wrote:
Our community has mostly relied on commercial distribution vendors and service providers to fill that role in the past. If enough of their customers say it's a feature they're relying on, then employing developers who can help keep it maintained is their raison d'être. This is how pretty much all free/libre open source community software projects work. -- Jeremy Stanley
Understood. I thought there may be a way to crowd-fund something in case smaller operators had small budgets, needed some feature supported, but couldn't afford an entire employee with the small budget.
Maybe there are developer consultants interested in a gig to maintain something for a while. Not sure where the best place to go for matching operators with consultants for this type of thing.
fwaas seems like such a necessity. We would love to offer it, but it is unusable with DVR. We just don't have the budget to hire someone specifically for development/support of this.
Smells like a case for gofundme time. Or, is there still time for google summer of code submission?
Eric
Smells like a case for gofundme time. Or, is there still timefor google summer of code submission?
I'll check out gofundme. I honestly haven't looked at it much. I wasn't sure where OpenStack developer consultants would look for this type of gig. If it is gofundme, that works!
Eric
On Mon, 2020-01-20 at 15:43 -0600, Eric K. Miller wrote:
Our community has mostly relied on commercial distribution vendors and service providers to fill that role in the past. If enough of their customers say it's a feature they're relying on, then employing developers who can help keep it maintained is their raison d'être. This is how pretty much all free/libre open source community software projects work. -- Jeremy Stanley
Understood. I thought there may be a way to crowd-fund something in case smaller operators had small budgets, needed some feature supported, but couldn't afford an entire employee with the small budget.
Maybe there are developer consultants interested in a gig to maintain something for a while. Not sure where the best place to go for matching operators with consultants for this type of thing.
fwaas seems like such a necessity. We would love to offer it, but it is unusable with DVR. We just don't have the budget to hire someone specifically for development/support of this.
for a lot of usecase security groups is sufficent and people do not need to enforce firewalls between networks at neutron routers which is effectivly how fwaas worked. enfrocement via security groups on the ports attached to the instance was sufficent. similarly for operators that have invested in an sdn solution they can porvide an out of band policy enformce point. as a result in a normal openstack deployment fwaas became redundant.
there still usecase for this fwaas but less then you would think. much of the thing you migh typicaly do in an east west direction or bettwen laywers in you applciation can be done using remote security groups instead of cidrs with security groups. the gab that security groups did not fill easily was ironic and sriov however i belive some fo the heriacical switch binding drives did support security impletend at the top of rack switch that could close that gap.
as a result FWaaS has become less deployed and less maintianed over time. the other issue as you noted is compatabliy the fact that VPNaas FWaas and ovs dvr with ml2/ovs did not just work means its a hard sell. that is compounded by the fact that none of the main sdn solutions supported it either.
any implematnion of FWaaS whould have provdied sevedor entroy point for neutron.agent.l2.firewall_drivers https://github.com/openstack/neutron-fwaas/blob/master/setup.cfg#L45-L47 and neutron.agent.l3.firewall_drivers https://github.com/openstack/neutron-fwaas/blob/master/setup.cfg#L51-L53
but as you can see odl, ovn, mideonet, onos, contrail, dragonflow and calico do not implement support https://github.com/openstack/networking-odl/blob/master/setup.cfg#L47-L66 https://github.com/openstack/networking-ovn/blob/master/setup.cfg#L51-L62 https://github.com/openstack/networking-midonet/blob/02e25cc65601add1d96b715... https://github.com/openstack/networking-onos/blob/master/setup.cfg#L40-L49 https://opendev.org/x/networking-opencontrail/src/branch/master/setup.cfg#L2... https://github.com/openstack/dragonflow/blob/master/setup.cfg#L45-L121 https://github.com/openstack/networking-calico/blob/master/setup.cfg#L24-L30
networking-cisco provide an alternive fw api https://opendev.org/x/networking-cisco/src/branch/master/setup.cfg#L97-L100 and arista support a security group api at the top or rack switch https://opendev.org/x/networking-arista/src/branch/master/setup.cfg#L41
unless customers are asking vendors to provide FWaaS, in my experince it was never a telco prioity at least, vendor wont have a buisness case to justify investment. That does not help those that do use FWaaS today but its a sad fact that individuals and compaines need to choose wehre they spend there resouces carfully and FWaaS just never caught on enough to remain relevent.
Eric
Hi,
Ussuri-2 milestone is behind us and we still don’t have anyone who would like to maintain neutron-fwaas project upstream. So I just sent patch [1] to add info to project’s docs that it is deprecated in Neutron stadium.
Question, to TC members mostly - should I do also some other actions to officially deprecate this project? Any changes to governance repo or something like that? Thanks in advance for any help with that.
[1] https://review.opendev.org/708675
On 20 Jan 2020, at 21:26, Slawek Kaplonski skaplons@redhat.com wrote:
Hi,
We are getting closer and closer to Ussuri-2 milestone which is our deadline to deprecate neutron-fwaas project if there will be no any volunteers to maintain this project. So if You are interested in this project, please raise Your hand here or ping me on IRC about that.
On 6 Jan 2020, at 21:05, Slawek Kaplonski skaplons@redhat.com wrote:
Hi,
Just as a reminder, we are still looking for maintainers who want to keep neutron-fwaas project alive. As it was written in my previous email, we will mark this project as deprecated. So please reply to this email or contact me directly if You are interested in maintaining this project.
On 19 Nov 2019, at 11:26, Slawek Kaplonski skaplons@redhat.com wrote:
Hi,
Over the past couple of cycles we have noticed that new contributions and maintenance efforts for neutron-fwaas project were almost non existent. This impacts patches for bug fixes, new features and reviews. The Neutron core team is trying to at least keep the CI of this project healthy, but we don’t have enough knowledge about the details of the neutron-fwaas code base to review more complex patches.
During the PTG in Shanghai we discussed that with operators and TC members during the forum session [1] and later within the Neutron team during the PTG session [2].
During these discussions, with the help of operators and TC members, we reached the conclusion that we need to have someone responsible for maintaining project. This doesn’t mean that the maintainer needs to spend full time working on this project. Rather, we need someone to be the contact person for the project, who takes care of the project’s CI and review patches. Of course that’s only a minimal requirement. If the new maintainer works on new features for the project, it’s even better :)
If we don’t have any new maintainer(s) before milestone Ussuri-2, which is Feb 10 - Feb 14 according to [3], we will need to mark neutron-fwaas as deprecated and in “V” cycle we will propose to move the project from the Neutron stadium, hosted in the “openstack/“ namespace, to the unofficial projects hosted in the “x/“ namespace.
So if You are using this project now, or if You have customers who are using it, please consider the possibility of maintaining it. Otherwise, please be aware that it is highly possible that the project will be deprecated and moved out from the official OpenStack projects.
[1] https://etherpad.openstack.org/p/PVG-Neutron-stadium-projects-the-path-forwa... [2] https://etherpad.openstack.org/p/Shanghai-Neutron-Planning-restored - Lines 379-421 [3] https://releases.openstack.org/ussuri/schedule.html
-- Slawek Kaplonski Senior software engineer Red Hat
— Slawek Kaplonski Senior software engineer Red Hat
— Slawek Kaplonski Senior software engineer Red Hat
— Slawek Kaplonski Senior software engineer Red Hat
On Wed, Feb 19, 2020 at 05:07:12PM +0100, Slawek Kaplonski wrote:
Hi,
Ussuri-2 milestone is behind us and we still don’t have anyone who would like to maintain neutron-fwaas project upstream. So I just sent patch [1] to add info to project’s docs that it is deprecated in Neutron stadium.
Question, to TC members mostly - should I do also some other actions to officially deprecate this project? Any changes to governance repo or something like that? Thanks in advance for any help with that.
Shall we follow the same process we used for LBaaS in [1] and [2], or does that need to wait? I think there is a good chance we will not see another release of neutron-fwaas code.
Thanks
Nate
[1] https://review.opendev.org/#/c/705780/ [2] https://review.opendev.org/#/c/658493/
[1] https://review.opendev.org/708675
On 20 Jan 2020, at 21:26, Slawek Kaplonski skaplons@redhat.com wrote:
Hi,
We are getting closer and closer to Ussuri-2 milestone which is our deadline to deprecate neutron-fwaas project if there will be no any volunteers to maintain this project. So if You are interested in this project, please raise Your hand here or ping me on IRC about that.
On 6 Jan 2020, at 21:05, Slawek Kaplonski skaplons@redhat.com wrote:
Hi,
Just as a reminder, we are still looking for maintainers who want to keep neutron-fwaas project alive. As it was written in my previous email, we will mark this project as deprecated. So please reply to this email or contact me directly if You are interested in maintaining this project.
On 19 Nov 2019, at 11:26, Slawek Kaplonski skaplons@redhat.com wrote:
Hi,
Over the past couple of cycles we have noticed that new contributions and maintenance efforts for neutron-fwaas project were almost non existent. This impacts patches for bug fixes, new features and reviews. The Neutron core team is trying to at least keep the CI of this project healthy, but we don’t have enough knowledge about the details of the neutron-fwaas code base to review more complex patches.
During the PTG in Shanghai we discussed that with operators and TC members during the forum session [1] and later within the Neutron team during the PTG session [2].
During these discussions, with the help of operators and TC members, we reached the conclusion that we need to have someone responsible for maintaining project. This doesn’t mean that the maintainer needs to spend full time working on this project. Rather, we need someone to be the contact person for the project, who takes care of the project’s CI and review patches. Of course that’s only a minimal requirement. If the new maintainer works on new features for the project, it’s even better :)
If we don’t have any new maintainer(s) before milestone Ussuri-2, which is Feb 10 - Feb 14 according to [3], we will need to mark neutron-fwaas as deprecated and in “V” cycle we will propose to move the project from the Neutron stadium, hosted in the “openstack/“ namespace, to the unofficial projects hosted in the “x/“ namespace.
So if You are using this project now, or if You have customers who are using it, please consider the possibility of maintaining it. Otherwise, please be aware that it is highly possible that the project will be deprecated and moved out from the official OpenStack projects.
[1] https://etherpad.openstack.org/p/PVG-Neutron-stadium-projects-the-path-forwa... [2] https://etherpad.openstack.org/p/Shanghai-Neutron-Planning-restored - Lines 379-421 [3] https://releases.openstack.org/ussuri/schedule.html
-- Slawek Kaplonski Senior software engineer Red Hat
— Slawek Kaplonski Senior software engineer Red Hat
— Slawek Kaplonski Senior software engineer Red Hat
— Slawek Kaplonski Senior software engineer Red Hat
On Thu, Feb 20, 2020 at 3:04 AM Nate Johnston nate.johnston@redhat.com wrote:
On Wed, Feb 19, 2020 at 05:07:12PM +0100, Slawek Kaplonski wrote:
Hi,
Ussuri-2 milestone is behind us and we still don’t have anyone who would like to maintain neutron-fwaas project upstream. So I just sent patch [1] to add info to project’s docs that it is deprecated in Neutron stadium.
Question, to TC members mostly - should I do also some other actions to officially deprecate this project? Any changes to governance repo or something like that? Thanks in advance for any help with that.
Shall we follow the same process we used for LBaaS in [1] and [2], or does that need to wait?
In case of LBaaS, the repository was marked as 'deprecated' when the master branch was retired. When neutron-lbaas was deprecated (in the master branch), no change happened in the governance side.
I think there is a good chance we will not see another release of neutron-fwaas code.
I also would like to note that 'deprecation' does not mean we stop new releases. neutron-lbaas continued to cut releases even after the deprecation is enabled. IIRC neutron-lbaas was marked as deprecated Jan 2018 around the queens release and it was released till Stein. neutron-fwaas is being marked as deprecated, so I think we still need to release it until neutron-fwaas was retired in the master branch.
Thanks, Akihiro
Thanks
Nate
[1] https://review.opendev.org/#/c/705780/ [2] https://review.opendev.org/#/c/658493/
[1] https://review.opendev.org/708675
On 20 Jan 2020, at 21:26, Slawek Kaplonski skaplons@redhat.com wrote:
Hi,
We are getting closer and closer to Ussuri-2 milestone which is our deadline to deprecate neutron-fwaas project if there will be no any volunteers to maintain this project. So if You are interested in this project, please raise Your hand here or ping me on IRC about that.
On 6 Jan 2020, at 21:05, Slawek Kaplonski skaplons@redhat.com wrote:
Hi,
Just as a reminder, we are still looking for maintainers who want to keep neutron-fwaas project alive. As it was written in my previous email, we will mark this project as deprecated. So please reply to this email or contact me directly if You are interested in maintaining this project.
On 19 Nov 2019, at 11:26, Slawek Kaplonski skaplons@redhat.com wrote:
Hi,
Over the past couple of cycles we have noticed that new contributions and maintenance efforts for neutron-fwaas project were almost non existent. This impacts patches for bug fixes, new features and reviews. The Neutron core team is trying to at least keep the CI of this project healthy, but we don’t have enough knowledge about the details of the neutron-fwaas code base to review more complex patches.
During the PTG in Shanghai we discussed that with operators and TC members during the forum session [1] and later within the Neutron team during the PTG session [2].
During these discussions, with the help of operators and TC members, we reached the conclusion that we need to have someone responsible for maintaining project. This doesn’t mean that the maintainer needs to spend full time working on this project. Rather, we need someone to be the contact person for the project, who takes care of the project’s CI and review patches. Of course that’s only a minimal requirement. If the new maintainer works on new features for the project, it’s even better :)
If we don’t have any new maintainer(s) before milestone Ussuri-2, which is Feb 10 - Feb 14 according to [3], we will need to mark neutron-fwaas as deprecated and in “V” cycle we will propose to move the project from the Neutron stadium, hosted in the “openstack/“ namespace, to the unofficial projects hosted in the “x/“ namespace.
So if You are using this project now, or if You have customers who are using it, please consider the possibility of maintaining it. Otherwise, please be aware that it is highly possible that the project will be deprecated and moved out from the official OpenStack projects.
[1] https://etherpad.openstack.org/p/PVG-Neutron-stadium-projects-the-path-forwa... [2] https://etherpad.openstack.org/p/Shanghai-Neutron-Planning-restored - Lines 379-421 [3] https://releases.openstack.org/ussuri/schedule.html
-- Slawek Kaplonski Senior software engineer Red Hat
— Slawek Kaplonski Senior software engineer Red Hat
— Slawek Kaplonski Senior software engineer Red Hat
— Slawek Kaplonski Senior software engineer Red Hat
Akihiro Motoki wrote:
[...] I also would like to note that 'deprecation' does not mean we stop new releases. neutron-lbaas continued to cut releases even after the deprecation is enabled. IIRC neutron-lbaas was marked as deprecated Jan 2018 around the queens release and it was released till Stein. neutron-fwaas is being marked as deprecated, so I think we still need to release it until neutron-fwaas was retired in the master branch.
If you release it in Ussuri, then nothing needs to get done governance-wise... it's still considered a deliverable from the Neutron team.
I'd advise you to consider not releasing it in Victoria though, if we are not comfortable with its state and nobody picks it up between now and the victoria-2 milestone.
Hi,
On 20 Feb 2020, at 11:33, Thierry Carrez thierry@openstack.org wrote:
Akihiro Motoki wrote:
[...] I also would like to note that 'deprecation' does not mean we stop new releases. neutron-lbaas continued to cut releases even after the deprecation is enabled. IIRC neutron-lbaas was marked as deprecated Jan 2018 around the queens release and it was released till Stein. neutron-fwaas is being marked as deprecated, so I think we still need to release it until neutron-fwaas was retired in the master branch.
If you release it in Ussuri, then nothing needs to get done governance-wise... it's still considered a deliverable from the Neutron team.
I'd advise you to consider not releasing it in Victoria though, if we are not comfortable with its state and nobody picks it up between now and the victoria-2 milestone.
Thx. I though that we will for sure release it in Ussuri still. And it’s good idea to add such note about not releasing for Victoria if there will be still nobody to take care of it. I will add it to the deprecation warning. And in such case, I think that deprecation process which worked for LBaaS and which Nate pointed to, will be good to apply here but in Victoria cycle, not now, right?
-- Thierry Carrez (ttx)
— Slawek Kaplonski Senior software engineer Red Hat
Slawek Kaplonski wrote:
Hi,
On 20 Feb 2020, at 11:33, Thierry Carrez thierry@openstack.org wrote:
Akihiro Motoki wrote:
[...] I also would like to note that 'deprecation' does not mean we stop new releases. neutron-lbaas continued to cut releases even after the deprecation is enabled. IIRC neutron-lbaas was marked as deprecated Jan 2018 around the queens release and it was released till Stein. neutron-fwaas is being marked as deprecated, so I think we still need to release it until neutron-fwaas was retired in the master branch.
If you release it in Ussuri, then nothing needs to get done governance-wise... it's still considered a deliverable from the Neutron team.
I'd advise you to consider not releasing it in Victoria though, if we are not comfortable with its state and nobody picks it up between now and the victoria-2 milestone.
Thx. I though that we will for sure release it in Ussuri still. And it’s good idea to add such note about not releasing for Victoria if there will be still nobody to take care of it. I will add it to the deprecation warning. And in such case, I think that deprecation process which worked for LBaaS and which Nate pointed to, will be good to apply here but in Victoria cycle, not now, right?
Yes.
participants (8)
-
Akihiro Motoki
-
Eric K. Miller
-
Jeremy Stanley
-
Mauricio Tavares
-
Nate Johnston
-
Sean Mooney
-
Slawek Kaplonski
-
Thierry Carrez