Hi folks, Agree with Kyle, you may go ahead and update the spec on review to reflect the design discussed at the summit.
Thanks, Eugene. On Tue, May 20, 2014 at 6:07 PM, Kyle Mestery <mest...@noironetworks.com>wrote: > On Mon, May 19, 2014 at 9:28 PM, Brandon Logan > <brandon.lo...@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.lo...@rackspace.com> wrote: > >> Yeah that’s a good point. Thanks! > >> > >> > >> From: Eugene Nikanorov <enikano...@mirantis.com> > >> Reply-To: "openstack-dev@lists.openstack.org" > >> <openstack-dev@lists.openstack.org> > >> > >> Date: Thursday, May 15, 2014 at 10:38 PM > >> > >> To: "openstack-dev@lists.openstack.org" > >> <openstack-dev@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.lo...@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 <enikano...@mirantis.com> > >> Reply-To: "openstack-dev@lists.openstack.org" > >> <openstack-dev@lists.openstack.org> > >> Date: Thursday, May 15, 2014 at 9:55 AM > >> To: "openstack-dev@lists.openstack.org" > >> <openstack-dev@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.venkatacha...@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:enikano...@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@lists.openstack.org > >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
