Open Stack

On 12/03/14 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.

Like I said, I know it's not always the case. :)

I'll work on a better upgrade path for this.

>
>>>
>>> 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/.  :)
>

Yeah but the failures weren't about glance failing to start because
swift's options were not registered. The failures were about swift
tests failing because it wasn't enabled (IIRC). Same reason, different
issue.

>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.

Fair enough. As mentioned in my previous email, the upgrade process
was discussed but we failed (or at least I failed) at considering this
impact.

>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.

Already working on a way to reduce the impact of this change. We can
revert it and re-submit a patch that handles the upgrade path.

>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.

Yup, I mentioned this in my previous email. I think it's the fairest
approach for now.

[snip]

Flavio

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140312/c47adb95/attachment.pgp>