| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-12-14 | |||
| 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 | |
| 16:11:39 | gibi | I just wanted to limit the number of bugs to track | |
| 16:12:05 | gibi | I would keep https://bugs.launchpad.net/nova/+bug/1907522 open until https://review.opendev.org/c/openstack/nova/+/766925 is merged | |
| 16:12:05 | openstack | Launchpad bug 1907522 in OpenStack Compute (nova) "test_*_with_qos_min_bw_allocation fails in the nova-multi-cell job with: nova.exception.MigrationPreCheckError: Migration pre-check error: Failed to create port bindings for host <host>" [High,In progress] - Assigned to Balazs Gibizer (balazs-gibizer) | |
| 16:12:13 | melwitt | yeah, I see now. without context of the other approach in the bug, it didn't make sense to me | |
| 16:12:34 | gibi | melwitt: I can add more context to the bug I closed | |
| 16:13:20 | melwitt | I am ok, just explaining why I asked. but it might help to add that info for reading back in history | |
| 16:13:30 | melwitt | I will abandon my patch | |
| 16:13:57 | gibi | sure | |
| 16:14:00 | gibi | I will add it | |
| 16:14:39 | melwitt | cool thanks | |
| 16:16:04 | gibi | done | |
| 16:26:32 | prometheanfire | melwitt: how goes the mock updates? :P | |
| 16:27:14 | melwitt | prometheanfire: will start on it maybe today, last week our gate was failing 100% so was focused on things related to that | |
| 16:27:47 | prometheanfire | yep | |
| 16:28:40 | prometheanfire | offhand, is it possible to switch a flavor from public to private via the API? I'm thinking no | |
| 16:32:46 | melwitt | prometheanfire: looks like no, can't switch flavor from public to private via the API | |
| 16:33:36 | gmann | prometheanfire: melwitt: yeah, only modification allowed in flavor is description or add/remove tenant access. | |
| 16:34:17 | gmann | gibi: melwitt lyarwood looks like placement l-c is also broken. https://review.opendev.org/c/openstack/placement/+/764394 | |