Eugene, Thanks for the feedback. I have a feeling thats where we will end up going anyway so perhaps status on all entities for now is the proper way to build into that. I just want my objections to be heard.
Thanks, Brandon On Tue, 2014-06-24 at 23:10 +0400, Eugene Nikanorov wrote: > Hi lbaas folks, > > > IMO a status is really an important part of the API. > In some old email threads Sam has proposed the solution for lbaas > objects: we need to have several attributes that independently > represent different types of statuses: > - admin_state_up > - operational status > - provisioning state > > > Not every status need to be on every object. > Pure-DB objects (like pool) should not have provisioning state and > operational status, instead, an association object should have them. I > think that resolves both questions (1) and (2). > If some object is shareable, then we'll have association object > anyway, and that's where provisioning status and operationl status can > reside. For sure it's not very simple, but this is the right way to do > it. > > > Also I'd like to emphasize that statuses are really an API thing, not > a driver thing, so they must be used similarly across all drivers. > > > Thanks, > Eugene. > > > On Tue, Jun 24, 2014 at 10:53 PM, Doug Wiegley <do...@a10networks.com> > wrote: > Hi Brandon, > > I think just one status is overloading too much onto the LB > object (which > is perhaps something that a UI should do for a user, but not > something an > API should be doing.) > > > 1) If an entity exists without a link to a load balancer it > is purely > > just a database entry, so it would always be ACTIVE, but not > really > > active in a technical sense. > > > Depends on the driver. I don¹t think this is a decision for > lbaas proper. > > > > 2) If some of these entities become shareable then how does > the status > > reflect that the entity failed to create on one load > balancer but was > > successfully created on another. That logic could get > overly complex. > > > That¹s a status on the join link, not the object, and I could > argue > multiple ways in which that should be one way or another based > on the > backend, which to me, again implies driver question (backend > could queue > for later, or error immediately, or let things run degraded, > orŠ) > > Thanks, > Doug > > > > > On 6/24/14, 11:23 AM, "Brandon Logan" > <brandon.lo...@rackspace.com> wrote: > > >I think we missed this discussion at the meet-up but I'd like > to bring > >it up here. To me having a status on all entities doesn't > make much > >sense, and justing having a status on a load balancer (which > would be a > >provisioning status) and a status on a member (which would be > an > >operational status) are what makes sense because: > > > >1) If an entity exists without a link to a load balancer it > is purely > >just a database entry, so it would always be ACTIVE, but not > really > >active in a technical sense. > > > >2) If some of these entities become shareable then how does > the status > >reflect that the entity failed to create on one load balancer > but was > >successfully created on another. That logic could get overly > complex. > > > >I think the best thing to do is to have the load balancer > status reflect > >the provisioning status of all of its children. So if a > health monitor > >is updated then the load balancer that health monitor is > linked to would > >have its status changed to PENDING_UPDATE. Conversely, if a > load > >balancer or any entities linked to it are changed and the > load > >balancer's status is in a non-ACTIVE state then that update > should not > >be allowed. > > > >Thoughts? > > > >Thanks, > >Brandon > > > > > >_______________________________________________ > >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