Open Stack

+1 to what Eugene just iterated:

  *   Different types of statuses
  *   Not every status on every object
  *   Status should be API call

Thanks,
Vivek

From: Eugene Nikanorov <enikanorov at mirantis.com<mailto:enikanorov at mirantis.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Tuesday, June 24, 2014 at 12:10 PM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][LBaaS] Which entities need status

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<mailto: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<mailto: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<mailto: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<mailto: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/20140624/5960264f/attachment.html>