Open Stack

On Mon, May 19, 2014 at 9:28 PM, Brandon Logan
<brandon.logan at rackspace.com> wrote:
> In the API meeting at the summit, Mark McClain mentioned that the
> existing API should be supported, but deprecated so as not to interrupt
> those using the existing API.  To me, that sounds like the object model
> can change but there needs to be some kind of adapter/translation layer
> that modifies any existing current API calls to the new object model.
>
> So currently there is this blueprint spec that Eugene submitted:
>
> https://review.openstack.org/#/c/89903/3/specs/juno/lbaas-api-and-objmodel-improvement.rst
>
> That is implementing the object model with VIP as root object.  I
> suppose this needs to be changed to have the changed we agreed on at the
> summit.  Also, this blueprint should also cover the layer in which to
> the existing API calls get mapped to this object model.
>
> My question is to anyone who knows for certain: should this blueprint
> just be changed to reflect the new object model agreed on at the summit
> or should a new blueprint spec be created?  If it should just be changed
> should it wait until Eugene gets back from vacation since he's the one
> who created this blueprint spec?
>
If you think it makes sense to change this existing document, I would
say we should update Eugene's spec mentioned above to reflect what was
agreed upon at the summit. I know Eugene is on vacation this week, so
in this case it may be ok for you to push a new revision of his
specification while he's out, updating it to reflect the object model
changes. This way we can make some quick progress on this front. We
won't approve this until he gets back and has a chance to review it.
Let me know if you need help in pulling this spec down and pushing a
new version.

Thanks,
Kyle

> After that, then the API change blueprint spec should be created that
> adds the /loadbalancers resource and other changes.
>
> If anyone else can add anything please do.  If I said anything wrong
> please correct me, and if anyone can answer my question above please do.
>
> Thanks,
> Brandon Logan
>
> On Mon, 2014-05-19 at 17:06 -0400, Susanne Balle wrote:
>> 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
>>
>>
>>
>> _______________________________________________
>> 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