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
