<div dir="ltr">Hi folks,<div><br></div><div>I will try to respond both recent emails:</div><div><br></div><div>> <span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:15px">What I absolutely don’t want is users getting Bronze load balancers and using TLS and L7 on them.</span></div>
<div><font face="arial, helvetica, sans-serif" color="#000000">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.</font></div><div><font face="arial, helvetica, sans-serif" color="#000000">Flavor is the entity that is used when user creates service instance, like loadbalancer, firewall or vpnservice objects.</font></div>
<div><font face="arial, helvetica, sans-serif" color="#000000">The extensions you are talking about provide access to REST resources which may not be directly attached to an instance.</font></div><div><font face="arial, helvetica, sans-serif" color="#000000">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.</font></div>
<div><font face="arial, helvetica, sans-serif" color="#000000"><br></font></div><div><font face="arial, helvetica, sans-serif" color="#000000">The second objection is more minor - this is a different problem then we are trying to solve right now.</font></div>
<div><font face="arial, helvetica, sans-serif" color="#000000">I suggested to postpone it until we have clearer vision of how it is going to work.</font></div><div><font face="arial, helvetica, sans-serif" color="#000000"><br>
</font></div><div><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:15px">> My understanding of the flavor framework was that by specifying (or not specifying) extensions I can create a diverse > offering meeting my business needs.</span><font face="arial, helvetica, sans-serif" color="#000000"><br>
</font></div><div><font color="#000000" face="arial, helvetica, sans-serif">Well, that's actually is not difficult: we have metadata in a service profile, admin can turn extensions on and off there.</font></div><div><font color="#000000" face="arial, helvetica, sans-serif">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.</font></div>
<div><font color="#000000" face="arial, helvetica, sans-serif"><br></font></div><div><font color="#000000" face="arial, helvetica, sans-serif">> </font><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:15px">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 </span></div>
<div><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:15px">> balancer with TLS.</span></div><div><font face="arial, helvetica, sans-serif" color="#000000">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.</font></div>
<div><font color="#000000" face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif" color="#000000">> </font><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:15px">in your example, say if I don’t have any TLS capable load balancers left and the user requests them</span></div>
<div><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">How user can request such load balancer if he/she doesn't see appropriate flavor?</span><br></div><div><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">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.</span></div>
<div><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div><div><font color="#000000" face="arial, helvetica, sans-serif">To Mark's comments:</font></div><div><font color="#000000" face="arial, helvetica, sans-serif">> </font><span style="font-family:arial,sans-serif;font-size:13px">The driver should not be involved.  We can use the supported extensions to determine is associated logical resources are supported.</span><span style="font-family:arial,sans-serif;font-size:13px"> </span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><font face="arial, sans-serif">In example above - user may only know about certain limitations when accessing core API, which you can't turn off.</font></div>
<div><font face="arial, sans-serif">Say, create a listener with certificate_id (or whatever object is responsible for keeping a certificate). </font></div><div><font face="arial, sans-serif">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.</font></div>
<div><font face="arial, sans-serif">I think that's completely unnecessary.</font></div><div><font face="arial, sans-serif"><br></font></div><div><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">> </span><span style="font-family:arial,sans-serif;font-size:13px"> Otherwise driver behaviors will vary wildly</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">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.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">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.</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">But it still will work at the point of association (cert with listener, l7 policy with listener, etc)</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">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.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">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.</span></div>
<div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Thanks,</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Eugene.</span></div>
<div><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 7, 2014 at 8:41 PM, Mark McClain <span dir="ltr"><<a href="mailto:mmcclain@yahoo-inc.com" target="_blank">mmcclain@yahoo-inc.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word">
<br>
<div><div class="">
<div>On Jul 4, 2014, at 1:09 AM, Eugene Nikanorov <<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>> wrote:</div>
<br>
<blockquote type="cite">
<div dir="ltr">German,
<div><br>
</div>
<div>First of all extension list looks lbaas-centric right now.</div>
</div>
</blockquote>
<div><br>
</div></div>
Actually far from it.  SSL VPN should be service extension.<div class=""><br>
<div><br>
</div>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>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).</div>
<div>Only when you associate those objects with loadbalancer (or its child objects), driver may tell if it supports them. <br>
</div>
<div>Which means that you can't really turn those on or off, it's a generic API.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
</div><div>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.</div><div class="">
<div><br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div></div>
<div>From user perspective flavor description (as interim) is sufficient to show what is supported by drivers behind the flavor.</div>
</div>
</blockquote>
<div><br>
</div>
</div><div>Supported extensions are critical component for this.</div><div><div class="h5">
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Also, I think that turning "extensions" on/off is a bit of side problem to a service specification, so let's resolve it separately.</div>
<div><br>
</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Eugene.</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Jul 4, 2014 at 3:07 AM, Eichberger, German <span dir="ltr">
<<a href="mailto:german.eichberger@hp.com" target="_blank">german.eichberger@hp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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...<br>
<span><font color="#888888"><br>
German<br>
</font></span>
<div>
<div><br>
-----Original Message-----<br>
From: Kyle Mestery [mailto:<a href="mailto:mestery@noironetworks.com" target="_blank">mestery@noironetworks.com</a>]<br>
Sent: Thursday, July 03, 2014 2:00 PM<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
Subject: Re: [openstack-dev] [neutron] Flavor framework: Conclusion<br>
<br>
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.<br>
<br>
Thanks,<br>
Kyle<br>
<br>
On Thu, Jul 3, 2014 at 10:32 AM, Eugene Nikanorov <<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>> wrote:<br>
> Hi,<br>
><br>
> Mark and me has spent some time today discussing existing proposals<br>
> and I think we got to a consensus.<br>
> Initially I had two concerns about Mark's proposal which are<br>
> - extension list attribute on the flavor<br>
> - driver entry point on the service profile<br>
><br>
> The first idea (ext list) need to be clarified more as we get more<br>
> drivers that needs it.<br>
> Right now we have FWaaS/VPNaaS which don't have extensions at all and<br>
> we have LBaaS where all drivers support all extensions.<br>
> So extension list can be postponed until we clarify how exactly we<br>
> want this to be exposed to the user and how we want it to function on<br>
> implementation side.<br>
><br>
> Driver entry point which implies dynamic loading per admin's request<br>
> is a important discussion point (at least, previously this idea<br>
> received negative opinions from some cores) We'll implement service<br>
> profiles, but this exact aspect of how driver is specified/loadede<br>
> will be discussed futher.<br>
><br>
> So based on that I'm going to start implementing this.<br>
> I think that implementation result will allow us to develop in<br>
> different directions (extension list vs tags, dynamic loading and<br>
> such) depending on more information about how this is utilized by deployers and users.<br>
><br>
> Thanks,<br>
> Eugene.<br>
><br>
><br>
><br>
> On Thu, Jul 3, 2014 at 5:57 PM, Susanne Balle <<a href="mailto:sleipnir012@gmail.com" target="_blank">sleipnir012@gmail.com</a>> wrote:<br>
>><br>
>> +1<br>
>><br>
>><br>
>> On Wed, Jul 2, 2014 at 10:12 PM, Kyle Mestery<br>
>> <<a href="mailto:mestery@noironetworks.com" target="_blank">mestery@noironetworks.com</a>><br>
>> wrote:<br>
>>><br>
>>> We're coming down to the wire here with regards to Neutron BPs in<br>
>>> Juno, and I wanted to bring up the topic of the flavor framework BP.<br>
>>> This is a critical BP for things like LBaaS, FWaaS, etc. We need<br>
>>> this work to land in Juno, as these other work items are dependent on it.<br>
>>> There are still two proposals [1] [2], and after the meeting last<br>
>>> week [3] it appeared we were close to conclusion on this. I now see<br>
>>> a bunch of comments on both proposals.<br>
>>><br>
>>> I'm going to again suggest we spend some time discussing this at the<br>
>>> Neutron meeting on Monday to come to a closure on this. I think<br>
>>> we're close. I'd like to ask Mark and Eugene to both look at the<br>
>>> latest comments, hopefully address them before the meeting, and then<br>
>>> we can move forward with this work for Juno.<br>
>>><br>
>>> Thanks for all the work by all involved on this feature! I think<br>
>>> we're close and I hope we can close on it Monday at the Neutron meeting!<br>
>>><br>
>>> Kyle<br>
>>><br>
>>> [1] <a href="https://review.openstack.org/#/c/90070/" target="_blank">https://review.openstack.org/#/c/90070/</a><br>
>>> [2] <a href="https://review.openstack.org/102723" target="_blank">https://review.openstack.org/102723</a><br>
>>> [3]<br>
>>> <a href="http://eavesdrop.openstack.org/meetings/networking_advanced_services" target="_blank">
http://eavesdrop.openstack.org/meetings/networking_advanced_services</a><br>
>>> /2014/networking_advanced_services.2014-06-27-17.30.log.html</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div></div></div>
</div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>