Open Stack

On Jul 4, 2014, at 1:09 AM, Eugene Nikanorov <enikanorov at mirantis.com<mailto:enikanorov at mirantis.com>> wrote:

German,

First of all extension list looks lbaas-centric right now.

Actually far from it.  SSL VPN should be service extension.


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.

The driver should not be involved.  We can use the supported extensions to determine is associated logical resources are supported.  Otherwise driver behaviors will vary wildly.  Also deferring to driver exposes a possible way for a tenant to utilize features that may not be supported by the operator curated flavor.

>From user perspective flavor description (as interim) is sufficient to show what is supported by drivers behind the flavor.

Supported extensions are critical component for this.


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140707/a1094389/attachment.html>