How to change nova db in Train ?
Buddies, I have a question about updating nova db. I would like to change the length of internal_access_path in console_auth_tokens, starting from Train. I want to modify nova/db/sqlalchemy/models.py and the migration file under nova/db/sqlalchemy/migrate_repo/versions. However I did not find a placeholder file for Train. 402_add_resources.py is the last one in Train and 403_ is "Add reserved schema migrations for Ussuri". So how can I do it in Train ? Yingji.
On Fri, Oct 16, 2020 at 08:31, Yingji Sun <yingjisun@vmware.com> wrote:
Buddies,
I have a question about updating nova db.
I would like to change the length of internal_access_path in console_auth_tokens, starting from Train. I want to modify nova/db/sqlalchemy/models.py and the migration file under nova/db/sqlalchemy/migrate_repo/versions. However I did not find a placeholder file for Train. 402_add_resources.py is the last one in Train and 403_ is "Add reserved schema migrations for Ussuri".
So how can I do it in Train ?
I think technically you can use 403 for your Train backport as there was no newer migration ever merged. But I hope others more experience with DB migration backporting in Nova can confirm this. Cheers, gibi
Yingji.
I think technically you can use 403 for your Train backport as there was no newer migration ever merged. But I hope others more experience with DB migration backporting in Nova can confirm this.
Yes, 403 is a placeholder for backports *from* Ussuri, to Train. However, I don't think the stated change is a reasonable candidate for a schema backport. They really should only be used for critical regressions that can't be fixed any other way. Since the length of that column hasn't changed lately, I wouldn't call it a regression, and definitely not critical. Going forward we can expand the size in master, if need-be, but I would not support backporting that change. --Dan
Dan, I am OK not backporting this change to previous branch as there is no such issue reported by other customers. It is a VIO user that reported this one. I can fix it in upstream master and backport it only downstream. I would use 403_placeholder.py in "downstream train" and when the customer upgrades from "downstream stein" to "downstream train", he can get the altered column. Do you think this is feasible ? Yingji > 在 2020/10/19 下午10:35，“Dan Smith”<dms@danplanet.com> 写入:
I think technically you can use 403 for your Train backport as there was no newer migration ever merged. But I hope others more experience with DB migration backporting in Nova can confirm this.
Yes, 403 is a placeholder for backports *from* Ussuri, to Train. However, I don't think the stated change is a reasonable candidate for a schema backport. They really should only be used for critical regressions that can't be fixed any other way. Since the length of that column hasn't changed lately, I wouldn't call it a regression, and definitely not critical. Going forward we can expand the size in master, if need-be, but I would not support backporting that change.
--Dan
I can fix it in upstream master and backport it only downstream. I would use 403_placeholder.py in "downstream train" and when the customer upgrades from "downstream stein" to "downstream train", he can get the altered column. Do you think this is feasible ?
Yes, if you make the master migration idempotent (which it should be anyway), then you can effectively just copy it to 403_placeholder.py (replacing the name with something useful) and they will get it when they upgrade, assuming they haven't rolled over 403 yet. When they get to what is now master, the idempotent master equivalent should result in a no-op. --Dan
participants (3)
-
Balázs Gibizer
-
Dan Smith
-
Yingji Sun