© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
Distinction between options 2 and 3 from my previous comment is next:
3 includes script that can be executed not only by alembic_migration, but by operator as well.
And option 2 migrates as reqular alembic_migration does, so executed unconditionally only during upgrade process.
Another difference in how code would look like.
For the second option I assume it would look similar to [1].
I.e. can't use objects directly from model_v2, and need create similar db models just for current migration.
And for the external script case I hope to have ability to use object from model_v2 directly.
Actually this part is just my assumptions based on what I see in code, so it would be good if someone says it is True or False.
Please note that alembic migration is as a trigger only for initial development stage, and can be replaced as with some other trigger depending on requirements.
As a final trigger solution we could use:
- Manual migration, where operator executes script;
- Automatically on neutron restart, tried to describe it as second option in [2];
- Automatically on neutron upgrade (alembic migration);
I'll try to ping Sean Dague to join discussion.
If we can easily get grenade to run an external upgrade script, that would simplify development and fixing grenade failures.
[1] https:/
[2] https:/