Excerpts from Sean McGinnis's message of 2018-06-05 07:26:27 -0500: > On Mon, Jun 04, 2018 at 06:44:15PM -0500, Matt Riedemann wrote: > > On 6/4/2018 5:13 PM, Sean McGinnis wrote: > > > Yes, exactly what I meant by the NOOP. I'm not sure what Cinder would > > > check here. We don't have to see if placement has been set up or if cell0 > > > has been configured. Maybe once we have the facility in place we would > > > find some things worth checking, but at present I don't know what that > > > would be. > > > > Here is an example from the Cinder Queens upgrade release notes: > > > > "RBD/Ceph backends should adjust max_over_subscription_ratio to take into > > account that the driver is no longer reporting volume’s physical usage but > > it’s provisioned size." > > > > I'm assuming you could check if rbd is configured as a storage backend and > > if so, is max_over_subscription_ratio set? If not, is it fatal? Does the > > operator need to configure it before upgrading to Rocky? Or is it something > > they should consider but don't necessary have to do - if that, there is a > > 'WARNING' status for those types of things. > > > > Things that are good candidates for automating are anything that would stop > > the cinder-volume service from starting, or things that require data > > migrations before you can roll forward. In nova we've had blocking DB schema > > migrations for stuff like this which basically mean "you haven't run the > > online data migrations CLI yet so we're not letting you go any further until > > your homework is done". > > > > Thanks, I suppose we probably could find some things to at least WARN on. > Maybe > that would be useful. > > I suppose as far as a series goal goes, even if each project doesn't come up > with a comprehensive set of checks, this would be a known thing deployers > could > use and potentially build some additional tooling around. This could be a good > win for the overall ease of upgrade story. > > > Like I said, it's not black and white, but chances are good there are things > > that fall into these categories.
In the past when we've had questions about how broadly a goal is going to affect projects, we did a little data collection work up front. Maybe that's the next step for this one? Does someone want to volunteer to go around and talk to some of the project teams that are likely candidates for these sorts of upgrade blockers to start making lists? Doug > > > > -- > > > > 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