Re: [openstack-dev] [goals][upgrade-checkers] Week R-29 Update
On 09/22/2018 11:15 AM, Matt Riedemann wrote: On 9/21/2018 4:19 PM, Ben Nemec wrote: * The only two projects that I'm aware of with patches up at this point are monasca [2] and designate [3]. The monasca one is tricky because as I've found going through release notes for some projects, they don't really have any major upgrade impacts so writing checks is not obvious. I don't have a great solution here. What monasca has done is add the framework with a noop check. If others are in the same situation, I'd like to hear your thoughts on what you think makes sense here. The alternative is these projects opt out of the goal for Stein and just add the check code later when it makes sense (but people might forget or not care to do that later if it's not a goal). My inclination is for the command to exist with a noop check, the main reason being that if we create it for everyone this cycle then the deployment tools can implement calls to the status commands all at once. If we wait until checks are needed then someone has to not only implement it in the service but also remember to go update all of the deployment tools. Implementing a noop check should be pretty trivial with the library so it isn't a huge imposition. Yeah, I agree, and I've left comments on the patch to give some ideas on how to write the noop check with a description that explains it's an initial check but doesn't really do anything. The alternative would be to dump the table header for the results but then not have any rows, which could be more confusing. +1 to "this page intentionally left blank", hopefully without the logical contradiction those pages always create. ;-) __ 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] [goals][upgrade-checkers] Week R-29 Update
On Fri, Sep 21, 2018 at 04:19:35PM -0500, Ben Nemec wrote: > > > On 09/21/2018 03:53 PM, Matt Riedemann wrote: > > Updates for this week: > > > > * As bnemec noted in the last update [1], he's making some progress with > > the oslo.upgradecheck library. He's retrofitting the nova-status upgrade > > check code to use the library and has a patch up for designate to use > > it. > > > > * The only two projects that I'm aware of with patches up at this point > > are monasca [2] and designate [3]. The monasca one is tricky because as > > I've found going through release notes for some projects, they don't > > really have any major upgrade impacts so writing checks is not obvious. > > I don't have a great solution here. What monasca has done is add the > > framework with a noop check. If others are in the same situation, I'd > > like to hear your thoughts on what you think makes sense here. The > > alternative is these projects opt out of the goal for Stein and just add > > the check code later when it makes sense (but people might forget or not > > care to do that later if it's not a goal). > > My inclination is for the command to exist with a noop check, the main > reason being that if we create it for everyone this cycle then the > deployment tools can implement calls to the status commands all at once. If > we wait until checks are needed then someone has to not only implement it in > the service but also remember to go update all of the deployment tools. > Implementing a noop check should be pretty trivial with the library so it > isn't a huge imposition. > This was brought up at one point, and I think the preference for those involved at the time was to still have the upgrade check available, even if it is just a noop. The reason being as you state that it makes things consistent for deployment tooling to be able to always run the check, regardless which project is being done. Sean __ 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] [goals][upgrade-checkers] Week R-29 Update
On 9/21/2018 4:19 PM, Ben Nemec wrote: * The only two projects that I'm aware of with patches up at this point are monasca [2] and designate [3]. The monasca one is tricky because as I've found going through release notes for some projects, they don't really have any major upgrade impacts so writing checks is not obvious. I don't have a great solution here. What monasca has done is add the framework with a noop check. If others are in the same situation, I'd like to hear your thoughts on what you think makes sense here. The alternative is these projects opt out of the goal for Stein and just add the check code later when it makes sense (but people might forget or not care to do that later if it's not a goal). My inclination is for the command to exist with a noop check, the main reason being that if we create it for everyone this cycle then the deployment tools can implement calls to the status commands all at once. If we wait until checks are needed then someone has to not only implement it in the service but also remember to go update all of the deployment tools. Implementing a noop check should be pretty trivial with the library so it isn't a huge imposition. Yeah, I agree, and I've left comments on the patch to give some ideas on how to write the noop check with a description that explains it's an initial check but doesn't really do anything. The alternative would be to dump the table header for the results but then not have any rows, which could be more confusing. -- Thanks, Matt __ 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] [goals][upgrade-checkers] Week R-29 Update
On 9/21/2018 3:53 PM, Matt Riedemann wrote: * The reference docs I wrote for writing upgrade checks is published now [4]. As I've been answering some questions in storyboard and IRC, it's obvious that I need to add some FAQs into those docs because I've taken some of this for granted on how it works in nova, so I'll push a docs change for some of that as well and link it back into the story. https://review.openstack.org/#/c/604486/ for anyone that thinks I missed something. -- Thanks, Matt __ 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] [goals][upgrade-checkers] Week R-29 Update
On 09/21/2018 03:53 PM, Matt Riedemann wrote: Updates for this week: * As bnemec noted in the last update [1], he's making some progress with the oslo.upgradecheck library. He's retrofitting the nova-status upgrade check code to use the library and has a patch up for designate to use it. * The only two projects that I'm aware of with patches up at this point are monasca [2] and designate [3]. The monasca one is tricky because as I've found going through release notes for some projects, they don't really have any major upgrade impacts so writing checks is not obvious. I don't have a great solution here. What monasca has done is add the framework with a noop check. If others are in the same situation, I'd like to hear your thoughts on what you think makes sense here. The alternative is these projects opt out of the goal for Stein and just add the check code later when it makes sense (but people might forget or not care to do that later if it's not a goal). My inclination is for the command to exist with a noop check, the main reason being that if we create it for everyone this cycle then the deployment tools can implement calls to the status commands all at once. If we wait until checks are needed then someone has to not only implement it in the service but also remember to go update all of the deployment tools. Implementing a noop check should be pretty trivial with the library so it isn't a huge imposition. * The reference docs I wrote for writing upgrade checks is published now [4]. As I've been answering some questions in storyboard and IRC, it's obvious that I need to add some FAQs into those docs because I've taken some of this for granted on how it works in nova, so I'll push a docs change for some of that as well and link it back into the story. As always, feel free to reach out to me with any questions or issues you might have with completing this goal (or just getting started). [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134972.html [2] https://review.openstack.org/#/c/603465/ [3] https://review.openstack.org/#/c/604430/ [4] https://docs.openstack.org/nova/latest/reference/upgrade-checks.html __ 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
