Open Stack

On Oct 14, 2013, at 3:38 AM, Joshua Hesketh <joshua.hesketh at rackspace.com> wrote:

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

Our plan for this has been to make the migration idempotent so it doesn't matter if the migration is run again. So yes, migrations that we plan to backport have to be carefully constructed.

Vish

> 
> 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.
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev