Open Stack

I agree. the current status can reflect the deployment status and we can add a new attribute to reflect operational status.

I also agree that adminstate_up should definitely affect operational status. But driver could choose to unprovision when admin state is set to false. In which case status will also change.

If agenda permits,  can we discuss this in the upcoming weekly meeting?

Sent using CloudMagic<https://cloudmagic.com/k/d/mailapp?ct=pa&cv=5.0.32&pv=4.2.2>

On Wed, Aug 06, 2014 at 2:46 AM, Stephen Balukoff <sbalukoff at bluebox.net<mailto:sbalukoff at bluebox.net>> wrote:

Hi guys,

I understood that admin_state_up was a manipulable field which (when working correctly) should change the entity to an operational status of "ADMIN_DOWN" or something similar to that. In any case, +1 on the deeper discussion of status.

How urgent is it to resolve the discussion around status? We could potentially bring the interested parties together via google hangout or webex (to facilitate the high bandwidth).

Stephen


On Tue, Aug 5, 2014 at 9:05 AM, Brandon Logan <brandon.logan at rackspace.com<mailto:brandon.logan at rackspace.com>> wrote:
Isn't that what admin_state_up is for?

But yes we do need a deeper discussion on this and many other things.

On Tue, 2014-08-05 at 15:42 +0000, Eichberger, German wrote:
> There was also talk about a third administrative status like ON/OFF...
>
> We really need a deeper status discussion - likely high bandwith to work all of that out.
>
> German
>
> -----Original Message-----
> From: Brandon Logan [mailto:brandon.logan at RACKSPACE.COM<mailto:brandon.logan at RACKSPACE.COM>]
> Sent: Tuesday, August 05, 2014 8:27 AM
> To: openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Neutron][LBaaS] "status" in entities
>
>
> Hello Vijay!
>
> Well this is a hold over from v1, but the status is a provisioning status.  So yes, when something is deployed successfully it should be ACTIVE.  The exception to this is the member status, in that it's status can be INACTIVE if a health check fails.  Now this will probably cause edge cases when health checks and updates are happening to the same member.  It's been talked about before, but we need to really have two types of status fields, provisioning and operational.  IMHO, that should be something we try to get into K.
>
> Thanks,
> Brandon
>
> On Tue, 2014-08-05 at 09:28 +0000, Vijay Venkatachalam wrote:
> > Hi:
> >
> >                I think we had some discussions around ‘status’
> > attribute earlier, I don’t recollect the conclusion.
> >
> > Does it reflect the deployment status?
> >
> >                Meaning, if the status of an entity is ACTIVE, the user
> > has to infer that the entity is deployed successfully in the
> > backend/loadbalancer.
> >
> > Thanks,
> >
> > Vijay V.
> >
> >
> > _______________________________________________
> > 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
> _______________________________________________
> 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



--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140806/4f956f64/attachment.html>