Open Stack

On Wed, 2014-03-12 at 13:21 -0400, Sean Dague wrote:
> On 03/12/2014 01:10 PM, Jay Pipes wrote:
> > On Wed, 2014-03-12 at 07:18 -0400, Sean Dague wrote:
> >> On 03/12/2014 06:38 AM, Flavio Percoco wrote:
> >>> On 11/03/14 16:25 -0700, Clint Byrum wrote:
> >>>> Hi. I asked in #openstack-glance a few times today but got no response,
> >>>> so sorry for the list spam.
> >>>>
> >>>> https://review.openstack.org/#/c/79710/
> >>>>
> >>>> This change introduces a backward incompatible change to defaults with
> >>>> Havana. If a user has chosen to configure swift, but did not add swift
> >>>> to the known_stores, then when that user upgrades Glance, Glance will
> >>>> fail to start because their swift configuration will be invalid.
> >>>>
> >>>> This broke TripleO btw, which tries hard to use default configurations.
> >>>
> >>> I don't think this change has to be reverted. We could add an upgrade
> >>> path for this. We could enable a driver if its config options were set
> >>> and warn the user about this change. Also, we could make sure we
> >>> import all drivers and the config options are registered but that we
> >>> don't try to enable them.
> >>>
> >>> Also, I don't expect (yeah, I know this is not always the case) users to
> >>> blindly upgrade if they really care about their cloud deployment.
> >>> Since this change will be part of the change log and the release
> >>> notes, I expect the user to be aware of it.
> >>
> >> OpenStack's 2 largest public clouds don't wait for releases, so that's
> >> not really a good answer.
> >>
> >>>>
> >>>> Also I am not really sure why this approach was taken. If a user has
> >>>> explicitly put swift configuration options in their config file, why
> >>>> not just load swift store? Oslo.config will help here in that you can
> >>>> just add all of the config options but not actually expect them to be
> >>>> set. It seems entirely backwards to just fail in this case.
> >>>
> >>> This is exactly the problem. With the current approach, the user has
> >>> not explicitly enabled the swift store. The user just put swift
> >>> configs. With the current 'enable all and let it fail' approach, it is
> >>> really confusing for users to see all the failures and it's not nice to
> >>> enable things by default for the user.
> >>>
> >>> Thanks for raising this issue, I didn't think about this corner
> >>> case.
> >>> Flavio
> >>
> >> In fairness, this wasn't a corner case. Grenade was blocking this change
> >> for the whole cycle until a change was made in stable/havana devstack
> >> that sneaked around it with https://review.openstack.org/#/c/75827/.  :)
> >>
> >> In addition, the commit in question for glance -
> >> https://review.openstack.org/#/c/59150/ didn't have UpgradeImpact, which
> >> is the signaling mechanism for these kinds of issues.
> >>
> >> I do think this is a real issue. OpenStack really is expected to be CD
> >> upgradable, not just post release and post release notes. Commits in
> >> OpenStack need to take that into account.
> >>
> >> A compatibility behavior should be put in place here.
> >>
> >> I do agree the current behavior isn't nice with gorpy error messages all
> >> the time. However, a completely legitimate approach would be:
> >>
> >> If configuration for a storage back end existed, but the driver wasn't
> >> explicitly set, load and configure that driver and throw a big
> >> DEPRECATION WARNING in the logs that Glance will require explicit
> >> loading of drivers in an upcoming release. That would let you move
> >> forward, and provide some user signally.
> > 
> > That's pretty much what already happens. On startup, Glance will log a
> > message about a particular store driver being disabled [1] because
> > configuration settings were not set properly. [2]
> > 
> > IIRC, on startup is the only place these messages occur (not, for
> > instance, every time somebody uploads an image), so I'm not entirely
> > sure what the big deal was.
> > 
> > Long term, moving stores into entrypoints might be a cleaner solution,
> > but you will still need to validate configuration for those endpoints on
> > startup -- all endpoints give you is a cleaner method than "set your new
> > store in the known_stores configuration option".
> 
> The issue is this was a failure going from old defaults to new defaults,
> which is why it was actually blocked by grenade for months.
> 
> The difference is actually we should be working with the drivers that
> were configured, and deprecate the fact that you can get away without
> specifying them.
> 
> Then you can roll forward gracefully, see a warning message on your
> working new config, go handle the situation, and later when the
> backwards compatible behavior is removed you are ok.

I think you may have misunderstood me :) I was saying that I don't
understand what the big deal was about log messages on startup around
failure to configure drivers properly. I didn't think that was something
that needed to be "fixed".

Best,
-jay