Open Stack

Great summit!! fantastic to meeting you all in person.

We now have agreement on the Object model. How do we turn that into
blueprints and also how do we start making progress on the rest of the
items we agree upon at the summit?

Susanne


On Fri, May 16, 2014 at 2:07 AM, Brandon Logan
<brandon.logan at rackspace.com>wrote:

>  Yeah that’s a good point.  Thanks!
>
>   From: Eugene Nikanorov <enikanorov at mirantis.com>
> Reply-To: "openstack-dev at lists.openstack.org" <
> openstack-dev at lists.openstack.org>
> Date: Thursday, May 15, 2014 at 10:38 PM
>
> To: "openstack-dev at lists.openstack.org" <openstack-dev at lists.openstack.org
> >
> Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
>
>   Brandon,
>
>  It's allowed right now just per API. It's up to a backend to decide the
> status of a node in case some monitors find it dead.
>
>  Thanks,
> Eugene.
>
>
>
> On Fri, May 16, 2014 at 4:41 AM, Brandon Logan <
> brandon.logan at rackspace.com> wrote:
>
>>  I have concerns about multiple health monitors on the same pool.  Is
>> this always going to be the same type of health monitor?  There’s also
>> ambiguity in the case where one health monitor fails and another doesn’t.
>>  Is it an AND or OR that determines whether the member is down or not?
>>
>>  Thanks,
>> Brandon Logan
>>
>>   From: Eugene Nikanorov <enikanorov at mirantis.com>
>> Reply-To: "openstack-dev at lists.openstack.org" <
>> openstack-dev at lists.openstack.org>
>> Date: Thursday, May 15, 2014 at 9:55 AM
>> To: "openstack-dev at lists.openstack.org" <
>> openstack-dev at lists.openstack.org>
>>
>> Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
>>
>>   Vijay,
>>
>>  Pools-monitors are still many to many, if it's not so on the picture -
>> we'll fix that.
>> I brought this up as an example of how we dealt with m:n via API.
>>
>>  Thanks,
>> Eugene.
>>
>>
>> On Thu, May 15, 2014 at 6:43 PM, Vijay Venkatachalam <
>> Vijay.Venkatachalam at citrix.com> wrote:
>>
>>>  Thanks for the clarification. Eugene.
>>>
>>>
>>>
>>> A tangential point since you brought healthmon and pool.
>>>
>>>
>>>
>>> There will be an additional entity called ‘PoolMonitorAssociation’ which
>>> results in a many to many relationship between pool and monitors. Right?
>>>
>>>
>>>
>>> Now, the model is indicating a pool can have only one monitor. So a
>>> minor correction is required to indicate the many to many relationship via
>>> PoolMonitorAssociation.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Vijay V.
>>>
>>>
>>>
>>>
>>>
>>> *From:* Eugene Nikanorov [mailto:enikanorov at mirantis.com]
>>> *Sent:* Thursday, May 15, 2014 7:36 PM
>>>
>>> *To:* OpenStack Development Mailing List (not for usage questions)
>>> *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
>>>
>>>
>>>
>>> Hi Vijay,
>>>
>>>
>>>
>>>
>>> When you say API is not available, it means this should not be
>>> considered like a resource/entity. Correct?
>>>
>>>
>>>
>>> But then, there would be API like a bind API, that accepts
>>> loadbalancer_id & listener_id,  which creates this object.
>>>
>>> And also, there would be an API that will be used to list the listeners
>>> of a LoadBalancer.
>>>
>>>
>>>
>>> Right?
>>>
>>>  Right, that's the same as health monitors and pools work right now:
>>> there are separate REST action to associate healthmon to a pool
>>>
>>>
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Eugene.
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> 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/20140519/b1899c4d/attachment.html>