Disable child cell support

This would be a nice addition. Could you provide a little more information about the specifics of it though? Does disabled just mean don't schedule to it anymore, or something else? Would it extend a current API or add a new endpoint? Is there anything else a user of this feature should be aware of? --alaski

Without wanting to make things very complicated, typical status that I could imagine would be for active, draining, read-only and inactive. active would be the usual state. draining would respond to queries, migrations and deletes but refuse new schedule requests. read-only would only permit queries and inactive would not respond. Depending on the intervention, all of these could be useful. user story for draining is where the hardware in a cell is to be re-used and you want to move the workload off but not schedule new VMs. read-only would where, for example, you are doing a database migration and don't want new entries during that migration. inactive would be where you really don't want the cell to answer. There are probably other components in OpenStack that also exhibit this behaviour.

That's great information. Would all of that be in scope for this blueprint? That's quite a bit more work than just enabled/disabled. I'd like to approve this but it needs a bit more work in certain areas. https://wiki.openstack.org/wiki/Blueprints#Blueprint_Review_Criteria is a helpful guide for the additional details that are necessary. Basically I'd like to fully understand the user impact, user in this case being an admin, and what's in scope for the change. I can try to catch someone on irc if that would help, or feel free to ping me (alaski) to discuss. I'm UTC-5.

According to Tim's information, it's would be more flexible and extensible for cell management if status for cell could be controllable, i will add this to the specifics.

It's more that the status is more than just an ACTIVE boolean but more of a status as for hypervisors or VMs. A staged implementation with the states active/disabled (i.e. completely functional versus would not respond) and then additional states could be added as the use cases are clarified. -- Tim

deferred from icehouse-3 to "next": http://lists.openstack.org/pipermail/openstack-dev/2014-February/026335.html

Removed from next, as next is now reserved for near misses from the last milestone --johnthetubaguyThis would be a nice addition. Could you provide a little more information about the specifics of it though? Does disabled just mean don't schedule to it anymore, or something else? Would it extend a current API or add a new endpoint? Is there anything else a user of this feature should be aware of? --alaski

Without wanting to make things very complicated, typical status that I could imagine would be for active, draining, read-only and inactive. active would be the usual state. draining would respond to queries, migrations and deletes but refuse new schedule requests. read-only would only permit queries and inactive would not respond. Depending on the intervention, all of these could be useful. user story for draining is where the hardware in a cell is to be re-used and you want to move the workload off but not schedule new VMs. read-only would where, for example, you are doing a database migration and don't want new entries during that migration. inactive would be where you really don't want the cell to answer. There are probably other components in OpenStack that also exhibit this behaviour.

That's great information. Would all of that be in scope for this blueprint? That's quite a bit more work than just enabled/disabled. I'd like to approve this but it needs a bit more work in certain areas. https://wiki.openstack.org/wiki/Blueprints#Blueprint_Review_Criteria is a helpful guide for the additional details that are necessary. Basically I'd like to fully understand the user impact, user in this case being an admin, and what's in scope for the change. I can try to catch someone on irc if that would help, or feel free to ping me (alaski) to discuss. I'm UTC-5.

According to Tim's information, it's would be more flexible and extensible for cell management if status for cell could be controllable, i will add this to the specifics.

It's more that the status is more than just an ACTIVE boolean but more of a status as for hypervisors or VMs. A staged implementation with the states active/disabled (i.e. completely functional versus would not respond) and then additional states could be added as the use cases are clarified. -- Tim

deferred from icehouse-3 to "next": http://lists.openstack.org/pipermail/openstack-dev/2014-February/026335.html

Removed from next, as next is now reserved for near misses from the last milestone --johnthetubaguy

Marking this blueprint as definition: Drafting. If you are still working on this, please re-submit via nova-specs. If not, please mark as obsolete, and add a quick comment to describe why. --johnthetubaguy (20th April 2014)This would be a nice addition. Could you provide a little more information about the specifics of it though? Does disabled just mean don't schedule to it anymore, or something else? Would it extend a current API or add a new endpoint? Is there anything else a user of this feature should be aware of? --alaski

