Open Stack

Hi Eugene,

My understanding of the flavor framework is the following:

Say I have an F5 load balancer supporting TLS, L7, and standard loadbalancing. For business reasons I want to offer a Bronze (“standard load balancing”), silver (“Standard” + TLS), and gold (silver + L7) at different price points. What I absolutely don’t want is users getting Bronze load balancers and using TLS and L7 on them.

My understanding of the flavor framework was that by specifying (or not specifying) extensions I can create a diverse offering meeting my business needs. The way you are describing it the user selects, say a bronze flavor, and the system might or might not put it on a load balancer with TLS. This will lead to users asking for 10 Bronze  load balancers test them and discard the ones which don’t support TLS – this is something as a provider I would like to avoid.

Furthermore, in your example, say if I don’t have any TLS capable load balancers left and the user requests them  it will take until scheduling for the user to discover that we can’t accommodate him.

I can live with extensions coming in a later release but I am confused how your design will support above use case.

Thanks,
German

From: Eugene Nikanorov [mailto:enikanorov at mirantis.com]
Sent: Thursday, July 03, 2014 10:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Flavor framework: Conclusion

German,

First of all extension list looks lbaas-centric right now.
Secondly, TLS and L7 are such APIs which objects should not require loadbalancer or flavor to be created (like pool or healthmonitor that are pure db objects).
Only when you associate those objects with loadbalancer (or its child objects), driver may tell if it supports them.
Which means that you can't really turn those on or off, it's a generic API.
From user perspective flavor description (as interim) is sufficient to show what is supported by drivers behind the flavor.

Also, I think that turning "extensions" on/off is a bit of side problem to a service specification, so let's resolve it separately.


Thanks,
Eugene.

On Fri, Jul 4, 2014 at 3:07 AM, Eichberger, German <german.eichberger at hp.com<mailto:german.eichberger at hp.com>> wrote:
I am actually a bit bummed that Extensions are postponed. In LBaaS we are working hard on L7 and TLS extensions which we (the operators) like to switch on and off with different flavors...

German

-----Original Message-----
From: Kyle Mestery [mailto:mestery at noironetworks.com<mailto:mestery at noironetworks.com>]
Sent: Thursday, July 03, 2014 2:00 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Flavor framework: Conclusion

Awesome, thanks for working on this Eugene and Mark! I'll still leave an item on Monday's meeting agenda to discuss this, hopefully it can be brief.

Thanks,
Kyle

On Thu, Jul 3, 2014 at 10:32 AM, Eugene Nikanorov <enikanorov at mirantis.com<mailto:enikanorov at mirantis.com>> wrote:
> Hi,
>
> Mark and me has spent some time today discussing existing proposals
> and I think we got to a consensus.
> Initially I had two concerns about Mark's proposal which are
> - extension list attribute on the flavor
> - driver entry point on the service profile
>
> The first idea (ext list) need to be clarified more as we get more
> drivers that needs it.
> Right now we have FWaaS/VPNaaS which don't have extensions at all and
> we have LBaaS where all drivers support all extensions.
> So extension list can be postponed until we clarify how exactly we
> want this to be exposed to the user and how we want it to function on
> implementation side.
>
> Driver entry point which implies dynamic loading per admin's request
> is a important discussion point (at least, previously this idea
> received negative opinions from some cores) We'll implement service
> profiles, but this exact aspect of how driver is specified/loadede
> will be discussed futher.
>
> So based on that I'm going to start implementing this.
> I think that implementation result will allow us to develop in
> different directions (extension list vs tags, dynamic loading and
> such) depending on more information about how this is utilized by deployers and users.
>
> Thanks,
> Eugene.
>
>
>
> On Thu, Jul 3, 2014 at 5:57 PM, Susanne Balle <sleipnir012 at gmail.com<mailto:sleipnir012 at gmail.com>> wrote:
>>
>> +1
>>
>>
>> On Wed, Jul 2, 2014 at 10:12 PM, Kyle Mestery
>> <mestery at noironetworks.com<mailto:mestery at noironetworks.com>>
>> wrote:
>>>
>>> We're coming down to the wire here with regards to Neutron BPs in
>>> Juno, and I wanted to bring up the topic of the flavor framework BP.
>>> This is a critical BP for things like LBaaS, FWaaS, etc. We need
>>> this work to land in Juno, as these other work items are dependent on it.
>>> There are still two proposals [1] [2], and after the meeting last
>>> week [3] it appeared we were close to conclusion on this. I now see
>>> a bunch of comments on both proposals.
>>>
>>> I'm going to again suggest we spend some time discussing this at the
>>> Neutron meeting on Monday to come to a closure on this. I think
>>> we're close. I'd like to ask Mark and Eugene to both look at the
>>> latest comments, hopefully address them before the meeting, and then
>>> we can move forward with this work for Juno.
>>>
>>> Thanks for all the work by all involved on this feature! I think
>>> we're close and I hope we can close on it Monday at the Neutron meeting!
>>>
>>> Kyle
>>>
>>> [1] https://review.openstack.org/#/c/90070/
>>> [2] https://review.openstack.org/102723
>>> [3]
>>> http://eavesdrop.openstack.org/meetings/networking_advanced_services
>>> /2014/networking_advanced_services.2014-06-27-17.30.log.html
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
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/20140707/380a63a5/attachment.html>