Re: [openstack-dev] [Neutron][LBaaS] "status" in entities
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 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 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 +, 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: > openstack-dev@lists.openstack.org<mailto:openstack-dev@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 +, 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@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] "status" in entities
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 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 +, 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] > > Sent: Tuesday, August 05, 2014 8:27 AM > > To: openstack-dev@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 +, 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@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 > -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] "status" in entities
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 +, 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] > Sent: Tuesday, August 05, 2014 8:27 AM > To: openstack-dev@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 +, 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@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
Re: [openstack-dev] [Neutron][LBaaS] "status" in entities
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] Sent: Tuesday, August 05, 2014 8:27 AM To: openstack-dev@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 +, 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@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
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 +, 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@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
