[openstack-dev] [neutron][lbaas] - Heat support for LbaasV2
Sergey Kraynev
skraynev at mirantis.com
Wed Sep 23 18:09:00 UTC 2015
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.Fox at 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.Fox at 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 at 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 [banveerad at 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.Fox at 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 [banveerad at 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.Fox at 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.logan at RACKSPACE.COM]
>> > Sent: Tuesday, September 22, 2015 3:22 PM
>> > To: openstack-dev at 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
>> > > <skraynev at 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.logan at 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
>> > [banveerad at 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.logan at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150923/882b16fd/attachment.html>
More information about the OpenStack-dev
mailing list