| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-12-14 | |||
| 13:16:41 | sean-k-mooney | but given how long ago it was added its unlikely you have not run any db migration since pike | |
| 13:16:57 | ygk_12345 | sean-k-mooney is this the one "su -s /bin/sh -c "nova-manage db sync" nova" ? | |
| 13:18:14 | sean-k-mooney | ygk_12345: more or less yes although it proably not the issue | |
| 13:18:23 | ygk_12345 | sean-k-mooney now I got this after the command http://paste.openstack.org/raw/801005/ | |
| 13:18:43 | openstackgerrit | Mamduh proposed openstack/os-vif stable/stein: Refactor code of linux_net to more cleaner and increase performace https://review.opendev.org/c/openstack/os-vif/+/765914 | |
| 13:19:53 | sean-k-mooney | so this is train | |
| 13:20:11 | sean-k-mooney | was the cloud initall deploy as train or upgraded form a previous release | |
| 13:20:11 | ygk_12345 | sean-k-mooney yes | |
| 13:20:21 | ygk_12345 | intially as train only | |
| 13:22:10 | sean-k-mooney | so that failing here https://github.com/openstack/nova/blob/0e7cd9d1a95a30455e3c91916ece590454235e0e/nova/db/sqlalchemy/migrate_repo/versions/316_add_disk_ratio_for_compute_nodes.py | |
| 13:22:59 | ygk_12345 | sean-k-mooney yes exactly | |
| 13:23:32 | sean-k-mooney | so if the migration is failing there which is mitaka then ist possbale that the rest fo the migration have not been run either | |
| 13:23:45 | sean-k-mooney | the service uuid was added in a later migration | |
| 13:24:29 | sean-k-mooney | lyarwood: gibi do you know if we ahve a way to print the crrent db version via nova manage | |
| 13:24:51 | ygk_12345 | sean-k-mooney so what would be the workaround now ? | |
| 13:24:52 | sean-k-mooney | stephenfin: maybe you know ^ | |
| 13:25:16 | sean-k-mooney | ygk_12345: well we need to figure out what version your db actull is | |
| 13:25:35 | sean-k-mooney | it sound like your deployment didnt actully work properly | |
| 13:25:40 | ygk_12345 | sean-k-mooney i am following the train minimal nova installation guide | |
| 13:25:50 | ygk_12345 | sean-k-mooney oh ok | |
| 13:26:35 | ygk_12345 | sean-k-mooney i used this on ubuntu18 add-apt-repository cloud-archive:train | |
| 13:27:22 | sean-k-mooney | the install gudies are not really tested at least not by the project teams | |
| 13:27:25 | lyarwood | sean-k-mooney: yeah isn't there a version subcommand or something? | |
| 13:27:55 | lyarwood | https://docs.openstack.org/nova/latest/cli/nova-manage.html#nova-database - nova-manage db version | |
| 13:28:37 | ygk_12345 | sean-k-mooney its version 315 | |
| 13:28:56 | ygk_12345 | lyarwood sean-k-mooney its db version 315 | |
| 13:28:56 | sean-k-mooney | ygk_12345: ya so that pre mitaka | |
| 13:29:05 | openstackgerrit | Mamduh proposed openstack/os-vif stable/rocky: Refactor code of linux_net to more cleaner and increase performace https://review.opendev.org/c/openstack/os-vif/+/765962 | |
| 13:29:35 | ygk_12345 | sean-k-mooney so what would be the workaroud now ? | |
| 13:29:35 | sean-k-mooney | ygk_12345: so at that point you should not have the disk_allocation_ratio column in that table | |
| 13:30:12 | sean-k-mooney | i think what has happened here is that since you started the services before the db was synced | |
| 13:30:38 | sean-k-mooney | the conductor or one of the other service created teh db column | |
| 13:31:05 | ygk_12345 | sean-k-mooney shall I remove the db and nova pkgs and try again ? | |
| 13:31:21 | sean-k-mooney | you could do that yes if you have not workloads on it | |
| 13:31:38 | ygk_12345 | sean-k-mooney just a test platform. no workloads | |
| 13:31:52 | sean-k-mooney | you dont really need to uninstall the service just stop them | |
| 13:32:00 | sean-k-mooney | then drop the db and recreate it | |
| 13:32:18 | sean-k-mooney | making sure that the db is fully migrated | |
| 13:33:07 | ygk_12345 | sean-k-mooney ok. sounds fine. will do that now | |
| 13:34:31 | sean-k-mooney | you were following https://docs.openstack.org/nova/train/install/controller-install-ubuntu.html#install-and-configure-components | |
| 13:35:29 | ygk_12345 | sean-k-mooney exactly. you spotted it :) | |
| 13:35:30 | sean-k-mooney | that has you restart the services at the end https://docs.openstack.org/nova/train/install/controller-install-ubuntu.html#finalize-installation implying they are running before you populate the db | |
| 13:35:35 | sean-k-mooney | i think that is wrong | |
| 13:35:44 | sean-k-mooney | really it should have you install nova-manage only | |
| 13:35:50 | sean-k-mooney | then populate the db | |
| 13:36:03 | sean-k-mooney | then install the contoler services after | |
| 13:36:19 | sean-k-mooney | i think that is what caused your issue | |
| 13:37:01 | openstackgerrit | Mamduh proposed openstack/os-vif stable/queens: Refactor code of linux_net to more cleaner and increase performace https://review.opendev.org/c/openstack/os-vif/+/765941 | |
| 13:37:08 | ygk_12345 | sean-k-mooney so i have deleted the dbs and created again | |
| 13:38:47 | ygk_12345 | sean-k-mooney i have created the dbs again now. Whats the next step ? | |
| 13:38:50 | sean-k-mooney | ygk_12345: are all the nova services stopoed | |
| 13:38:56 | sean-k-mooney | *stopped | |
| 13:39:18 | ygk_12345 | sean-k-mooney not on the compute node though. will it affect ? | |
| 13:40:27 | sean-k-mooney | possibly | |
| 13:40:32 | sean-k-mooney | although no it should not | |
| 13:40:43 | sean-k-mooney | the compute node only access the db via the conductor | |
| 13:41:19 | ygk_12345 | sean-k-mooney now shall I populate the dbs ? | |
| 13:42:06 | ygk_12345 | sean-k-mooney also the services are shown to be started in the end after the db stuff in that doc. so whats wrong with that ? | |
| 13:42:07 | sean-k-mooney | yep thats the next step | |
| 13:42:52 | sean-k-mooney | starting them at the end is ok | |
| 13:43:09 | sean-k-mooney | but they should not be started before the db is ready | |
| 13:43:47 | sean-k-mooney | steps 3-6 should be done before any of the serviecs are started | |
| 13:44:24 | ygk_12345 | @se | |
| 13:44:37 | ygk_12345 | sean-k-mooney oh ok got it. it went well this time. lets see further | |
| 13:45:16 | sean-k-mooney | before you start the services check the db version | |
| 13:46:03 | ygk_12345 | oh ok | |
| 13:46:07 | sean-k-mooney | i think it shoudl be 402 | |
| 13:46:26 | sean-k-mooney | https://github.com/openstack/nova/tree/stable/train/nova/db/sqlalchemy/migrate_repo/versions based on the last migration | |
| 13:47:21 | sean-k-mooney | if it gets to 402 then your good to go with starting the services | |
| 13:48:30 | ygk_12345 | yes its 402. awesome | |
| 13:49:36 | sean-k-mooney | feel free to submit a patch to update the install guide with this and any other issue you find | |
| 13:50:26 | sean-k-mooney | as i said in this case it should have had you install just nova-manage then set up the db then install the other nova packages for the api conducort and scheduler | |
| 13:51:11 | sean-k-mooney | ygk_12345: when you install the packages the post init script starts the service automatically which can cause issues as you found | |
| 13:51:25 | ygk_12345 | sean-k-mooney ok sure thanks for your time as well | |
| 13:51:39 | sean-k-mooney | no worries | |
| 14:28:29 | gibi | lyarwood: sorry I was away, but I see you found the reasons | |
| 14:59:14 | sean-k-mooney | gibi: i suspect the conductor proably created the column not really sure what actully did it but yes | |
| 14:59:46 | sean-k-mooney | gibi: i have seen that with devstack often enought to know that running the service before the db is ready end is weired issue like that | |
| 15:00:48 | gibi | sean-k-mooney: oh I referred to the aggregate question from lyarwood | |
| 15:00:59 | sean-k-mooney | oh ok | |
| 15:01:04 | sean-k-mooney | sorry | |
| 15:12:39 | openstackgerrit | Lance Bragstad proposed openstack/placement master: Pass context objects to oslo.policy directly https://review.opendev.org/c/openstack/placement/+/766785 | |
| 15:12:40 | openstackgerrit | Lance Bragstad proposed openstack/placement master: Implement secure RBAC for resource providers https://review.opendev.org/c/openstack/placement/+/760240 | |
| 15:41:53 | openstackgerrit | Jan Gutter proposed openstack/os-vif stable/train: DNM: testing lower-constraints https://review.opendev.org/c/openstack/os-vif/+/766975 | |
| 15:45:08 | openstackgerrit | Lee Yarwood proposed openstack/nova master: Add regression test for bug #1908075 https://review.opendev.org/c/openstack/nova/+/766976 | |
| 15:45:08 | openstack | bug 1908075 in OpenStack Compute (nova) "Nova allows a non-multiattach volume to be attached to multiple instances *if* its volume state is reset by an admin" [Undecided,New] https://launchpad.net/bugs/1908075 - Assigned to Lee Yarwood (lyarwood) | |
| 16:01:20 | gibi | lyarwood: do you happen to know if all the issues we fixed in https://review.opendev.org/c/openstack/nova/+/765749 for stable/victoria needs to be backported to stable/ussuri? if yes I can do the cherry-pick | |
| 16:03:41 | lyarwood | gibi: there are other issues to resolve on the older branches, I've been waiting to see if people wanted to drop the LC jobs | |
| 16:03:54 | gibi | lyarwood: ack, then I | |
| 16:03:55 | lyarwood | gibi: and for the bandit issue to be resolved | |
| 16:04:22 | gibi | then I'm not pushing the backport now, the qos bug is targeted to ussuri | |
| 16:09:27 | melwitt | gibi: wondering why is this considered closed? this one is about the lack of cell targeting for lookup of the service record, not really about the lack of multi-cell support for min bw requests? https://bugs.launchpad.net/nova/+bug/1907511 | |
| 16:09:27 | openstack | Launchpad bug 1907511 in OpenStack Compute (nova) ussuri "nova-multi-cell fails on stable branches with: Failed to compute_task_migrate_server: 'NoneType' object has no attribute 'version'" [Undecided,New] | |
| 16:09:49 | melwitt | *closed for victoria | |
| 16:10:23 | gibi | melwitt: my thinking is to backport his fix to victoria instead https://review.opendev.org/c/openstack/nova/+/766925 | |
| 16:10:47 | gibi | melwitt: | |
| 16:11:12 | gibi | melwitt: I considered https://bugs.launchpad.net/nova/+bug/1907511 as a gate blocker bug which we resolved with turning off the test | |
| 16:11:12 | openstack | Launchpad bug 1907511 in OpenStack Compute (nova) ussuri "nova-multi-cell fails on stable branches with: Failed to compute_task_migrate_server: 'NoneType' object has no attribute 'version'" [Undecided,New] | |
| 16:11:26 | melwitt | oh, I didn't see that | |
| 16:11:26 | gibi | but I can reopen it and close it with https://review.opendev.org/c/openstack/nova/+/766925 if that make more sense | |