Re: [openstack-dev] [Nova] RFC Host Maintenance
Hi, Maintenance was discussed in the OpenStack summit in "Ops: Nova Maintenance - how do you do it?" It was decided the best alternative is just to expose the nova-compute disabled_reason to owner of the server. This field can then have URL to more detailed status given in external tool. There was also all kind of requirements from operators that we did not have time to go through, but those are as a base what the external tool could handle. As result, original spec is now abandoned: https://review.openstack.org/296995 And new made: https://review.openstack.org/310510 Also as part of the whole story, filtering by host_status: https://review.openstack.org/276671 Thank you for all the comments and getting this NFV requirement forwards. Br, Tomi > -Original Message- > From: Juvonen, Tomi (Nokia - FI/Espoo) > Sent: Wednesday, April 13, 2016 2:02 AM > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org> > Subject: RE: [openstack-dev] [Nova] RFC Host Maintenance > > > -Original Message- > > From: EXT Jim Rollenhagen [mailto:j...@jimrollenhagen.com] > > Sent: Tuesday, April 12, 2016 4:46 PM > > To: OpenStack Development Mailing List (not for usage questions) > > <openstack-dev@lists.openstack.org> > > Subject: Re: [openstack-dev] [Nova] RFC Host Maintenance > > > > On Thu, Apr 07, 2016 at 06:36:20AM -0400, Sean Dague wrote: > > > On 04/07/2016 03:26 AM, Juvonen, Tomi (Nokia - FI/Espoo) wrote: > > > > Hi Nova, Ops, stackers, > > > > > > > > I am trying to figure out different use cases and requirements there > > > > would be for host maintenance and would like to get feedback and > > > > transfer all this to spec and discussion what could and should land > for > > > > Nova or other places. > > > > > > > > As working in OPNFV Doctor project that has the Telco perspective > about > > > > related requirements, I started to draft a spec based on something > > > > smaller that would be nice to have in Nova and less complicated to > have > > > > it in single cycle. Anyhow the feedback from Nova API team was to > look > > > > this as a whole and gather more. This is why asking this here and not > > > > just trough spec, to get input for requirements and use cases with > > wider > > > > audience. Here is the draft spec proposing first just maintenance > > window > > > > to be added: > > > > _https://review.openstack.org/296995/_ > > > > > > > > Here is link to OPNFV Doctor requirements: > > > > _http://artifacts.opnfv.org/doctor/docs/requirements/02- > > use_cases.html#nvfi-maintenance_ > > > > _http://artifacts.opnfv.org/doctor/docs/requirements/03- > > architecture.html#nfvi-maintenance_ > > > > _http://artifacts.opnfv.org/doctor/docs/requirements/05- > > implementation.html#nfvi-maintenance_ > > > > > > > > Here is what I could transfer as use cases, but would ask feedback to > > > > get more: > > > > > > > > As admin I want to set maintenance period for certain host. > > > > > > > > As admin I want to know when host is ready to actions to be done by > > admin > > > > during the maintenance. Meaning physical resources are emptied. > > > > > > > > As owner of a server I want to prepare for maintenance to minimize > > downtime, > > > > keep capacity on needed level and switch HA service to server not > > > > affected by > > > > maintenance. > > > > > > > > As owner of a server I want to know when my servers will be down > > because of > > > > host maintenance as it might be servers are not moved to another > host. > > > > > > > > As owner of a server I want to know if host is to be totally removed, > > so > > > > instead of keeping my servers on host during maintenance, I want to > > move > > > > them > > > > to somewhere else. > > > > > > > > As owner of a server I want to send acknowledgement to be ready for > > host > > > > maintenance and I want to state if servers are to be moved or kept on > > host. > > > > Removal and creating of server is in owner's control already. > > Optionally > > > > server > > > > Configuration data could hold information about automatic actions to > be > > > > done > > > > when host is going down unexpectedly or in contro
Re: [openstack-dev] [Nova] RFC Host Maintenance
> -Original Message- > From: EXT Jim Rollenhagen [mailto:j...@jimrollenhagen.com] > Sent: Tuesday, April 12, 2016 4:46 PM > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Nova] RFC Host Maintenance > > On Thu, Apr 07, 2016 at 06:36:20AM -0400, Sean Dague wrote: > > On 04/07/2016 03:26 AM, Juvonen, Tomi (Nokia - FI/Espoo) wrote: > > > Hi Nova, Ops, stackers, > > > > > > I am trying to figure out different use cases and requirements there > > > would be for host maintenance and would like to get feedback and > > > transfer all this to spec and discussion what could and should land for > > > Nova or other places. > > > > > > As working in OPNFV Doctor project that has the Telco perspective about > > > related requirements, I started to draft a spec based on something > > > smaller that would be nice to have in Nova and less complicated to have > > > it in single cycle. Anyhow the feedback from Nova API team was to look > > > this as a whole and gather more. This is why asking this here and not > > > just trough spec, to get input for requirements and use cases with > wider > > > audience. Here is the draft spec proposing first just maintenance > window > > > to be added: > > > _https://review.openstack.org/296995/_ > > > > > > Here is link to OPNFV Doctor requirements: > > > _http://artifacts.opnfv.org/doctor/docs/requirements/02- > use_cases.html#nvfi-maintenance_ > > > _http://artifacts.opnfv.org/doctor/docs/requirements/03- > architecture.html#nfvi-maintenance_ > > > _http://artifacts.opnfv.org/doctor/docs/requirements/05- > implementation.html#nfvi-maintenance_ > > > > > > Here is what I could transfer as use cases, but would ask feedback to > > > get more: > > > > > > As admin I want to set maintenance period for certain host. > > > > > > As admin I want to know when host is ready to actions to be done by > admin > > > during the maintenance. Meaning physical resources are emptied. > > > > > > As owner of a server I want to prepare for maintenance to minimize > downtime, > > > keep capacity on needed level and switch HA service to server not > > > affected by > > > maintenance. > > > > > > As owner of a server I want to know when my servers will be down > because of > > > host maintenance as it might be servers are not moved to another host. > > > > > > As owner of a server I want to know if host is to be totally removed, > so > > > instead of keeping my servers on host during maintenance, I want to > move > > > them > > > to somewhere else. > > > > > > As owner of a server I want to send acknowledgement to be ready for > host > > > maintenance and I want to state if servers are to be moved or kept on > host. > > > Removal and creating of server is in owner's control already. > Optionally > > > server > > > Configuration data could hold information about automatic actions to be > > > done > > > when host is going down unexpectedly or in controlled manner. Also > > > actions at > > > the same if down permanently or only temporarily. Still this needs > > > acknowledgement from server owner as he needs time for application > level > > > controlled HA service switchover. > > > > While I definitely understand the value of these in a deployement, I'm a > > bit concerned of baking all this structured data into Nova itself. As it > > effectively means putting some degree of a ticket management system in > > Nova that's specific to a workflow you've decided on here. Baked in > > workflow is hard to change when the needs of an industry do. > > > > My counter proposal on your spec was to provide a free form field > > associated with maintenance mode which could contain a url linking to > > the details. This could be a jira ticket, or a REST url for some other > > service. This would actually be much like how we handle images in Nova, > > with a url to glance to find more info. > > FWIW, this is what we do in ironic. A maintenance boolean, and a > maintenance_reason text field that operators can dump text/links/etc in. > > As an example: > $ ironic node-set-maintenance $uuid on --reason "Dead fiber // ticket 123 > // jroll 2016/04/12" > > It's worked well for Rackspace's deployment, at least, and I seem to > remember others being happy with it as well.
Re: [openstack-dev] [Nova] RFC Host Maintenance
On Thu, Apr 07, 2016 at 06:36:20AM -0400, Sean Dague wrote: > On 04/07/2016 03:26 AM, Juvonen, Tomi (Nokia - FI/Espoo) wrote: > > Hi Nova, Ops, stackers, > > > > I am trying to figure out different use cases and requirements there > > would be for host maintenance and would like to get feedback and > > transfer all this to spec and discussion what could and should land for > > Nova or other places. > > > > As working in OPNFV Doctor project that has the Telco perspective about > > related requirements, I started to draft a spec based on something > > smaller that would be nice to have in Nova and less complicated to have > > it in single cycle. Anyhow the feedback from Nova API team was to look > > this as a whole and gather more. This is why asking this here and not > > just trough spec, to get input for requirements and use cases with wider > > audience. Here is the draft spec proposing first just maintenance window > > to be added: > > _https://review.openstack.org/296995/_ > > > > Here is link to OPNFV Doctor requirements: > > _http://artifacts.opnfv.org/doctor/docs/requirements/02-use_cases.html#nvfi-maintenance_ > > _http://artifacts.opnfv.org/doctor/docs/requirements/03-architecture.html#nfvi-maintenance_ > > _http://artifacts.opnfv.org/doctor/docs/requirements/05-implementation.html#nfvi-maintenance_ > > > > Here is what I could transfer as use cases, but would ask feedback to > > get more: > > > > As admin I want to set maintenance period for certain host. > > > > As admin I want to know when host is ready to actions to be done by admin > > during the maintenance. Meaning physical resources are emptied. > > > > As owner of a server I want to prepare for maintenance to minimize downtime, > > keep capacity on needed level and switch HA service to server not > > affected by > > maintenance. > > > > As owner of a server I want to know when my servers will be down because of > > host maintenance as it might be servers are not moved to another host. > > > > As owner of a server I want to know if host is to be totally removed, so > > instead of keeping my servers on host during maintenance, I want to move > > them > > to somewhere else. > > > > As owner of a server I want to send acknowledgement to be ready for host > > maintenance and I want to state if servers are to be moved or kept on host. > > Removal and creating of server is in owner's control already. Optionally > > server > > Configuration data could hold information about automatic actions to be > > done > > when host is going down unexpectedly or in controlled manner. Also > > actions at > > the same if down permanently or only temporarily. Still this needs > > acknowledgement from server owner as he needs time for application level > > controlled HA service switchover. > > While I definitely understand the value of these in a deployement, I'm a > bit concerned of baking all this structured data into Nova itself. As it > effectively means putting some degree of a ticket management system in > Nova that's specific to a workflow you've decided on here. Baked in > workflow is hard to change when the needs of an industry do. > > My counter proposal on your spec was to provide a free form field > associated with maintenance mode which could contain a url linking to > the details. This could be a jira ticket, or a REST url for some other > service. This would actually be much like how we handle images in Nova, > with a url to glance to find more info. FWIW, this is what we do in ironic. A maintenance boolean, and a maintenance_reason text field that operators can dump text/links/etc in. As an example: $ ironic node-set-maintenance $uuid on --reason "Dead fiber // ticket 123 // jroll 2016/04/12" It's worked well for Rackspace's deployment, at least, and I seem to remember others being happy with it as well. // jim > > -Sean > > -- > Sean Dague > http://dague.net > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] RFC Host Maintenance
Hi, > -Original Message- > From: EXT Balázs Gibizer [mailto:balazs.gibi...@ericsson.com] > Sent: Tuesday, April 12, 2016 10:14 AM > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Nova] RFC Host Maintenance > > > -Original Message- > > From: Juvonen, Tomi (Nokia - FI/Espoo) [mailto:tomi.juvo...@nokia.com] > > Sent: April 11, 2016 09:06 > > > > Hi, > > > > Looking the discussion so far: > > -Suggestion to have extended information for maintenance to somewhere > > outside Nova. > > -Notification about Nova state changes. > > > > So how about if the whole logic of maintenance would be triggered by Nova > > API disable/enable service notification, but otherwise the business logic > > would be outside Nova?! > > I think in this scenario the module that holds the business logic outside > of > Nova can be used by the admin to trigger the maintenance and one of the > business logic piece would be to set the respective service(s) disabled in > OpenStack. Yes. > > > > > -Extended host information needed by maintenance should be outside of > > Nova (extended information like maintenance window, more precise > > maintenance state and version information) -Extended server information > > needed by maintenance should be outside of Nova (configuration for > > automatic actions in different use cases) -The communicating and action > flow > > with server owner and admin should be outside of Nova. > > > > One thing is now as there is accepted that host fault monitoring is to be > > external, it might be best fit also for some of this maintenance logic. > > Monitoring SW is also the place with the best knowledge about the host > > state and if looking to build any automated actions on fault scenarios, > then > > surely maintenance would be close to that also. Monitoring also need to > > know what host is in maintenance. Logic is very similar from server point > of > > view when looking server actions and communication with server owner. > > > > Might this be the way to go? > > What impact this solution has on Nova? As far as I see it is very limited > if not > zero. If the conclusion is really this, then by fast no changes to Nova. > > Cheers, > Gibi > > > > > Br, > > Tomi > > > > > -Original Message- > > > From: EXT Qiming Teng [mailto:teng...@linux.vnet.ibm.com] > > > Sent: Friday, April 08, 2016 2:38 PM > > > To: OpenStack Development Mailing List (not for usage questions) > > > <openstack-dev@lists.openstack.org> > > > Subject: Re: [openstack-dev] [Nova] RFC Host Maintenance > > > > > > On Fri, Apr 08, 2016 at 09:52:31AM +, Balázs Gibizer wrote: > > > > > -Original Message- > > > > > From: Qiming Teng [mailto:teng...@linux.vnet.ibm.com] > > > > > Sent: April 07, 2016 15:42 > > > > > > > > > > The only gap based on my limited understanding is that nova is not > > > emitting > > > > > events compute host state changes. This knowledge is still kept > > > > > inside > > > nova > > > > > as some service states. If that info is posted to oslo messaging, > > > > > a lot > > > of usage > > > > > scenarios can be enabled and we can avoid too much churns to nova > > > itself. > > > > > > > > Nova does not really know the state of the compute host, it knows > > > > only > > > the state of the nova-compute service running on the compute host. In > > > Mitaka we added notification about the service status[2]. > > > > Also there is a proposal about notification about hypervisor info > > > > change > > > [1]. > > > > > > > > Cheers, > > > > Gibi > > > > > > > > [1] https://review.openstack.org/#/c/299807/ > > > > [2] > > > > http://docs.openstack.org/developer/nova/notifications.html#existing > > > > - > > > versioned-notifications > > > > > > > > > > Thanks for the sharing, Balázs. The mitaka service status notification > > > looks pretty useful, I'll try it. > > > > > > Regards, > > > Qiming > > > > > > > > > > > > > Regards, > > > > > Qiming > > > > > > > > > > > > > > > > > _
Re: [openstack-dev] [Nova] RFC Host Maintenance
> -Original Message- > From: Juvonen, Tomi (Nokia - FI/Espoo) [mailto:tomi.juvo...@nokia.com] > Sent: April 11, 2016 09:06 > > Hi, > > Looking the discussion so far: > -Suggestion to have extended information for maintenance to somewhere > outside Nova. > -Notification about Nova state changes. > > So how about if the whole logic of maintenance would be triggered by Nova > API disable/enable service notification, but otherwise the business logic > would be outside Nova?! I think in this scenario the module that holds the business logic outside of Nova can be used by the admin to trigger the maintenance and one of the business logic piece would be to set the respective service(s) disabled in OpenStack. > > -Extended host information needed by maintenance should be outside of > Nova (extended information like maintenance window, more precise > maintenance state and version information) -Extended server information > needed by maintenance should be outside of Nova (configuration for > automatic actions in different use cases) -The communicating and action flow > with server owner and admin should be outside of Nova. > > One thing is now as there is accepted that host fault monitoring is to be > external, it might be best fit also for some of this maintenance logic. > Monitoring SW is also the place with the best knowledge about the host > state and if looking to build any automated actions on fault scenarios, then > surely maintenance would be close to that also. Monitoring also need to > know what host is in maintenance. Logic is very similar from server point of > view when looking server actions and communication with server owner. > > Might this be the way to go? What impact this solution has on Nova? As far as I see it is very limited if not zero. Cheers, Gibi > > Br, > Tomi > > > -Original Message- > > From: EXT Qiming Teng [mailto:teng...@linux.vnet.ibm.com] > > Sent: Friday, April 08, 2016 2:38 PM > > To: OpenStack Development Mailing List (not for usage questions) > > <openstack-dev@lists.openstack.org> > > Subject: Re: [openstack-dev] [Nova] RFC Host Maintenance > > > > On Fri, Apr 08, 2016 at 09:52:31AM +, Balázs Gibizer wrote: > > > > -Original Message- > > > > From: Qiming Teng [mailto:teng...@linux.vnet.ibm.com] > > > > Sent: April 07, 2016 15:42 > > > > > > > > The only gap based on my limited understanding is that nova is not > > emitting > > > > events compute host state changes. This knowledge is still kept > > > > inside > > nova > > > > as some service states. If that info is posted to oslo messaging, > > > > a lot > > of usage > > > > scenarios can be enabled and we can avoid too much churns to nova > > itself. > > > > > > Nova does not really know the state of the compute host, it knows > > > only > > the state of the nova-compute service running on the compute host. In > > Mitaka we added notification about the service status[2]. > > > Also there is a proposal about notification about hypervisor info > > > change > > [1]. > > > > > > Cheers, > > > Gibi > > > > > > [1] https://review.openstack.org/#/c/299807/ > > > [2] > > > http://docs.openstack.org/developer/nova/notifications.html#existing > > > - > > versioned-notifications > > > > > > > Thanks for the sharing, Balázs. The mitaka service status notification > > looks pretty useful, I'll try it. > > > > Regards, > > Qiming > > > > > > > > > > Regards, > > > > Qiming > > > > > > > > > > > > > __ > > > > > > > > OpenStack Development Mailing List (not for usage questions) > > > > Unsubscribe: OpenStack-dev- > > > > requ...@lists.openstack.org?subject:unsubscribe > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > __ > > > > > > OpenStack Development Mailing List (not for usage questions) > > > Unsubscribe: OpenStack-dev- > > requ...@lists.openstack.org?subject:unsubscribe > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > __ > > > OpenStack Development Mailing Lis
Re: [openstack-dev] [Nova] RFC Host Maintenance
Hi, Looking the discussion so far: -Suggestion to have extended information for maintenance to somewhere outside Nova. -Notification about Nova state changes. So how about if the whole logic of maintenance would be triggered by Nova API disable/enable service notification, but otherwise the business logic would be outside Nova?! -Extended host information needed by maintenance should be outside of Nova (extended information like maintenance window, more precise maintenance state and version information) -Extended server information needed by maintenance should be outside of Nova (configuration for automatic actions in different use cases) -The communicating and action flow with server owner and admin should be outside of Nova. One thing is now as there is accepted that host fault monitoring is to be external, it might be best fit also for some of this maintenance logic. Monitoring SW is also the place with the best knowledge about the host state and if looking to build any automated actions on fault scenarios, then surely maintenance would be close to that also. Monitoring also need to know what host is in maintenance. Logic is very similar from server point of view when looking server actions and communication with server owner. Might this be the way to go? Br, Tomi > -Original Message- > From: EXT Qiming Teng [mailto:teng...@linux.vnet.ibm.com] > Sent: Friday, April 08, 2016 2:38 PM > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Nova] RFC Host Maintenance > > On Fri, Apr 08, 2016 at 09:52:31AM +, Balázs Gibizer wrote: > > > -Original Message- > > > From: Qiming Teng [mailto:teng...@linux.vnet.ibm.com] > > > Sent: April 07, 2016 15:42 > > > > > > The only gap based on my limited understanding is that nova is not > emitting > > > events compute host state changes. This knowledge is still kept inside > nova > > > as some service states. If that info is posted to oslo messaging, a lot > of usage > > > scenarios can be enabled and we can avoid too much churns to nova > itself. > > > > Nova does not really know the state of the compute host, it knows only > the state of the nova-compute service running on the compute host. In > Mitaka we added notification about the service status[2]. > > Also there is a proposal about notification about hypervisor info change > [1]. > > > > Cheers, > > Gibi > > > > [1] https://review.openstack.org/#/c/299807/ > > [2] http://docs.openstack.org/developer/nova/notifications.html#existing- > versioned-notifications > > > > Thanks for the sharing, Balázs. The mitaka service status notification > looks pretty useful, I'll try it. > > Regards, > Qiming > > > > > > > Regards, > > > Qiming > > > > > > > > > __ > > > > > > OpenStack Development Mailing List (not for usage questions) > > > Unsubscribe: OpenStack-dev- > > > requ...@lists.openstack.org?subject:unsubscribe > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: OpenStack-dev- > requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] RFC Host Maintenance
On Fri, Apr 08, 2016 at 09:52:31AM +, Balázs Gibizer wrote: > > -Original Message- > > From: Qiming Teng [mailto:teng...@linux.vnet.ibm.com] > > Sent: April 07, 2016 15:42 > > > > The only gap based on my limited understanding is that nova is not emitting > > events compute host state changes. This knowledge is still kept inside nova > > as some service states. If that info is posted to oslo messaging, a lot of > > usage > > scenarios can be enabled and we can avoid too much churns to nova itself. > > Nova does not really know the state of the compute host, it knows only the > state of the nova-compute service running on the compute host. In Mitaka we > added notification about the service status[2]. > Also there is a proposal about notification about hypervisor info change [1]. > > Cheers, > Gibi > > [1] https://review.openstack.org/#/c/299807/ > [2] > http://docs.openstack.org/developer/nova/notifications.html#existing-versioned-notifications > > Thanks for the sharing, Balázs. The mitaka service status notification looks pretty useful, I'll try it. Regards, Qiming > > > > Regards, > > Qiming > > > > > > __ > > > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: OpenStack-dev- > > requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] RFC Host Maintenance
> -Original Message- > From: Qiming Teng [mailto:teng...@linux.vnet.ibm.com] > Sent: April 07, 2016 15:42 > > The only gap based on my limited understanding is that nova is not emitting > events compute host state changes. This knowledge is still kept inside nova > as some service states. If that info is posted to oslo messaging, a lot of > usage > scenarios can be enabled and we can avoid too much churns to nova itself. Nova does not really know the state of the compute host, it knows only the state of the nova-compute service running on the compute host. In Mitaka we added notification about the service status[2]. Also there is a proposal about notification about hypervisor info change [1]. Cheers, Gibi [1] https://review.openstack.org/#/c/299807/ [2] http://docs.openstack.org/developer/nova/notifications.html#existing-versioned-notifications > > Regards, > Qiming > > > __ > > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev- > requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] RFC Host Maintenance
The only gap based on my limited understanding is that nova is not emitting events compute host state changes. This knowledge is still kept inside nova as some service states. If that info is posted to oslo messaging, a lot of usage scenarios can be enabled and we can avoid too much churns to nova itself. Regards, Qiming __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] RFC Host Maintenance
Thanks Sean, I totally understand your comment and this logic might really be somewhere else, not to overload Nova with all kind of things and the level of exposing you suggested might then be enough. Anyhow I am also asking more user or operator perspectives to get more use cases. Surely if building this mostly externally (to Nova) those could also be added later. Br, Tomi > -Original Message- > From: EXT Sean Dague [mailto:s...@dague.net] > Sent: Thursday, April 07, 2016 1:36 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Nova] RFC Host Maintenance > > On 04/07/2016 03:26 AM, Juvonen, Tomi (Nokia - FI/Espoo) wrote: > > Hi Nova, Ops, stackers, > > > > I am trying to figure out different use cases and requirements there > > would be for host maintenance and would like to get feedback and > > transfer all this to spec and discussion what could and should land for > > Nova or other places. > > > > As working in OPNFV Doctor project that has the Telco perspective about > > related requirements, I started to draft a spec based on something > > smaller that would be nice to have in Nova and less complicated to have > > it in single cycle. Anyhow the feedback from Nova API team was to look > > this as a whole and gather more. This is why asking this here and not > > just trough spec, to get input for requirements and use cases with wider > > audience. Here is the draft spec proposing first just maintenance window > > to be added: > > _https://review.openstack.org/296995/_ > > > > Here is link to OPNFV Doctor requirements: > > _http://artifacts.opnfv.org/doctor/docs/requirements/02- > use_cases.html#nvfi-maintenance_ > > _http://artifacts.opnfv.org/doctor/docs/requirements/03- > architecture.html#nfvi-maintenance_ > > _http://artifacts.opnfv.org/doctor/docs/requirements/05- > implementation.html#nfvi-maintenance_ > > > > Here is what I could transfer as use cases, but would ask feedback to > > get more: > > > > As admin I want to set maintenance period for certain host. > > > > As admin I want to know when host is ready to actions to be done by admin > > during the maintenance. Meaning physical resources are emptied. > > > > As owner of a server I want to prepare for maintenance to minimize > downtime, > > keep capacity on needed level and switch HA service to server not > > affected by > > maintenance. > > > > As owner of a server I want to know when my servers will be down because > of > > host maintenance as it might be servers are not moved to another host. > > > > As owner of a server I want to know if host is to be totally removed, so > > instead of keeping my servers on host during maintenance, I want to move > > them > > to somewhere else. > > > > As owner of a server I want to send acknowledgement to be ready for host > > maintenance and I want to state if servers are to be moved or kept on > host. > > Removal and creating of server is in owner's control already. Optionally > > server > > Configuration data could hold information about automatic actions to be > > done > > when host is going down unexpectedly or in controlled manner. Also > > actions at > > the same if down permanently or only temporarily. Still this needs > > acknowledgement from server owner as he needs time for application level > > controlled HA service switchover. > > While I definitely understand the value of these in a deployement, I'm a > bit concerned of baking all this structured data into Nova itself. As it > effectively means putting some degree of a ticket management system in > Nova that's specific to a workflow you've decided on here. Baked in > workflow is hard to change when the needs of an industry do. > > My counter proposal on your spec was to provide a free form field > associated with maintenance mode which could contain a url linking to > the details. This could be a jira ticket, or a REST url for some other > service. This would actually be much like how we handle images in Nova, > with a url to glance to find more info. > > -Sean > > -- > Sean Dague > http://dague.net > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] RFC Host Maintenance
On 04/07/2016 03:26 AM, Juvonen, Tomi (Nokia - FI/Espoo) wrote: > Hi Nova, Ops, stackers, > > I am trying to figure out different use cases and requirements there > would be for host maintenance and would like to get feedback and > transfer all this to spec and discussion what could and should land for > Nova or other places. > > As working in OPNFV Doctor project that has the Telco perspective about > related requirements, I started to draft a spec based on something > smaller that would be nice to have in Nova and less complicated to have > it in single cycle. Anyhow the feedback from Nova API team was to look > this as a whole and gather more. This is why asking this here and not > just trough spec, to get input for requirements and use cases with wider > audience. Here is the draft spec proposing first just maintenance window > to be added: > _https://review.openstack.org/296995/_ > > Here is link to OPNFV Doctor requirements: > _http://artifacts.opnfv.org/doctor/docs/requirements/02-use_cases.html#nvfi-maintenance_ > _http://artifacts.opnfv.org/doctor/docs/requirements/03-architecture.html#nfvi-maintenance_ > _http://artifacts.opnfv.org/doctor/docs/requirements/05-implementation.html#nfvi-maintenance_ > > Here is what I could transfer as use cases, but would ask feedback to > get more: > > As admin I want to set maintenance period for certain host. > > As admin I want to know when host is ready to actions to be done by admin > during the maintenance. Meaning physical resources are emptied. > > As owner of a server I want to prepare for maintenance to minimize downtime, > keep capacity on needed level and switch HA service to server not > affected by > maintenance. > > As owner of a server I want to know when my servers will be down because of > host maintenance as it might be servers are not moved to another host. > > As owner of a server I want to know if host is to be totally removed, so > instead of keeping my servers on host during maintenance, I want to move > them > to somewhere else. > > As owner of a server I want to send acknowledgement to be ready for host > maintenance and I want to state if servers are to be moved or kept on host. > Removal and creating of server is in owner's control already. Optionally > server > Configuration data could hold information about automatic actions to be > done > when host is going down unexpectedly or in controlled manner. Also > actions at > the same if down permanently or only temporarily. Still this needs > acknowledgement from server owner as he needs time for application level > controlled HA service switchover. While I definitely understand the value of these in a deployement, I'm a bit concerned of baking all this structured data into Nova itself. As it effectively means putting some degree of a ticket management system in Nova that's specific to a workflow you've decided on here. Baked in workflow is hard to change when the needs of an industry do. My counter proposal on your spec was to provide a free form field associated with maintenance mode which could contain a url linking to the details. This could be a jira ticket, or a REST url for some other service. This would actually be much like how we handle images in Nova, with a url to glance to find more info. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
