Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap
Octavia is using own DB and LBaaS v2 has his own. Because of that like Michael said we’re working on aligning this DBs and we’re planning to provide migration mechanism. Cheers, Lubosz Kosnik Cloud Software Engineer OSIC On Nov 10, 2016, at 1:13 AM, Gary Kotton mailto:gkot...@vmware.com>> wrote: Will the same DB be maintained or will the LBaaS DB be moved to that of Octavia. I am really concerned about this and I feel that it will cause production problems. From: Kevin Benton mailto:ke...@benton.pub>> Reply-To: OpenStack List mailto:openstack-dev@lists.openstack.org>> Date: Wednesday, November 9, 2016 at 11:43 PM To: OpenStack List mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap The people working on the migration are ensuring API compatibility and are even leaving in a shim on the Neutron side for some time so you don't even have to change endpoints initially. It should be a seamless change. On Wed, Nov 9, 2016 at 12:28 PM, Fox, Kevin M mailto:kevin@pnnl.gov>> wrote: Just please don't make this a lbv3 thing that completely breaks compatibility of existing lb's yet again. If its just an "point url endpoint from thing like x to thing like y" in one place, thats ok. I still have v1 lb's in existence though I have to deal with and a backwards incompatible v3 would just cause me to abandon lbaas all together I think as it would show the lbaas stuff is just not maintainable. Thanks, Kevin From: Armando M. [arma...@gmail.com<mailto:arma...@gmail.com>] Sent: Wednesday, November 09, 2016 8:05 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap On 9 November 2016 at 05:50, Gary Kotton mailto:gkot...@vmware.com>> wrote: Hi, What about neutron-lbaas project? Is this project still alive and kicking to the merge is done or are we going to continue to maintain it? I feel like we are between a rock and a hard place here. LBaaS is in production and it is not clear the migration process. Will Octavia have the same DB models as LBaaS or will there be a migration? Sorry for the pessimism but I feel that things are very unclear and that we cannot even indicate to our community/consumers what to use/expect. Thanks Gary http://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html On 11/8/16, 1:36 AM, "Michael Johnson" mailto:johnso...@gmail.com>> wrote: Ocata LBaaS retrospective and next steps recap -- This session lightly touched on the work in the newton cycle, but primarily focused on planning for the Ocata release and the LBaaS spin out of neutron and merge into the octavia project [1]. Notes were captured on the etherpad [1]. The focus of work for Ocata in neutron-lbaas and octavia will be on the spin out/merge and not new features. Work has started on merging neutron-lbaas into the octavia project with API sorting/pagination, quota support, keystone integration, neutron-lbaas driver shim, and documentation updates. Work is still needed for policy support, the API shim to handle capability gaps (example: stats are by listener in octavia, but by load balancer in neturon-lbaas), neutron api proxy, a database migration script from the neutron database to the octavia database for existing non-octavia load balancers, and adding the "bug for bug" neutron-lbaas v2 API to the octavia API server. The room agreed that since we will have a shim/proxy in neutron for some time, updating the OpenStack client can be deferred to a future cycle. There is a lot of concern about Ocata being a short cycle and the amount of work to be done. There is hope that additional resources will help out with this task to allow us to complete the spin out/merge for Ocata. We discussed the current state of the active/active topology patches and agreed that it is unlikely this will merge in Ocata. There are a lot of open comments and work to do on the patches. It appears that these patches may have been created against an old release and require significant updating. Finally there was a question about when octavia would implement metadata tags. When we dug into the need for the tags we found that what was really wanted is a full implementation of the flavors framework [3] [4]. Some vendors expressed interest in finishing the flavors framework for Octavia. Thank you to everyone that participated in our design session and etherpad. Michael [1] https://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neut
Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap
Hi Gary, The LBaaS DB table contents will be moved into the Octavia database as part of the migration process/tool. Michael On Wed, Nov 9, 2016 at 11:13 PM, Gary Kotton wrote: > Will the same DB be maintained or will the LBaaS DB be moved to that of > Octavia. I am really concerned about this and I feel that it will cause > production problems. > > > > From: Kevin Benton > Reply-To: OpenStack List > Date: Wednesday, November 9, 2016 at 11:43 PM > To: OpenStack List > > > Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS > retrospective and next steps recap > > > > The people working on the migration are ensuring API compatibility and are > even leaving in a shim on the Neutron side for some time so you don't even > have to change endpoints initially. It should be a seamless change. > > > > On Wed, Nov 9, 2016 at 12:28 PM, Fox, Kevin M wrote: > > Just please don't make this a lbv3 thing that completely breaks > compatibility of existing lb's yet again. If its just an "point url endpoint > from thing like x to thing like y" in one place, thats ok. I still have v1 > lb's in existence though I have to deal with and a backwards incompatible v3 > would just cause me to abandon lbaas all together I think as it would show > the lbaas stuff is just not maintainable. > > Thanks, > Kevin > > > > From: Armando M. [arma...@gmail.com] > Sent: Wednesday, November 09, 2016 8:05 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS > retrospective and next steps recap > > > > > > On 9 November 2016 at 05:50, Gary Kotton wrote: > > Hi, > What about neutron-lbaas project? Is this project still alive and kicking to > the merge is done or are we going to continue to maintain it? I feel like we > are between a rock and a hard place here. LBaaS is in production and it is > not clear the migration process. Will Octavia have the same DB models as > LBaaS or will there be a migration? > Sorry for the pessimism but I feel that things are very unclear and that we > cannot even indicate to our community/consumers what to use/expect. > Thanks > Gary > > > > http://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html > > > > > On 11/8/16, 1:36 AM, "Michael Johnson" wrote: > > Ocata LBaaS retrospective and next steps recap > -- > > This session lightly touched on the work in the newton cycle, but > primarily focused on planning for the Ocata release and the LBaaS spin > out of neutron and merge into the octavia project [1]. Notes were > captured on the etherpad [1]. > > The focus of work for Ocata in neutron-lbaas and octavia will be on > the spin out/merge and not new features. > > Work has started on merging neutron-lbaas into the octavia project > with API sorting/pagination, quota support, keystone integration, > neutron-lbaas driver shim, and documentation updates. Work is still > needed for policy support, the API shim to handle capability gaps > (example: stats are by listener in octavia, but by load balancer in > neturon-lbaas), neutron api proxy, a database migration script from > the neutron database to the octavia database for existing non-octavia > load balancers, and adding the "bug for bug" neutron-lbaas v2 API to > the octavia API server. > > The room agreed that since we will have a shim/proxy in neutron for > some time, updating the OpenStack client can be deferred to a future > cycle. > > There is a lot of concern about Ocata being a short cycle and the > amount of work to be done. There is hope that additional resources > will help out with this task to allow us to complete the spin > out/merge for Ocata. > > We discussed the current state of the active/active topology patches > and agreed that it is unlikely this will merge in Ocata. There are a > lot of open comments and work to do on the patches. It appears that > these patches may have been created against an old release and require > significant updating. > > Finally there was a question about when octavia would implement > metadata tags. When we dug into the need for the tags we found that > what was really wanted is a full implementation of the flavors > framework [3] [4]. Some vendors expressed interest in finishing the > flavors framework for Octavia. > > Thank you to everyone th
Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap
Will the same DB be maintained or will the LBaaS DB be moved to that of Octavia. I am really concerned about this and I feel that it will cause production problems. From: Kevin Benton Reply-To: OpenStack List Date: Wednesday, November 9, 2016 at 11:43 PM To: OpenStack List Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap The people working on the migration are ensuring API compatibility and are even leaving in a shim on the Neutron side for some time so you don't even have to change endpoints initially. It should be a seamless change. On Wed, Nov 9, 2016 at 12:28 PM, Fox, Kevin M mailto:kevin@pnnl.gov>> wrote: Just please don't make this a lbv3 thing that completely breaks compatibility of existing lb's yet again. If its just an "point url endpoint from thing like x to thing like y" in one place, thats ok. I still have v1 lb's in existence though I have to deal with and a backwards incompatible v3 would just cause me to abandon lbaas all together I think as it would show the lbaas stuff is just not maintainable. Thanks, Kevin From: Armando M. [arma...@gmail.com<mailto:arma...@gmail.com>] Sent: Wednesday, November 09, 2016 8:05 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap On 9 November 2016 at 05:50, Gary Kotton mailto:gkot...@vmware.com>> wrote: Hi, What about neutron-lbaas project? Is this project still alive and kicking to the merge is done or are we going to continue to maintain it? I feel like we are between a rock and a hard place here. LBaaS is in production and it is not clear the migration process. Will Octavia have the same DB models as LBaaS or will there be a migration? Sorry for the pessimism but I feel that things are very unclear and that we cannot even indicate to our community/consumers what to use/expect. Thanks Gary http://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html On 11/8/16, 1:36 AM, "Michael Johnson" mailto:johnso...@gmail.com>> wrote: Ocata LBaaS retrospective and next steps recap -- This session lightly touched on the work in the newton cycle, but primarily focused on planning for the Ocata release and the LBaaS spin out of neutron and merge into the octavia project [1]. Notes were captured on the etherpad [1]. The focus of work for Ocata in neutron-lbaas and octavia will be on the spin out/merge and not new features. Work has started on merging neutron-lbaas into the octavia project with API sorting/pagination, quota support, keystone integration, neutron-lbaas driver shim, and documentation updates. Work is still needed for policy support, the API shim to handle capability gaps (example: stats are by listener in octavia, but by load balancer in neturon-lbaas), neutron api proxy, a database migration script from the neutron database to the octavia database for existing non-octavia load balancers, and adding the "bug for bug" neutron-lbaas v2 API to the octavia API server. The room agreed that since we will have a shim/proxy in neutron for some time, updating the OpenStack client can be deferred to a future cycle. There is a lot of concern about Ocata being a short cycle and the amount of work to be done. There is hope that additional resources will help out with this task to allow us to complete the spin out/merge for Ocata. We discussed the current state of the active/active topology patches and agreed that it is unlikely this will merge in Ocata. There are a lot of open comments and work to do on the patches. It appears that these patches may have been created against an old release and require significant updating. Finally there was a question about when octavia would implement metadata tags. When we dug into the need for the tags we found that what was really wanted is a full implementation of the flavors framework [3] [4]. Some vendors expressed interest in finishing the flavors framework for Octavia. Thank you to everyone that participated in our design session and etherpad. Michael [1] https://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html [2] https://etherpad.openstack.org/p/ocata-neutron-octavia-lbaas-session [3] https://specs.openstack.org/openstack/neutron-specs/specs/mitaka/neutron-flavor-framework-templates.html [4] https://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron-flavor-framework.html __ OpenStack Development M
Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap
Kevin, Yep, totally understand. This is not a V3, it is simply moving the API from running under neutron to running under the octavia API process. It will still be the LBaaSv2 API, just a new endpoint (though the old endpoint will work for some time into the future). Michael On Wed, Nov 9, 2016 at 12:28 PM, Fox, Kevin M wrote: > Just please don't make this a lbv3 thing that completely breaks > compatibility of existing lb's yet again. If its just an "point url endpoint > from thing like x to thing like y" in one place, thats ok. I still have v1 > lb's in existence though I have to deal with and a backwards incompatible v3 > would just cause me to abandon lbaas all together I think as it would show > the lbaas stuff is just not maintainable. > > Thanks, > Kevin > > From: Armando M. [arma...@gmail.com] > Sent: Wednesday, November 09, 2016 8:05 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS > retrospective and next steps recap > > > > On 9 November 2016 at 05:50, Gary Kotton wrote: >> >> Hi, >> What about neutron-lbaas project? Is this project still alive and kicking >> to the merge is done or are we going to continue to maintain it? I feel like >> we are between a rock and a hard place here. LBaaS is in production and it >> is not clear the migration process. Will Octavia have the same DB models as >> LBaaS or will there be a migration? >> Sorry for the pessimism but I feel that things are very unclear and that >> we cannot even indicate to our community/consumers what to use/expect. >> Thanks >> Gary > > > http://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html > >> >> >> On 11/8/16, 1:36 AM, "Michael Johnson" wrote: >> >> Ocata LBaaS retrospective and next steps recap >> -- >> >> This session lightly touched on the work in the newton cycle, but >> primarily focused on planning for the Ocata release and the LBaaS spin >> out of neutron and merge into the octavia project [1]. Notes were >> captured on the etherpad [1]. >> >> The focus of work for Ocata in neutron-lbaas and octavia will be on >> the spin out/merge and not new features. >> >> Work has started on merging neutron-lbaas into the octavia project >> with API sorting/pagination, quota support, keystone integration, >> neutron-lbaas driver shim, and documentation updates. Work is still >> needed for policy support, the API shim to handle capability gaps >> (example: stats are by listener in octavia, but by load balancer in >> neturon-lbaas), neutron api proxy, a database migration script from >> the neutron database to the octavia database for existing non-octavia >> load balancers, and adding the "bug for bug" neutron-lbaas v2 API to >> the octavia API server. >> >> The room agreed that since we will have a shim/proxy in neutron for >> some time, updating the OpenStack client can be deferred to a future >> cycle. >> >> There is a lot of concern about Ocata being a short cycle and the >> amount of work to be done. There is hope that additional resources >> will help out with this task to allow us to complete the spin >> out/merge for Ocata. >> >> We discussed the current state of the active/active topology patches >> and agreed that it is unlikely this will merge in Ocata. There are a >> lot of open comments and work to do on the patches. It appears that >> these patches may have been created against an old release and require >> significant updating. >> >> Finally there was a question about when octavia would implement >> metadata tags. When we dug into the need for the tags we found that >> what was really wanted is a full implementation of the flavors >> framework [3] [4]. Some vendors expressed interest in finishing the >> flavors framework for Octavia. >> >> Thank you to everyone that participated in our design session and >> etherpad. >> >> Michael >> >> [1] >> https://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html >> [2] >> https://etherpad.openstack.org/p/ocata-neutron-octavia-lbaas-session >> [3] >> https://specs.openstack.org/openstack/neutron-specs/specs/mitaka/neutron-flavor-framework-templates
Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap
Ok. cool. thanks. :) Kevin From: Kevin Benton [ke...@benton.pub] Sent: Wednesday, November 09, 2016 1:43 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap The people working on the migration are ensuring API compatibility and are even leaving in a shim on the Neutron side for some time so you don't even have to change endpoints initially. It should be a seamless change. On Wed, Nov 9, 2016 at 12:28 PM, Fox, Kevin M mailto:kevin@pnnl.gov>> wrote: Just please don't make this a lbv3 thing that completely breaks compatibility of existing lb's yet again. If its just an "point url endpoint from thing like x to thing like y" in one place, thats ok. I still have v1 lb's in existence though I have to deal with and a backwards incompatible v3 would just cause me to abandon lbaas all together I think as it would show the lbaas stuff is just not maintainable. Thanks, Kevin From: Armando M. [arma...@gmail.com<mailto:arma...@gmail.com>] Sent: Wednesday, November 09, 2016 8:05 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap On 9 November 2016 at 05:50, Gary Kotton mailto:gkot...@vmware.com>> wrote: Hi, What about neutron-lbaas project? Is this project still alive and kicking to the merge is done or are we going to continue to maintain it? I feel like we are between a rock and a hard place here. LBaaS is in production and it is not clear the migration process. Will Octavia have the same DB models as LBaaS or will there be a migration? Sorry for the pessimism but I feel that things are very unclear and that we cannot even indicate to our community/consumers what to use/expect. Thanks Gary http://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html On 11/8/16, 1:36 AM, "Michael Johnson" mailto:johnso...@gmail.com>> wrote: Ocata LBaaS retrospective and next steps recap -- This session lightly touched on the work in the newton cycle, but primarily focused on planning for the Ocata release and the LBaaS spin out of neutron and merge into the octavia project [1]. Notes were captured on the etherpad [1]. The focus of work for Ocata in neutron-lbaas and octavia will be on the spin out/merge and not new features. Work has started on merging neutron-lbaas into the octavia project with API sorting/pagination, quota support, keystone integration, neutron-lbaas driver shim, and documentation updates. Work is still needed for policy support, the API shim to handle capability gaps (example: stats are by listener in octavia, but by load balancer in neturon-lbaas), neutron api proxy, a database migration script from the neutron database to the octavia database for existing non-octavia load balancers, and adding the "bug for bug" neutron-lbaas v2 API to the octavia API server. The room agreed that since we will have a shim/proxy in neutron for some time, updating the OpenStack client can be deferred to a future cycle. There is a lot of concern about Ocata being a short cycle and the amount of work to be done. There is hope that additional resources will help out with this task to allow us to complete the spin out/merge for Ocata. We discussed the current state of the active/active topology patches and agreed that it is unlikely this will merge in Ocata. There are a lot of open comments and work to do on the patches. It appears that these patches may have been created against an old release and require significant updating. Finally there was a question about when octavia would implement metadata tags. When we dug into the need for the tags we found that what was really wanted is a full implementation of the flavors framework [3] [4]. Some vendors expressed interest in finishing the flavors framework for Octavia. Thank you to everyone that participated in our design session and etherpad. Michael [1] https://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html [2] https://etherpad.openstack.org/p/ocata-neutron-octavia-lbaas-session [3] https://specs.openstack.org/openstack/neutron-specs/specs/mitaka/neutron-flavor-framework-templates.html [4] https://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron-flavor-framework.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstac
Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap
The people working on the migration are ensuring API compatibility and are even leaving in a shim on the Neutron side for some time so you don't even have to change endpoints initially. It should be a seamless change. On Wed, Nov 9, 2016 at 12:28 PM, Fox, Kevin M wrote: > Just please don't make this a lbv3 thing that completely breaks > compatibility of existing lb's yet again. If its just an "point url > endpoint from thing like x to thing like y" in one place, thats ok. I still > have v1 lb's in existence though I have to deal with and a backwards > incompatible v3 would just cause me to abandon lbaas all together I think > as it would show the lbaas stuff is just not maintainable. > > Thanks, > Kevin > -- > *From:* Armando M. [arma...@gmail.com] > *Sent:* Wednesday, November 09, 2016 8:05 AM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS > retrospective and next steps recap > > > > On 9 November 2016 at 05:50, Gary Kotton wrote: > >> Hi, >> What about neutron-lbaas project? Is this project still alive and kicking >> to the merge is done or are we going to continue to maintain it? I feel >> like we are between a rock and a hard place here. LBaaS is in production >> and it is not clear the migration process. Will Octavia have the same DB >> models as LBaaS or will there be a migration? >> Sorry for the pessimism but I feel that things are very unclear and that >> we cannot even indicate to our community/consumers what to use/expect. >> Thanks >> Gary >> > > http://specs.openstack.org/openstack/neutron-specs/specs/ > newton/kill-neutron-lbaas.html > > >> >> On 11/8/16, 1:36 AM, "Michael Johnson" wrote: >> >> Ocata LBaaS retrospective and next steps recap >> >> -- >> >> This session lightly touched on the work in the newton cycle, but >> primarily focused on planning for the Ocata release and the LBaaS spin >> out of neutron and merge into the octavia project [1]. Notes were >> captured on the etherpad [1]. >> >> The focus of work for Ocata in neutron-lbaas and octavia will be on >> the spin out/merge and not new features. >> >> Work has started on merging neutron-lbaas into the octavia project >> with API sorting/pagination, quota support, keystone integration, >> neutron-lbaas driver shim, and documentation updates. Work is still >> needed for policy support, the API shim to handle capability gaps >> (example: stats are by listener in octavia, but by load balancer in >> neturon-lbaas), neutron api proxy, a database migration script from >> the neutron database to the octavia database for existing non-octavia >> load balancers, and adding the "bug for bug" neutron-lbaas v2 API to >> the octavia API server. >> >> The room agreed that since we will have a shim/proxy in neutron for >> some time, updating the OpenStack client can be deferred to a future >> cycle. >> >> There is a lot of concern about Ocata being a short cycle and the >> amount of work to be done. There is hope that additional resources >> will help out with this task to allow us to complete the spin >> out/merge for Ocata. >> >> We discussed the current state of the active/active topology patches >> and agreed that it is unlikely this will merge in Ocata. There are a >> lot of open comments and work to do on the patches. It appears that >> these patches may have been created against an old release and require >> significant updating. >> >> Finally there was a question about when octavia would implement >> metadata tags. When we dug into the need for the tags we found that >> what was really wanted is a full implementation of the flavors >> framework [3] [4]. Some vendors expressed interest in finishing the >> flavors framework for Octavia. >> >> Thank you to everyone that participated in our design session and >> etherpad. >> >> Michael >> >> [1] https://specs.openstack.org/openstack/neutron-specs/specs/ne >> wton/kill-neutron-lbaas.html >> [2] https://etherpad.openstack.org/p/ocata-neutron-octavia-lbaas >> -session >> [3] https://specs.openstack.org/openstack/neutron-specs/specs/mi >> taka/neutron-flavor-framework-templates.html >> [4] https://specs.ope
Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap
Just please don't make this a lbv3 thing that completely breaks compatibility of existing lb's yet again. If its just an "point url endpoint from thing like x to thing like y" in one place, thats ok. I still have v1 lb's in existence though I have to deal with and a backwards incompatible v3 would just cause me to abandon lbaas all together I think as it would show the lbaas stuff is just not maintainable. Thanks, Kevin From: Armando M. [arma...@gmail.com] Sent: Wednesday, November 09, 2016 8:05 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap On 9 November 2016 at 05:50, Gary Kotton mailto:gkot...@vmware.com>> wrote: Hi, What about neutron-lbaas project? Is this project still alive and kicking to the merge is done or are we going to continue to maintain it? I feel like we are between a rock and a hard place here. LBaaS is in production and it is not clear the migration process. Will Octavia have the same DB models as LBaaS or will there be a migration? Sorry for the pessimism but I feel that things are very unclear and that we cannot even indicate to our community/consumers what to use/expect. Thanks Gary http://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html On 11/8/16, 1:36 AM, "Michael Johnson" mailto:johnso...@gmail.com>> wrote: Ocata LBaaS retrospective and next steps recap -- This session lightly touched on the work in the newton cycle, but primarily focused on planning for the Ocata release and the LBaaS spin out of neutron and merge into the octavia project [1]. Notes were captured on the etherpad [1]. The focus of work for Ocata in neutron-lbaas and octavia will be on the spin out/merge and not new features. Work has started on merging neutron-lbaas into the octavia project with API sorting/pagination, quota support, keystone integration, neutron-lbaas driver shim, and documentation updates. Work is still needed for policy support, the API shim to handle capability gaps (example: stats are by listener in octavia, but by load balancer in neturon-lbaas), neutron api proxy, a database migration script from the neutron database to the octavia database for existing non-octavia load balancers, and adding the "bug for bug" neutron-lbaas v2 API to the octavia API server. The room agreed that since we will have a shim/proxy in neutron for some time, updating the OpenStack client can be deferred to a future cycle. There is a lot of concern about Ocata being a short cycle and the amount of work to be done. There is hope that additional resources will help out with this task to allow us to complete the spin out/merge for Ocata. We discussed the current state of the active/active topology patches and agreed that it is unlikely this will merge in Ocata. There are a lot of open comments and work to do on the patches. It appears that these patches may have been created against an old release and require significant updating. Finally there was a question about when octavia would implement metadata tags. When we dug into the need for the tags we found that what was really wanted is a full implementation of the flavors framework [3] [4]. Some vendors expressed interest in finishing the flavors framework for Octavia. Thank you to everyone that participated in our design session and etherpad. Michael [1] https://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html [2] https://etherpad.openstack.org/p/ocata-neutron-octavia-lbaas-session [3] https://specs.openstack.org/openstack/neutron-specs/specs/mitaka/neutron-flavor-framework-templates.html [4] https://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron-flavor-framework.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for us
Re: [openstack-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap
Hi Gary, Our intent is to merge neutron-lbaas into the Octavia project. When this is complete, the neutron-lbaas project will remain for some time as a light weight shim/proxy that provides the legacy neutron endpoint experience. The database models are already very similar to the existing neutron-lbaas models (by design) and we will finish aligning these as part of the merge work. For example, the names that were added to some objects will be added in the octavia database as well. We are also planing a migration from the neutron LBaaSv2 database to the octavia database. This should not impact existing running load balancers. Michael On Wed, Nov 9, 2016 at 5:50 AM, Gary Kotton wrote: > Hi, > What about neutron-lbaas project? Is this project still alive and kicking to > the merge is done or are we going to continue to maintain it? I feel like we > are between a rock and a hard place here. LBaaS is in production and it is > not clear the migration process. Will Octavia have the same DB models as > LBaaS or will there be a migration? > Sorry for the pessimism but I feel that things are very unclear and that we > cannot even indicate to our community/consumers what to use/expect. > Thanks > Gary > > On 11/8/16, 1:36 AM, "Michael Johnson" wrote: > > Ocata LBaaS retrospective and next steps recap > -- > > This session lightly touched on the work in the newton cycle, but > primarily focused on planning for the Ocata release and the LBaaS spin > out of neutron and merge into the octavia project [1]. Notes were > captured on the etherpad [1]. > > The focus of work for Ocata in neutron-lbaas and octavia will be on > the spin out/merge and not new features. > > Work has started on merging neutron-lbaas into the octavia project > with API sorting/pagination, quota support, keystone integration, > neutron-lbaas driver shim, and documentation updates. Work is still > needed for policy support, the API shim to handle capability gaps > (example: stats are by listener in octavia, but by load balancer in > neturon-lbaas), neutron api proxy, a database migration script from > the neutron database to the octavia database for existing non-octavia > load balancers, and adding the "bug for bug" neutron-lbaas v2 API to > the octavia API server. > > The room agreed that since we will have a shim/proxy in neutron for > some time, updating the OpenStack client can be deferred to a future > cycle. > > There is a lot of concern about Ocata being a short cycle and the > amount of work to be done. There is hope that additional resources > will help out with this task to allow us to complete the spin > out/merge for Ocata. > > We discussed the current state of the active/active topology patches > and agreed that it is unlikely this will merge in Ocata. There are a > lot of open comments and work to do on the patches. It appears that > these patches may have been created against an old release and require > significant updating. > > Finally there was a question about when octavia would implement > metadata tags. When we dug into the need for the tags we found that > what was really wanted is a full implementation of the flavors > framework [3] [4]. Some vendors expressed interest in finishing the > flavors framework for Octavia. > > Thank you to everyone that participated in our design session and > etherpad. > > Michael > > [1] > https://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html > [2] https://etherpad.openstack.org/p/ocata-neutron-octavia-lbaas-session > [3] > https://specs.openstack.org/openstack/neutron-specs/specs/mitaka/neutron-flavor-framework-templates.html > [4] > https://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron-flavor-framework.html > > __ > 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] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap
On 9 November 2016 at 05:50, Gary Kotton wrote: > Hi, > What about neutron-lbaas project? Is this project still alive and kicking > to the merge is done or are we going to continue to maintain it? I feel > like we are between a rock and a hard place here. LBaaS is in production > and it is not clear the migration process. Will Octavia have the same DB > models as LBaaS or will there be a migration? > Sorry for the pessimism but I feel that things are very unclear and that > we cannot even indicate to our community/consumers what to use/expect. > Thanks > Gary > http://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html > > On 11/8/16, 1:36 AM, "Michael Johnson" wrote: > > Ocata LBaaS retrospective and next steps recap > -- > > This session lightly touched on the work in the newton cycle, but > primarily focused on planning for the Ocata release and the LBaaS spin > out of neutron and merge into the octavia project [1]. Notes were > captured on the etherpad [1]. > > The focus of work for Ocata in neutron-lbaas and octavia will be on > the spin out/merge and not new features. > > Work has started on merging neutron-lbaas into the octavia project > with API sorting/pagination, quota support, keystone integration, > neutron-lbaas driver shim, and documentation updates. Work is still > needed for policy support, the API shim to handle capability gaps > (example: stats are by listener in octavia, but by load balancer in > neturon-lbaas), neutron api proxy, a database migration script from > the neutron database to the octavia database for existing non-octavia > load balancers, and adding the "bug for bug" neutron-lbaas v2 API to > the octavia API server. > > The room agreed that since we will have a shim/proxy in neutron for > some time, updating the OpenStack client can be deferred to a future > cycle. > > There is a lot of concern about Ocata being a short cycle and the > amount of work to be done. There is hope that additional resources > will help out with this task to allow us to complete the spin > out/merge for Ocata. > > We discussed the current state of the active/active topology patches > and agreed that it is unlikely this will merge in Ocata. There are a > lot of open comments and work to do on the patches. It appears that > these patches may have been created against an old release and require > significant updating. > > Finally there was a question about when octavia would implement > metadata tags. When we dug into the need for the tags we found that > what was really wanted is a full implementation of the flavors > framework [3] [4]. Some vendors expressed interest in finishing the > flavors framework for Octavia. > > Thank you to everyone that participated in our design session and > etherpad. > > Michael > > [1] https://specs.openstack.org/openstack/neutron-specs/specs/ > newton/kill-neutron-lbaas.html > [2] https://etherpad.openstack.org/p/ocata-neutron-octavia- > lbaas-session > [3] https://specs.openstack.org/openstack/neutron-specs/specs/ > mitaka/neutron-flavor-framework-templates.html > [4] https://specs.openstack.org/openstack/neutron-specs/specs/ > liberty/neutron-flavor-framework.html > > > __ > 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] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap
Hi, What about neutron-lbaas project? Is this project still alive and kicking to the merge is done or are we going to continue to maintain it? I feel like we are between a rock and a hard place here. LBaaS is in production and it is not clear the migration process. Will Octavia have the same DB models as LBaaS or will there be a migration? Sorry for the pessimism but I feel that things are very unclear and that we cannot even indicate to our community/consumers what to use/expect. Thanks Gary On 11/8/16, 1:36 AM, "Michael Johnson" wrote: Ocata LBaaS retrospective and next steps recap -- This session lightly touched on the work in the newton cycle, but primarily focused on planning for the Ocata release and the LBaaS spin out of neutron and merge into the octavia project [1]. Notes were captured on the etherpad [1]. The focus of work for Ocata in neutron-lbaas and octavia will be on the spin out/merge and not new features. Work has started on merging neutron-lbaas into the octavia project with API sorting/pagination, quota support, keystone integration, neutron-lbaas driver shim, and documentation updates. Work is still needed for policy support, the API shim to handle capability gaps (example: stats are by listener in octavia, but by load balancer in neturon-lbaas), neutron api proxy, a database migration script from the neutron database to the octavia database for existing non-octavia load balancers, and adding the "bug for bug" neutron-lbaas v2 API to the octavia API server. The room agreed that since we will have a shim/proxy in neutron for some time, updating the OpenStack client can be deferred to a future cycle. There is a lot of concern about Ocata being a short cycle and the amount of work to be done. There is hope that additional resources will help out with this task to allow us to complete the spin out/merge for Ocata. We discussed the current state of the active/active topology patches and agreed that it is unlikely this will merge in Ocata. There are a lot of open comments and work to do on the patches. It appears that these patches may have been created against an old release and require significant updating. Finally there was a question about when octavia would implement metadata tags. When we dug into the need for the tags we found that what was really wanted is a full implementation of the flavors framework [3] [4]. Some vendors expressed interest in finishing the flavors framework for Octavia. Thank you to everyone that participated in our design session and etherpad. Michael [1] https://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html [2] https://etherpad.openstack.org/p/ocata-neutron-octavia-lbaas-session [3] https://specs.openstack.org/openstack/neutron-specs/specs/mitaka/neutron-flavor-framework-templates.html [4] https://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron-flavor-framework.html __ 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] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap
thanks very much for the update! Cheers, Lingxian Kong (Larry) On Tue, Nov 8, 2016 at 12:36 PM, Michael Johnson wrote: > Ocata LBaaS retrospective and next steps recap > -- > > This session lightly touched on the work in the newton cycle, but > primarily focused on planning for the Ocata release and the LBaaS spin > out of neutron and merge into the octavia project [1]. Notes were > captured on the etherpad [1]. > > The focus of work for Ocata in neutron-lbaas and octavia will be on > the spin out/merge and not new features. > > Work has started on merging neutron-lbaas into the octavia project > with API sorting/pagination, quota support, keystone integration, > neutron-lbaas driver shim, and documentation updates. Work is still > needed for policy support, the API shim to handle capability gaps > (example: stats are by listener in octavia, but by load balancer in > neturon-lbaas), neutron api proxy, a database migration script from > the neutron database to the octavia database for existing non-octavia > load balancers, and adding the "bug for bug" neutron-lbaas v2 API to > the octavia API server. > > The room agreed that since we will have a shim/proxy in neutron for > some time, updating the OpenStack client can be deferred to a future > cycle. > > There is a lot of concern about Ocata being a short cycle and the > amount of work to be done. There is hope that additional resources > will help out with this task to allow us to complete the spin > out/merge for Ocata. > > We discussed the current state of the active/active topology patches > and agreed that it is unlikely this will merge in Ocata. There are a > lot of open comments and work to do on the patches. It appears that > these patches may have been created against an old release and require > significant updating. > > Finally there was a question about when octavia would implement > metadata tags. When we dug into the need for the tags we found that > what was really wanted is a full implementation of the flavors > framework [3] [4]. Some vendors expressed interest in finishing the > flavors framework for Octavia. > > Thank you to everyone that participated in our design session and etherpad. > > Michael > > [1] https://specs.openstack.org/openstack/neutron-specs/specs/ > newton/kill-neutron-lbaas.html > [2] https://etherpad.openstack.org/p/ocata-neutron-octavia-lbaas-session > [3] https://specs.openstack.org/openstack/neutron-specs/specs/ > mitaka/neutron-flavor-framework-templates.html > [4] https://specs.openstack.org/openstack/neutron-specs/specs/ > liberty/neutron-flavor-framework.html > > __ > 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-dev] [neutron] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap
Ocata LBaaS retrospective and next steps recap -- This session lightly touched on the work in the newton cycle, but primarily focused on planning for the Ocata release and the LBaaS spin out of neutron and merge into the octavia project [1]. Notes were captured on the etherpad [1]. The focus of work for Ocata in neutron-lbaas and octavia will be on the spin out/merge and not new features. Work has started on merging neutron-lbaas into the octavia project with API sorting/pagination, quota support, keystone integration, neutron-lbaas driver shim, and documentation updates. Work is still needed for policy support, the API shim to handle capability gaps (example: stats are by listener in octavia, but by load balancer in neturon-lbaas), neutron api proxy, a database migration script from the neutron database to the octavia database for existing non-octavia load balancers, and adding the "bug for bug" neutron-lbaas v2 API to the octavia API server. The room agreed that since we will have a shim/proxy in neutron for some time, updating the OpenStack client can be deferred to a future cycle. There is a lot of concern about Ocata being a short cycle and the amount of work to be done. There is hope that additional resources will help out with this task to allow us to complete the spin out/merge for Ocata. We discussed the current state of the active/active topology patches and agreed that it is unlikely this will merge in Ocata. There are a lot of open comments and work to do on the patches. It appears that these patches may have been created against an old release and require significant updating. Finally there was a question about when octavia would implement metadata tags. When we dug into the need for the tags we found that what was really wanted is a full implementation of the flavors framework [3] [4]. Some vendors expressed interest in finishing the flavors framework for Octavia. Thank you to everyone that participated in our design session and etherpad. Michael [1] https://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html [2] https://etherpad.openstack.org/p/ocata-neutron-octavia-lbaas-session [3] https://specs.openstack.org/openstack/neutron-specs/specs/mitaka/neutron-flavor-framework-templates.html [4] https://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron-flavor-framework.html __ 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
