Open Stack

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