Open Stack

Hi folks,

I will try to respond both recent emails:

> What I absolutely don’t want is users getting Bronze load balancers and
using TLS and L7 on them.
My main objection of having extension list on the flavor is that it is
actually doesn't allow you to do what you want to do.
Flavor is the entity that is used when user creates service instance, like
loadbalancer, firewall or vpnservice objects.
The extensions you are talking about provide access to REST resources which
may not be directly attached to an instance.
Which means that user may create those object without bothering with
flavors at all. You can't turn off access to those REST resources, because
user doesn't need to use flavors to access them.

The second objection is more minor - this is a different problem then we
are trying to solve right now.
I suggested to postpone it until we have clearer vision of how it is going
to work.

> My understanding of the flavor framework was that by specifying (or not
specifying) extensions I can create a diverse > offering meeting my
business needs.
Well, that's actually is not difficult: we have metadata in a service
profile, admin can turn extensions on and off there.
As I said before, extension in the flavor is too coarse-grained to specify
supported API aspects, secondly, it can't be used to actually turn
extensions on or off.

> 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.
In first implementation this would be the responsibility of the description
to provide such information, and the responsibility of a admin to provide
proper mapping between flavor and service profile.

> in your example, say if I don’t have any TLS capable load balancers left
and the user requests them
How user can request such load balancer if he/she doesn't see appropriate
flavor?
I'm just telling that if extension list on the flavor doesn't solve the
problems it supposed to solve - it's no better than providing such
information in the description.

To Mark's comments:
> The driver should not be involved.  We can use the supported extensions
to determine is associated logical resources are supported.

In example above - user may only know about certain limitations when
accessing core API, which you can't turn off.
Say, create a listener with certificate_id (or whatever object is
responsible for keeping a certificate).
In other words: in order to perform any kind of dispatching that will
actually turn off access to TLS (in the core API) we will need to implement
some complex dispatching which consider not only REST resources of the
extension, but also attributes of the core API used in the request.
I think that's completely unnecessary.

>  Otherwise driver behaviors will vary wildly
I don't see why it should. Once admin provided proper mapping between
flavor and service profile (where, as I suggested above, you may turn
on/off the extensions with metadata) driver should behave according to the
flavor.
It's then up to our implementation on what to return to user in case it
tries to access the extension unsupported in a given mode.
But it still will work at the point of association (cert with listener, l7
policy with listener, etc)

Another point is that you look at the extension list more closely - you'll
see that it's no better then tags, and that's the reason to move that to
service profile's metadata.
I don't think dispatching should be done on the basis of what is defined on
the flavor - it is a complex solution giving no benefits over existing
dispatching method.


Thanks,
Eugene.



On Mon, Jul 7, 2014 at 8:41 PM, Mark McClain <mmcclain at yahoo-inc.com> wrote:

>
>  On Jul 4, 2014, at 1:09 AM, Eugene Nikanorov <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> 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]
>> 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> 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>
>> wrote:
>> >>
>> >> +1
>> >>
>> >>
>> >> On Wed, Jul 2, 2014 at 10:12 PM, Kyle Mestery
>> >> <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
> 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/45936dde/attachment.html>