Without wanting to make things very complicated, typical status that I could imagine would be for active, draining, read-only and inactive. active would be the usual state. draining would respond to queries, migrations and deletes but refuse new schedule requests. read-only would only permit queries and inactive would not respond. Depending on the intervention, all of these could be useful. user story for draining is where the hardware in a cell is to be re-used and you want to move the workload off but not schedule new VMs. read-only would where, for example, you are doing a database migration and don't want new entries during that migration. inactive would be where you really don't want the cell to answer. There are probably other components in OpenStack that also exhibit this behaviour.

That's great information. Would all of that be in scope for this blueprint? That's quite a bit more work than just enabled/disabled. I'd like to approve this but it needs a bit more work in certain areas. https://wiki.openstack.org/wiki/Blueprints#Blueprint_Review_Criteria is a helpful guide for the additional details that are necessary. Basically I'd like to fully understand the user impact, user in this case being an admin, and what's in scope for the change. I can try to catch someone on irc if that would help, or feel free to ping me (alaski) to discuss. I'm UTC-5.

According to Tim's information, it's would be more flexible and extensible for cell management if status for cell could be controllable, i will add this to the specifics.

It's more that the status is more than just an ACTIVE boolean but more of a status as for hypervisors or VMs. A staged implementation with the states active/disabled (i.e. completely functional versus would not respond) and then additional states could be added as the use cases are clarified. -- Tim

deferred from icehouse-3 to "next": http://lists.openstack.org/pipermail/openstack-dev/2014-February/026335.html

Removed from next, as next is now reserved for near misses from the last milestone --johnthetubaguyThis would be a nice addition. Could you provide a little more information about the specifics of it though? Does disabled just mean don't schedule to it anymore, or something else? Would it extend a current API or add a new endpoint? Is there anything else a user of this feature should be aware of? --alaski

Without wanting to make things very complicated, typical status that I could imagine would be for active, draining, read-only and inactive. active would be the usual state. draining would respond to queries, migrations and deletes but refuse new schedule requests. read-only would only permit queries and inactive would not respond. Depending on the intervention, all of these could be useful. user story for draining is where the hardware in a cell is to be re-used and you want to move the workload off but not schedule new VMs. read-only would where, for example, you are doing a database migration and don't want new entries during that migration. inactive would be where you really don't want the cell to answer. There are probably other components in OpenStack that also exhibit this behaviour.

That's great information. Would all of that be in scope for this blueprint? That's quite a bit more work than just enabled/disabled. I'd like to approve this but it needs a bit more work in certain areas. https://wiki.openstack.org/wiki/Blueprints#Blueprint_Review_Criteria is a helpful guide for the additional details that are necessary. Basically I'd like to fully understand the user impact, user in this case being an admin, and what's in scope for the change. I can try to catch someone on irc if that would help, or feel free to ping me (alaski) to discuss. I'm UTC-5.

According to Tim's information, it's would be more flexible and extensible for cell management if status for cell could be controllable, i will add this to the specifics.

It's more that the status is more than just an ACTIVE boolean but more of a status as for hypervisors or VMs. A staged implementation with the states active/disabled (i.e. completely functional versus would not respond) and then additional states could be added as the use cases are clarified. -- Tim

deferred from icehouse-3 to "next": http://lists.openstack.org/pipermail/openstack-dev/2014-February/026335.html

Removed from next, as next is now reserved for near misses from the last milestone --johnthetubaguy

Marking this blueprint as definition: Drafting. If you are still working on this, please re-submit via nova-specs. If not, please mark as obsolete, and add a quick comment to describe why. --johnthetubaguy (20th April 2014)

Marking this blueprint as definition: Drafting. If you are still working on this, please re-submit via nova-specs. If not, please mark as obsolete, and add a quick comment to describe why. --johnthetubaguy (20th April 2014)