Open Stack

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 <dougw at 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.logan at 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 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