<div dir="ltr">Hi folks,<div><br></div><div>Agree with Kyle, you may go ahead and update the spec on review to reflect the design discussed at the summit.</div><div><br></div><div>Thanks,</div><div>Eugene.</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, May 20, 2014 at 6:07 PM, Kyle Mestery <span dir="ltr"><<a href="mailto:mestery@noironetworks.com" target="_blank">mestery@noironetworks.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On Mon, May 19, 2014 at 9:28 PM, Brandon Logan<br>
<<a href="mailto:brandon.logan@rackspace.com">brandon.logan@rackspace.com</a>> wrote:<br>
> In the API meeting at the summit, Mark McClain mentioned that the<br>
> existing API should be supported, but deprecated so as not to interrupt<br>
> those using the existing API. To me, that sounds like the object model<br>
> can change but there needs to be some kind of adapter/translation layer<br>
> that modifies any existing current API calls to the new object model.<br>
><br>
> So currently there is this blueprint spec that Eugene submitted:<br>
><br>
> <a href="https://review.openstack.org/#/c/89903/3/specs/juno/lbaas-api-and-objmodel-improvement.rst" target="_blank">https://review.openstack.org/#/c/89903/3/specs/juno/lbaas-api-and-objmodel-improvement.rst</a><br>
><br>
> That is implementing the object model with VIP as root object. I<br>
> suppose this needs to be changed to have the changed we agreed on at the<br>
> summit. Also, this blueprint should also cover the layer in which to<br>
> the existing API calls get mapped to this object model.<br>
><br>
> My question is to anyone who knows for certain: should this blueprint<br>
> just be changed to reflect the new object model agreed on at the summit<br>
> or should a new blueprint spec be created? If it should just be changed<br>
> should it wait until Eugene gets back from vacation since he's the one<br>
> who created this blueprint spec?<br>
><br>
</div>If you think it makes sense to change this existing document, I would<br>
say we should update Eugene's spec mentioned above to reflect what was<br>
agreed upon at the summit. I know Eugene is on vacation this week, so<br>
in this case it may be ok for you to push a new revision of his<br>
specification while he's out, updating it to reflect the object model<br>
changes. This way we can make some quick progress on this front. We<br>
won't approve this until he gets back and has a chance to review it.<br>
Let me know if you need help in pulling this spec down and pushing a<br>
new version.<br>
<br>
Thanks,<br>
Kyle<br>
<div class="HOEnZb"><div class="h5"><br>
> After that, then the API change blueprint spec should be created that<br>
> adds the /loadbalancers resource and other changes.<br>
><br>
> If anyone else can add anything please do. If I said anything wrong<br>
> please correct me, and if anyone can answer my question above please do.<br>
><br>
> Thanks,<br>
> Brandon Logan<br>
><br>
> On Mon, 2014-05-19 at 17:06 -0400, Susanne Balle wrote:<br>
>> Great summit!! fantastic to meeting you all in person.<br>
>><br>
>><br>
>> We now have agreement on the Object model. How do we turn that into<br>
>> blueprints and also how do we start making progress on the rest of the<br>
>> items we agree upon at the summit?<br>
>><br>
>><br>
>> Susanne<br>
>><br>
>><br>
>> On Fri, May 16, 2014 at 2:07 AM, Brandon Logan<br>
>> <<a href="mailto:brandon.logan@rackspace.com">brandon.logan@rackspace.com</a>> wrote:<br>
>> Yeah that’s a good point. Thanks!<br>
>><br>
>><br>
>> From: Eugene Nikanorov <<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>><br>
>> Reply-To: "<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>><br>
>> Date: Thursday, May 15, 2014 at 10:38 PM<br>
>><br>
>> To: "<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object<br>
>> Model?<br>
>><br>
>><br>
>><br>
>> Brandon,<br>
>><br>
>><br>
>> It's allowed right now just per API. It's up to a backend to<br>
>> decide the status of a node in case some monitors find it<br>
>> dead.<br>
>><br>
>><br>
>> Thanks,<br>
>> Eugene.<br>
>><br>
>><br>
>><br>
>><br>
>> On Fri, May 16, 2014 at 4:41 AM, Brandon Logan<br>
>> <<a href="mailto:brandon.logan@rackspace.com">brandon.logan@rackspace.com</a>> wrote:<br>
>> I have concerns about multiple health monitors on the<br>
>> same pool. Is this always going to be the same type<br>
>> of health monitor? There’s also ambiguity in the case<br>
>> where one health monitor fails and another doesn’t.<br>
>> Is it an AND or OR that determines whether the member<br>
>> is down or not?<br>
>><br>
>><br>
>> Thanks,<br>
>> Brandon Logan<br>
>><br>
>><br>
>> From: Eugene Nikanorov <<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>><br>
>> Reply-To: "<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> Date: Thursday, May 15, 2014 at 9:55 AM<br>
>> To: "<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>><br>
>> Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated<br>
>> Object Model?<br>
>><br>
>><br>
>><br>
>> Vijay,<br>
>><br>
>><br>
>> Pools-monitors are still many to many, if it's not so<br>
>> on the picture - we'll fix that.<br>
>> I brought this up as an example of how we dealt with<br>
>> m:n via API.<br>
>><br>
>><br>
>> Thanks,<br>
>> Eugene.<br>
>><br>
>><br>
>> On Thu, May 15, 2014 at 6:43 PM, Vijay Venkatachalam<br>
>> <<a href="mailto:Vijay.Venkatachalam@citrix.com">Vijay.Venkatachalam@citrix.com</a>> wrote:<br>
>> Thanks for the clarification. Eugene.<br>
>><br>
>><br>
>><br>
>> A tangential point since you brought healthmon<br>
>> and pool.<br>
>><br>
>><br>
>><br>
>> There will be an additional entity called<br>
>> ‘PoolMonitorAssociation’ which results in a<br>
>> many to many relationship between pool and<br>
>> monitors. Right?<br>
>><br>
>><br>
>><br>
>> Now, the model is indicating a pool can have<br>
>> only one monitor. So a minor correction is<br>
>> required to indicate the many to many<br>
>> relationship via PoolMonitorAssociation.<br>
>><br>
>><br>
>><br>
>> Thanks,<br>
>><br>
>> Vijay V.<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> From: Eugene Nikanorov<br>
>> [mailto:<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>]<br>
>> Sent: Thursday, May 15, 2014 7:36 PM<br>
>><br>
>><br>
>> To: OpenStack Development Mailing List (not<br>
>> for usage questions)<br>
>> Subject: Re: [openstack-dev] [Neutron][LBaaS]<br>
>> Updated Object Model?<br>
>><br>
>><br>
>> Hi Vijay,<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> When you say API is not available, it<br>
>> means this should not be considered<br>
>> like a resource/entity. Correct?<br>
>><br>
>><br>
>><br>
>> But then, there would be API like a<br>
>> bind API, that accepts loadbalancer_id<br>
>> & listener_id, which creates this<br>
>> object.<br>
>><br>
>> And also, there would be an API that<br>
>> will be used to list the listeners of<br>
>> a LoadBalancer.<br>
>><br>
>><br>
>><br>
>> Right?<br>
>><br>
>><br>
>> Right, that's the same as health monitors and<br>
>> pools work right now: there are separate REST<br>
>> action to associate healthmon to a pool<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> Thanks,<br>
>><br>
>><br>
>> Eugene.<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>
>><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>
>><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>
>><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>
</div></div></blockquote></div><br></div>