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 <sbaluk...@bluebox.net<mailto:sbaluk...@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.lo...@rackspace.com<mailto:brandon.lo...@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.lo...@rackspace.com<mailto:brandon.lo...@rackspace.com>] > Sent: Tuesday, August 05, 2014 8:27 AM > To: > firstname.lastname@example.org<mailto:email@example.com> > 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 > > OpenStackfirstname.lastname@example.org<mailto:OpenStackemail@example.com> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStackfirstname.lastname@example.org<mailto:OpenStackemail@example.com> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ > OpenStack-dev mailing list > OpenStackfirstname.lastname@example.org<mailto:OpenStackemail@example.com> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org<mailto:OpenStackemail@example.com> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807
_______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev