Hi All, Have created a BP for the task. Please review it. https://blueprints.launchpad.net/heat/+spec/lbaasv2-suport
Thanks Banashankar On Tue, Sep 29, 2015 at 2:47 AM, Sergey Kraynev <skray...@mirantis.com> wrote: > Guys, my apologize for the delay. Now I can give answers. > > Stephen, Heat meeting scheduled on Wednesday. ( > https://wiki.openstack.org/wiki/Meetings/HeatAgenda) > > Result was really short and clear: use suggested in this mail thread > naming OS::LBaaS::* and add new resources. > I personally think, that this work requires separate BP + spec. So some > corner cases about similar resources may be discussed on review for this > specification. > > Thank you guys, for the raising this idea. We definitely should provide > new "fresh" resources for users :) > > Regards, > Sergey. > > On 25 September 2015 at 01:30, Doug Wiegley <doug...@parksidesoftware.com> > wrote: > >> Hi Sergey, >> >> I agree with the previous comments here. While supporting several APIs at >> once, with one set of objects, is a noble goal, in this case, the object >> relationships are *completely* different. Unless you want to get into the >> business of redefining your own higher-level API abstractions in all cases, >> that general strategy for all things will be awkward and difficult. >> >> Some API changes lend themselves well to object reuse abstractions. Some >> don’t. Lbaas v2 is definitely the latter, IMO. >> >> What was the result of your meeting discussion? (*goes to grub around in >> eavesdrop logs after typing this.*) >> >> Thanks, >> doug >> >> >> >> On Sep 23, 2015, at 12:09 PM, Sergey Kraynev <skray...@mirantis.com> >> wrote: >> >> Guys. I happy, that you already discussed it here :) >> However, I'd like to raise same question on our Heat IRC meeting. >> Probably we should define some common concepts, because I think, that >> lbaas is not single example of service with >> several APIs. >> I will post update in this thread later (after meeting). >> >> Regards, >> Sergey. >> >> On 23 September 2015 at 14:37, Fox, Kevin M <kevin....@pnnl.gov> wrote: >> >>> Seperate ns would work great. >>> >>> Thanks, >>> Kevin >>> >>> ------------------------------ >>> *From:* Banashankar KV >>> *Sent:* Tuesday, September 22, 2015 9:14:35 PM >>> >>> *To:* OpenStack Development Mailing List (not for usage questions) >>> *Subject:* Re: [openstack-dev] [neutron][lbaas] - Heat support for >>> LbaasV2 >>> >>> What you think about separating both of them with the name as Doug >>> mentioned. In future if we want to get rid of the v1 we can just remove >>> that namespace. Everything will be clean. >>> >>> Thanks >>> Banashankar >>> >>> >>> On Tue, Sep 22, 2015 at 6:01 PM, Fox, Kevin M <kevin....@pnnl.gov> >>> wrote: >>> >>>> As I understand it, loadbalancer in v2 is more like pool was in v1. Can >>>> we make it such that if you are using the loadbalancer resource and have >>>> the mandatory v2 properties that it tries to use v2 api, otherwise its a v1 >>>> resource? PoolMember should be ok being the same. It just needs to call v1 >>>> or v2 depending on if the lb its pointing at is v1 or v2. Is monitor's api >>>> different between them? Can it be like pool member? >>>> >>>> Thanks, >>>> Kevin >>>> >>>> ------------------------------ >>>> *From:* Brandon Logan >>>> *Sent:* Tuesday, September 22, 2015 5:39:03 PM >>>> >>>> *To:* openstack-dev@lists.openstack.org >>>> *Subject:* Re: [openstack-dev] [neutron][lbaas] - Heat support for >>>> LbaasV2 >>>> >>>> So for the API v1s api is of the structure: >>>> >>>> <neutron-endpoint>/lb/(vip|pool|member|health_monitor) >>>> >>>> V2s is: >>>> <neutron-endpoint>/lbaas/(loadbalancer|listener|pool|healthmonitor) >>>> >>>> member is a child of pool, so it would go down one level. >>>> >>>> The only difference is the lb for v1 and lbaas for v2. Not sure if that >>>> is enough of a different. >>>> >>>> Thanks, >>>> Brandon >>>> On Tue, 2015-09-22 at 23:48 +0000, Fox, Kevin M wrote: >>>> > Thats the problem. :/ >>>> > >>>> > I can't think of a way to have them coexist without: breaking old >>>> > templates, including v2 in the name, or having a flag on the resource >>>> > saying the version is v2. And as an app developer I'd rather not have >>>> > my existing templates break. >>>> > >>>> > I haven't compared the api's at all, but is there a required field of >>>> > v2 that is different enough from v1 that by its simple existence in >>>> > the resource you can tell a v2 from a v1 object? Would something like >>>> > that work? PoolMember wouldn't have to change, the same resource could >>>> > probably work for whatever lb it was pointing at I'm guessing. >>>> > >>>> > Thanks, >>>> > Kevin >>>> > >>>> > >>>> > >>>> > ______________________________________________________________________ >>>> > From: Banashankar KV [banvee...@gmail.com] >>>> > Sent: Tuesday, September 22, 2015 4:40 PM >>>> > To: OpenStack Development Mailing List (not for usage questions) >>>> > Subject: Re: [openstack-dev] [neutron][lbaas] - Heat support for >>>> > LbaasV2 >>>> > >>>> > >>>> > >>>> > Ok, sounds good. So now the question is how should we name the new V2 >>>> > resources ? >>>> > >>>> > >>>> > >>>> > Thanks >>>> > Banashankar >>>> > >>>> > >>>> > >>>> > On Tue, Sep 22, 2015 at 4:33 PM, Fox, Kevin M <kevin....@pnnl.gov> >>>> > wrote: >>>> > Yes, hence the need to support the v2 resources as seperate >>>> > things. Then I can rewrite the templates to include the new >>>> > resources rather then the old resources as appropriate. IE, it >>>> > will be a porting effort to rewrite them. Then do a heat >>>> > update on the stack to migrate it from lbv1 to lbv2. Since >>>> > they are different resources, it should create the new and >>>> > delete the old. >>>> > >>>> > Thanks, >>>> > Kevin >>>> > >>>> > >>>> > ______________________________________________________________ >>>> > From: Banashankar KV [banvee...@gmail.com] >>>> > Sent: Tuesday, September 22, 2015 4:16 PM >>>> > >>>> > To: OpenStack Development Mailing List (not for usage >>>> > questions) >>>> > Subject: Re: [openstack-dev] [neutron][lbaas] - Heat support >>>> > for LbaasV2 >>>> > >>>> > >>>> > >>>> > >>>> > But I think, V2 has introduced some new components and whole >>>> > association of the resources with each other is changed, we >>>> > should be still able to do what Kevin has mentioned ? >>>> > >>>> > Thanks >>>> > Banashankar >>>> > >>>> > >>>> > >>>> > On Tue, Sep 22, 2015 at 3:39 PM, Fox, Kevin M >>>> > <kevin....@pnnl.gov> wrote: >>>> > There needs to be a way to have both v1 and v2 >>>> > supported in one engine.... >>>> > >>>> > Say I have templates that use v1 already in existence >>>> > (I do), and I want to be able to heat stack update on >>>> > them one at a time to v2. This will replace the v1 lb >>>> > with v2, migrating the floating ip from the v1 lb to >>>> > the v2 one. This gives a smoothish upgrade path. >>>> > >>>> > Thanks, >>>> > Kevin >>>> > ________________________________________ >>>> > From: Brandon Logan [brandon.lo...@rackspace.com] >>>> > Sent: Tuesday, September 22, 2015 3:22 PM >>>> > To: openstack-dev@lists.openstack.org >>>> > Subject: Re: [openstack-dev] [neutron][lbaas] - Heat >>>> > support for LbaasV2 >>>> > >>>> > Well I'd hate to have the V2 postfix on it because V1 >>>> > will be deprecated >>>> > and removed, which means the V2 being there would be >>>> > lame. Is there any >>>> > kind of precedent set for for how to handle this? >>>> > >>>> > Thanks, >>>> > Brandon >>>> > On Tue, 2015-09-22 at 14:49 -0700, Banashankar KV >>>> > wrote: >>>> > > So are we thinking of making it as ? >>>> > > OS::Neutron::LoadBalancerV2 >>>> > > >>>> > > OS::Neutron::ListenerV2 >>>> > > >>>> > > OS::Neutron::PoolV2 >>>> > > >>>> > > OS::Neutron::PoolMemberV2 >>>> > > >>>> > > OS::Neutron::HealthMonitorV2 >>>> > > >>>> > > >>>> > > >>>> > > and add all those into the loadbalancer.py of heat >>>> > engine ? >>>> > > >>>> > > Thanks >>>> > > Banashankar >>>> > > >>>> > > >>>> > > >>>> > > On Tue, Sep 22, 2015 at 12:52 PM, Sergey Kraynev >>>> > > <skray...@mirantis.com> wrote: >>>> > > Brandon. >>>> > > >>>> > > >>>> > > As I understand we v1 and v2 have >>>> > differences also in list of >>>> > > objects and also in relationships between >>>> > them. >>>> > > So I don't think that it will be easy to >>>> > upgrade old resources >>>> > > (unfortunately). >>>> > > I'd agree with second Kevin's suggestion >>>> > about implementation >>>> > > new resources in this case. >>>> > > >>>> > > >>>> > > I see, that a lot of guys, who wants to help >>>> > with it :) And I >>>> > > suppose, that me and Rabi Mishra may try to >>>> > help with it, >>>> > > because we was involvement in implementation >>>> > of v1 resources >>>> > > in Heat. >>>> > > Follow the list of v1 lbaas resources in >>>> > Heat: >>>> > > >>>> > > >>>> > > >>>> > >>>> http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::LoadBalancer >>>> > > >>>> > >>>> http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::Pool >>>> > > >>>> > > >>>> > >>>> http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::PoolMember >>>> > > >>>> > > >>>> > >>>> http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::HealthMonitor >>>> > > >>>> > > >>>> > > >>>> > > Also, I suppose, that it may be discussed >>>> > during summit >>>> > > talks :) >>>> > > Will add to etherpad with potential >>>> > sessions. >>>> > > >>>> > > >>>> > > >>>> > > Regards, >>>> > > Sergey. >>>> > > >>>> > > On 22 September 2015 at 22:27, Brandon Logan >>>> > > <brandon.lo...@rackspace.com> wrote: >>>> > > There is some overlap, but there was >>>> > some incompatible >>>> > > differences when >>>> > > we started designing v2. I'm sure >>>> > the same issues >>>> > > will arise this time >>>> > > around so new resources sounds like >>>> > the path to go. >>>> > > However, I do not >>>> > > know much about Heat and the >>>> > resources so I'm speaking >>>> > > on a very >>>> > > uneducated level here. >>>> > > >>>> > > Thanks, >>>> > > Brandon >>>> > > On Tue, 2015-09-22 at 18:38 +0000, >>>> > Fox, Kevin M wrote: >>>> > > > We're using the v1 resources... >>>> > > > >>>> > > > If the v2 ones are compatible and >>>> > can seamlessly >>>> > > upgrade, great >>>> > > > >>>> > > > Otherwise, make new ones please. >>>> > > > >>>> > > > Thanks, >>>> > > > Kevin >>>> > > > >>>> > > > >>>> > > >>>> > >>>> ______________________________________________________________________ >>>> > > > From: Banashankar KV >>>> > [banvee...@gmail.com] >>>> > > > Sent: Tuesday, September 22, 2015 >>>> > 10:07 AM >>>> > > > To: OpenStack Development Mailing >>>> > List (not for >>>> > > usage questions) >>>> > > > Subject: Re: [openstack-dev] >>>> > [neutron][lbaas] - Heat >>>> > > support for >>>> > > > LbaasV2 >>>> > > > >>>> > > > >>>> > > > >>>> > > > Hi Brandon, >>>> > > > Work in progress, but need some >>>> > input on the way we >>>> > > want them, like >>>> > > > replace the existing lbaasv1 or we >>>> > still need to >>>> > > support them ? >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > Thanks >>>> > > > Banashankar >>>> > > > >>>> > > > >>>> > > > >>>> > > > On Tue, Sep 22, 2015 at 9:18 AM, >>>> > Brandon Logan >>>> > > > <brandon.lo...@rackspace.com> >>>> > wrote: >>>> > > > Hi Banashankar, >>>> > > > I think it'd be great if >>>> > you got this going. >>>> > > One of those >>>> > > > things we >>>> > > > want to have and people >>>> > ask for but has >>>> > > always gotten a lower >>>> > > > priority >>>> > > > due to the critical things >>>> > needed. >>>> > > > >>>> > > > Thanks, >>>> > > > Brandon >>>> > > > On Mon, 2015-09-21 at >>>> > 17:57 -0700, >>>> > > Banashankar KV wrote: >>>> > > > > Hi All, >>>> > > > > I was thinking of >>>> > starting the work on >>>> > > heat to support >>>> > > > LBaasV2, Is >>>> > > > > there any concerns about >>>> > that? >>>> > > > > >>>> > > > > >>>> > > > > I don't know if it is >>>> > the right time to >>>> > > bring this up :D . >>>> > > > > >>>> > > > > Thanks, >>>> > > > > Banashankar (bana_k) >>>> > > > > >>>> > > > > >>>> > > > >>>> > > > > >>>> > > > >>>> > > >>>> > >>>> __________________________________________________________________________ >>>> > > > > 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 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 >>>> > 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 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 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 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 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://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 > >
__________________________________________________________________________ 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
