[openstack-dev] Change I3e080c30: Fix "resource" length in project_user_quotas table for Havana?

Joshua Hesketh joshua.hesketh at rackspace.com
Mon Oct 14 10:38:20 UTC 2013


Rackspace Australia

On 10/12/13 12:35 AM, Russell Bryant wrote:
> On 10/10/2013 11:15 PM, Joshua Hesketh wrote:
>> Hi there,
>>
>> I've been reviewing this change which is currently proposed for master
>> and I think it needs to be considered for the next Havana RC.
>>
>> Change I3e080c30: Fix "resource" length in project_user_quotas table
>> https://review.openstack.org/#/c/47299/
>>
>> I'm new to the process around these kinds of patches but I imagine that
>> we should use one of the placeholder migrations in the havana branch and
>> cherry-pick it back into master?
> The fix looks good, thanks!
>
> I agree that this is good for Havana.  I'll see if I can slip it into
> havana-rc2.
>
> The process is generally merging the fix to master and then backporting
> it.  In this case the backport can't be the same.  Instead of using a
> new migration number, we'll use one of the migration numbers reserved
> for havana backports.
>
So I'm a bit late responding to this but I'm confused about this process 
and was wondering if you could please clarify.

Why wouldn't we use one of the placeholders in master and backport it as 
is to Havana? What happens when an administrator installs Havana and 
then later upgrades to Icehouse? Their migration version number will be 
at 226 having already applied the patch at 217. However in Icehouse the 
patch re-represents itself as 227 and will therefore attempt to apply again*

Now typing this I am seeing this will pose issues for those running 
against trunk who will have already made it to migration 226 before the 
fix is implemented at 217. Still, how do we prevent the above scenario 
from causing problems?

Cheers,
Josh

*granted in this particular case there is no harm in the migration 
applying again but in other migration backports this could be problematic.




More information about the OpenStack-dev mailing list