Open Stack

Yes, please, let's support commit-to-commit migrations in all of the
projects. Some of us are planning to do continuous deployment instead of
more massive migrations.

Doug

On Wed, Feb 27, 2013 at 9:09 AM, Dolph Mathews <dolph.mathews at gmail.com>wrote:

> This was discussed in #openstack-dev, as I recall.
>
> The goal in these migrations was to support folsom <--> grizzly, not
> necessarily supporting intermediate milestones. I'm not aware of anyone
> doing continuous deployments of keystone, if but if migrating commit to
> commit is the community's expectation, I'm more happy to ensure that
> happens moving forward -- I just wasn't aware that was a concern here.
>
> Thanks for the feedback, and apologies for any inconvenience!
>
>
> -Dolph
>
>
> On Wed, Feb 27, 2013 at 7:43 AM, Mark McLoughlin <markmc at redhat.com>wrote:
>
>> On Wed, 2013-02-27 at 08:09 -0500, Eoghan Glynn wrote:
>> > Folks,
>> >
>> > When looking into an error encountered on a keystone db sync,
>> > I noticed some apparent strangeness in the way keystone schema
>> > migrations have been managed.
>> >
>> > Specifically the *rewriting* of schema migration history, see:
>> >
>> >   https://github.com/openstack/keystone/commit/5bc46d86
>> >
>> > In my (albeit imperfect) understanding of sqlalchemy-migrate, this
>> > reordering seems to defeat the whole purpose of step-wise reversible
>> > migration.
>> >
>> > Would it even be possible to migrate a grizzly-2 deployment to
>> > grizzly-3 with that re-ordering in place?
>> >
>> > Maybe I've missed something here, but I'd appreciate some clarity
>> > on what is considered community best practice in terms of changes
>> > to the migration sequence.
>> >
>> > Previously I would have assumed something like ...
>> >
>> > Invariants we maintain:
>> >
>> >  - DB schemas must always be migrate-able across milestone releases
>>
>> (snip good stuff)
>>
>> It's more than just across milestone releases, we should support
>> upgrading from commit to commit. In Nova, at least, we're trying hard to
>> avoid messing up those who are deploying continuously. I'd expect any
>> nova-core member to reject this patch immediately.
>>
>> What I really don't understand is how this concern wasn't raised in the
>> review at all:
>>
>>   https://review.openstack.org/19780
>>
>> Cheers,
>> Mark.
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130227/36078929/attachment.html>