<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hi,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I think we are debating some edge-case. An important part of the flavor framework is the ability of me the operator to say failover from Octavia to an F5. So
as an operator I would ensure to only offer the features in that flavor which both support. So in order to arrive at Brandon’s example I would have misconfigured my environment and rightfully would get errors at the drive level – which might be hard to understand
for end users but hopefully pretty clear for me the operator…<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">German<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Eugene Nikanorov [mailto:enikanorov@mirantis.com]
<br>
<b>Sent:</b> Monday, August 11, 2014 9:56 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [Neutron][LBaaS] Continuing on "Calling driver interface on every API request"<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Well, that exactly what we've tried to solve with tags in the flavor.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Considering your example with whole configuration being sent to the driver - i think it will be fine to not apply unsupported parts of configuration (like such HM) and mark the HM object with error status/status description.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Eugene.<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Tue, Aug 12, 2014 at 12:33 AM, Brandon Logan <<a href="mailto:brandon.logan@rackspace.com" target="_blank">brandon.logan@rackspace.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">Hi Eugene,<br>
An example of the HM issue (and really this can happen with any entity)<br>
is if the driver the API sends the configuration to does not actually<br>
support the value of an attribute.<br>
<br>
For example: Provider A support PING health monitor type, Provider B<br>
does not. API allows the PING health monitor type to go through. Once<br>
a load balancer has been linked with that health monitor and the<br>
LoadBalancer chose to use Provider B, that entire configuration is then<br>
sent to the driver. The driver errors out not on the LoadBalancer<br>
create, but on the health monitor create.<br>
<br>
I think that's the issue.<br>
<br>
Thanks,<br>
Brandon<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
On Tue, 2014-08-12 at 00:17 +0400, Eugene Nikanorov wrote:<br>
> Hi folks,<br>
><br>
><br>
> That actually going in opposite direction to what flavor framework is<br>
> trying to do (and for dispatching it's doing the same as providers).<br>
> REST call dispatching should really go via the root object.<br>
><br>
><br>
> I don't quite get the issue with health monitors. If HM is incorrectly<br>
> configured prior to association with a pool - API layer should handle<br>
> that.<br>
> I don't think driver implementations should be different at<br>
> constraints to HM parameters.<br>
><br>
><br>
> So I'm -1 on adding provider (or flavor) to each entity. After all, it<br>
> looks just like data denormalization which actually will affect lots<br>
> of API aspects in negative way.<br>
><br>
><br>
> Thanks,<br>
> Eugene.<br>
><br>
><br>
><br>
><br>
> On Mon, Aug 11, 2014 at 11:20 PM, Vijay Venkatachalam<br>
> <<a href="mailto:Vijay.Venkatachalam@citrix.com">Vijay.Venkatachalam@citrix.com</a>> wrote:<br>
><br>
> Yes, the point was to say "the plugin need not restrict and<br>
> let driver decide what to do with the API".<br>
><br>
> Even if the call was made to driver instantaneously, I<br>
> understand, the driver might decide to ignore<br>
> first and schedule later. But, if the call is present, there<br>
> is scope for validation.<br>
> Also, the driver might be scheduling an async-api to backend,<br>
> in which case deployment error<br>
> cannot be shown to the user instantaneously.<br>
><br>
> W.r.t. identifying a provider/driver, how would it be to make<br>
> tenant the default "root" object?<br>
> "tenantid" is already associated with each of these entities,<br>
> so no additional pain.<br>
> For the tenant who wants to override let him specify provider<br>
> in each of the entities.<br>
> If you think of this in terms of the UI, let's say if the<br>
> loadbalancer configuration is exposed<br>
> as a single wizard (which has loadbalancer, listener, pool,<br>
> monitor properties) then provider<br>
> is chosen only once.<br>
><br>
> Curious question, is flavour framework expected to address<br>
> this problem?<br>
><br>
> Thanks,<br>
> Vijay V.<br>
><br>
> -----Original Message-----<br>
> From: Doug Wiegley [mailto:<a href="mailto:dougw@a10networks.com">dougw@a10networks.com</a>]<br>
><br>
> Sent: 11 August 2014 22:02<br>
> To: OpenStack Development Mailing List (not for usage<br>
> questions)<br>
> Subject: Re: [openstack-dev] [Neutron][LBaaS] Continuing on<br>
> "Calling driver interface on every API request"<br>
><br>
> Hi Sam,<br>
><br>
> Very true. I think that Vijay’s objection is that we are<br>
> currently imposing a logical structure on the driver, when it<br>
> should be a driver decision. Certainly, it goes both ways.<br>
><br>
> And I also agree that the mechanism for returning multiple<br>
> errors, and the ability to specify whether those errors are<br>
> fatal or not, individually, is currently weak.<br>
><br>
> Doug<br>
><br>
><br>
> On 8/11/14, 10:21 AM, "Samuel Bercovici" <<a href="mailto:SamuelB@Radware.com">SamuelB@Radware.com</a>><br>
> wrote:<br>
><br>
> >Hi Doug,<br>
> ><br>
> >In some implementations Driver !== Device. I think this is<br>
> also true<br>
> >for HA Proxy.<br>
> >This might mean that there is a difference between creating a<br>
> logical<br>
> >object and when there is enough information to actually<br>
> schedule/place<br>
> >this into a device.<br>
> >The ability to express such errors (detecting an error on a<br>
> logical<br>
> >object after it was created but when it actually get<br>
> scheduled) should<br>
> >be discussed and addressed anyway.<br>
> ><br>
> >-Sam.<br>
> ><br>
> ><br>
> >-----Original Message-----<br>
> >From: Doug Wiegley [mailto:<a href="mailto:dougw@a10networks.com">dougw@a10networks.com</a>]<br>
> >Sent: Monday, August 11, 2014 6:55 PM<br>
> >To: OpenStack Development Mailing List (not for usage<br>
> questions)<br>
> >Subject: Re: [openstack-dev] [Neutron][LBaaS] Continuing on<br>
> "Calling<br>
> >driver interface on every API request"<br>
> ><br>
> >Hi all,<br>
> ><br>
> >> Validations such as ³timeout > delay² should be performed<br>
> on the API<br>
> >>level before it reaches the driver.<br>
> >For a configuration tree (lb, listeners, pools, etc.), there<br>
> should be<br>
> >one provider.<br>
> ><br>
> >You¹re right, but I think the point of Vijay¹s example was to<br>
> highlight<br>
> >the combo error problem with populating all of the driver<br>
> objects at<br>
> >once (in short, the driver interface isn¹t well suited to<br>
> that model.)<br>
> >That his one example can be covered by API validators is<br>
> irrelevant.<br>
> >Consider a backend that does not support APP_COOKIE¹s, or<br>
> >HTTPS_TERMINATED (but has multiple listeners) instead.<br>
> Should the<br>
> >entire load balancer create fail, or should it offer degraded<br>
> service?<br>
> >Do all drivers have to implement a transaction rollback;<br>
> wait, the<br>
> >interface makes that very hard. That¹s his point. The<br>
> driver is no<br>
> >longer just glue code between interfaces; it¹s now a<br>
> mini-object error handler.<br>
> ><br>
> ><br>
> >> Having provider defined in multiple places does not make<br>
> sense.<br>
> ><br>
> >Channeling Brandon, who can yell if I get this wrong, the<br>
> point is not<br>
> >to have a potentially different provider on each object.<br>
> It¹s to allow<br>
> >a provider to be assigned when the first object in the tree<br>
> is created,<br>
> >so that future related objects will always get routed to the<br>
> same provider.<br>
> >Not knowing which provider should get all the objects is why<br>
> we have to<br>
> >wait until we see a LoadBalancer object.<br>
> ><br>
> ><br>
> >All of this sort of edge case nonsense is because we (the<br>
> royal we, the<br>
> >community), wanted all load balancer objects to be ³root²<br>
> objects, even<br>
> >though only one of them is an actual root today, to support<br>
> >many-to-many relationships among all of them, at some future<br>
> date,<br>
> >without an interface change. If my bias is showing that I¹m<br>
> not a fan<br>
> >of adding this complexity for that, I¹m not surprised.<br>
> ><br>
> >Thanks,<br>
> >doug<br>
> ><br>
> ><br>
> >On 8/11/14, 7:57 AM, "Samuel Bercovici" <<a href="mailto:SamuelB@Radware.com">SamuelB@Radware.com</a>><br>
> wrote:<br>
> ><br>
> >>Hi,<br>
> >><br>
> >>Validations such as ³timeout > delay² should be performed on<br>
> the API<br>
> >>level before it reaches the driver.<br>
> >><br>
> >>For a configuration tree (lb, listeners, pools, etc.), there<br>
> should be<br>
> >>one provider.<br>
> >><br>
> >>Having provider defined in multiple places does not make<br>
> sense.<br>
> >><br>
> >><br>
> >>-San.<br>
> >><br>
> >><br>
> >>From: Vijay Venkatachalam<br>
> [mailto:<a href="mailto:Vijay.Venkatachalam@citrix.com">Vijay.Venkatachalam@citrix.com</a>]<br>
> >><br>
> >>Sent: Monday, August 11, 2014 2:43 PM<br>
> >>To: OpenStack Development Mailing List<br>
> >>(<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>)<br>
> >>Subject: [openstack-dev] [Neutron][LBaaS] Continuing on<br>
> "Calling<br>
> >>driver interface on every API request"<br>
> >><br>
> >><br>
> >><br>
> >>Hi:<br>
> >><br>
> >>Continuing from last week¹s LBaaS meetingŠ<br>
> >><br>
> >>Currently an entity cannot be sent to driver unless it is<br>
> linked to<br>
> >>loadbalancer because loadbalancer is the root object and<br>
> driver<br>
> >>information is only available with loadbalancer.<br>
> >><br>
> >><br>
> >>The request to the driver is delayed because of which error<br>
> >>propagation becomes tricky.<br>
> >><br>
> >>Let¹s say a monitor was configured with timeout > delay<br>
> there would be<br>
> >>no error then.<br>
> >>When a listener is configured there will be a monitor<br>
> >>creation/deployment error like ³timeout configured greater<br>
> than delay².<br>
> >><br>
> >>Unless the error is very clearly crafted the user won¹t be<br>
> able to<br>
> >>understand the error.<br>
> >><br>
> >>I am half-heartedly OK with current approach.<br>
> >><br>
> >><br>
> >>But, I would prefer Brandon¹s Solution make provider an<br>
> attribute in<br>
> >>each of the entities to get rid of this problem.<br>
> >><br>
> >><br>
> >>What do others think?<br>
> >><br>
> >>Thanks,<br>
> >>Vijay V.<br>
> >><br>
> ><br>
> ><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>
> >_______________________________________________<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>
> _______________________________________________<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>
> 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>
><br>
><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>
_______________________________________________<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><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>