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 <[email protected]> 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 <[email protected]> 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:* [email protected] >> *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 [[email protected]] >> > 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 <[email protected]> >> > 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 [[email protected]] >> > 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 >> > <[email protected]> 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 [[email protected]] >> > Sent: Tuesday, September 22, 2015 3:22 PM >> > To: [email protected] >> > 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 >> > > <[email protected]> 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 >> > > <[email protected]> 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 >> > [[email protected]] >> > > > 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 >> > > > <[email protected]> >> > 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: >> > > > >> > > >> > >> [email protected]?subject:unsubscribe >> > > > > >> > > > >> > > >> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > >> > > > >> > > >> > >> __________________________________________________________________________ >> > > > OpenStack Development >> > Mailing List (not for >> > > usage questions) >> > > > Unsubscribe: >> > > > >> > > >> > >> [email protected]?subject:unsubscribe >> > > > >> > > >> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > >> > > > >> > > > >> > > > >> > > >> > >> __________________________________________________________________________ >> > > > OpenStack Development Mailing List >> > (not for usage >> > > questions) >> > > > Unsubscribe: >> > > >> > >> [email protected]?subject:unsubscribe >> > > > >> > > >> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > >> > > >> > >> __________________________________________________________________________ >> > > OpenStack Development Mailing List >> > (not for usage >> > > questions) >> > > Unsubscribe: >> > > >> > >> [email protected]?subject:unsubscribe >> > > >> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > >> > > >> > > >> > > >> > > >> > >> __________________________________________________________________________ >> > > OpenStack Development Mailing List (not for >> > usage questions) >> > > Unsubscribe: >> > > >> > >> [email protected]?subject:unsubscribe >> > > >> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > >> > > >> > > >> > > >> > >> __________________________________________________________________________ >> > > OpenStack Development Mailing List (not for usage >> > questions) >> > > Unsubscribe: >> > >> [email protected]?subject:unsubscribe >> > > >> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > >> __________________________________________________________________________ >> > OpenStack Development Mailing List (not for usage >> > questions) >> > Unsubscribe: >> > >> [email protected]?subject:unsubscribe >> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > >> __________________________________________________________________________ >> > OpenStack Development Mailing List (not for usage >> > questions) >> > Unsubscribe: >> > >> [email protected]?subject:unsubscribe >> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > >> > >> > >> > >> __________________________________________________________________________ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> > [email protected]?subject:unsubscribe >> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > >> > >> > >> __________________________________________________________________________ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> [email protected]?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
