| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-09-07 | |||
| 16:37:42 | sean-k-mooney | i assume that is the one that is blocking the host | |
| 16:37:47 | sean-k-mooney | id did not think it would | |
| 16:37:49 | bauzas | but if all your hosts are within aggregates that set metadata and you have a filter that verifies this, then you explicitly write a contract | |
| 16:38:45 | sean-k-mooney | i guess with force we will just check the host exist and skip everything else with the old microverion? | |
| 16:39:05 | sean-k-mooney | that would leave the vm in a state the future move operation will try to move ti out of the aggreate you moved it into | |
| 16:39:32 | mloza | got it to live migrate after passing a target host | |
| 16:40:01 | gibi | OK, I guess that is solve then | |
| 16:40:03 | gibi | :0 | |
| 16:40:04 | gibi | :) | |
| 16:40:17 | gibi | any other topic for today? | |
| 16:42:10 | gibi | then lets closed this | |
| 16:42:17 | gibi | thanks for joining | |
| 16:42:23 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2021/nova.2021-09-07-16.00.log.html | |
| 16:42:23 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2021/nova.2021-09-07-16.00.txt | |
| 16:42:23 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2021/nova.2021-09-07-16.00.html | |
| 16:42:23 | opendevmeet | Meeting ended Tue Sep 7 16:42:23 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:42:23 | gibi | #endmeeting | |
| 16:42:59 | bauzas | holy shit, I was already knowing about it | |
| 16:44:35 | mloza | Thanks. I think the instance should have extra_specs and prefer live migrating without a target host. If I have to add to extra_specs in the instance, is it instance_extra table that I have to modify ? | |
| 16:45:03 | mloza | instance_uuid='a65b26f5-a278-4200-a573-84e01c685699'; which has "extra_specs": {"aggregate_instance_extra_specs:cephcomputestorage": "true"} | |
| 16:45:12 | mloza | https://paste.opendev.org/raw/bMf35OK3I9aYbCNCv9jm/ | |
| 16:45:59 | gibi | mloza: yepp if you want to hack the db then that is the place | |
| 16:47:04 | sean-k-mooney | well there are 2 palces | |
| 16:47:20 | sean-k-mooney | the instance extra table is what woud be used for generating the vm xml and on the compute node | |
| 16:47:56 | opendevreview | melanie witt proposed openstack/placement master: Narrow scope of set allocations database transaction https://review.opendev.org/c/openstack/placement/+/807014 | |
| 16:48:58 | sean-k-mooney | i woudl hope that is the same falvor we use for move operation inthat are not resize but we do also have flavor info in the request spec which is what is passed to the schduler filters | |
| 16:49:32 | sean-k-mooney | the schduler never uses the info in the instance_extra tabel driectly | |
| 16:51:18 | mloza | where does the scheduler pull info if not from instance_extra table ? | |
| 16:52:01 | sean-k-mooney | i belive we invoke the schduler with a populated request spec object when we do the select destioantion call form the conductor | |
| 16:52:16 | sean-k-mooney | but technially there is a request_sepcs table in the api db | |
| 16:52:23 | sean-k-mooney | with a serialised copy of the requst spec | |
| 16:53:15 | bauzas | sean-k-mooney: this is correct | |
| 16:53:25 | bauzas | but when you resize (eg.) you update the request spec | |
| 16:53:33 | sean-k-mooney | yes | |
| 16:53:37 | bauzas | for the flavor, I mean | |
| 16:53:40 | sean-k-mooney | but what about live migrate and cold migrate | |
| 16:53:48 | sean-k-mooney | do they just use the api db copy | |
| 16:54:03 | sean-k-mooney | or reconstruct it form the embeded flavor in the cell db | |
| 16:54:37 | bauzas | cold and live migrate don't modify the resources, right? | |
| 16:54:48 | bauzas | resize and rebuild do | |
| 16:55:08 | bauzas | so, yes, we just call out the request spec from the api table | |
| 16:55:23 | bauzas | we never lookup the cell db | |
| 16:55:37 | sean-k-mooney | right which has an enbeded copy of the flavor extra specs | |
| 16:55:49 | bauzas | the instance table, you mean? | |
| 16:56:06 | sean-k-mooney | mloza: so you would have to update both the instnace_extra table for the compute node to use and request_specs table for the scuduler to use | |
| 16:56:28 | sean-k-mooney | bauzas: no the request_spec has a full embeded copy of the flavor as a json blob | |
| 16:56:40 | sean-k-mooney | well seriasised nova object | |
| 16:56:42 | bauzas | ah this | |
| 16:56:46 | bauzas | yes | |
| 16:57:03 | sean-k-mooney | so if mloza is changing it to make live migrateion work they need to update the request_sepc version | |
| 16:57:03 | bauzas | we have the embedded flavor stored in two places | |
| 16:57:09 | sean-k-mooney | bauzas: yes | |
| 16:57:16 | bauzas | one in the api db within the request_specs table | |
| 16:57:26 | bauzas | one in the cell db within the instances table | |
| 16:57:40 | bauzas | the instances table is never used for scheduling decisions | |
| 16:57:42 | sean-k-mooney | instance_extra but yes | |
| 16:57:49 | bauzas | my bad, yes indeed | |
| 16:58:08 | mloza | i looked at request_specs in nova api db and indeed, there is extra_specs | |
| 16:58:11 | sean-k-mooney | so mloza you would have to keep both in sync if you do decide to hack the db | |
| 16:59:56 | mloza | noted. thanks for the info | |
| 17:01:04 | mloza | nbeed to figure out the query to modify the json blob in the table extra_specs and request_specs | |
| 17:01:36 | bauzas | use the python objects directly | |
| 17:01:43 | bauzas | simple and quick | |
| 17:02:11 | bauzas | but you need to run the python script somewhere where you have some nova code | |
| 17:02:40 | sean-k-mooney | this come up often | |
| 17:02:47 | bauzas | in the past, we said those instances can be rebuilt | |
| 17:02:54 | sean-k-mooney | not for flavor | |
| 17:03:01 | sean-k-mooney | but ya resized | |
| 17:03:03 | bauzas | or resized | |
| 17:03:07 | sean-k-mooney | but this comes up alot | |
| 17:03:22 | bauzas | and we said we are cloud | |
| 17:03:31 | sean-k-mooney | it is a significant downstream and upstream | |
| 17:03:38 | bauzas | for some reason, people thought we were vmware | |
| 17:03:42 | sean-k-mooney | right and there is a cloud native way to do it | |
| 17:04:00 | bauzas | resize --live ? | |
| 17:04:00 | sean-k-mooney | well k8 swould suport this too alto0ugh it would delete it and recreate it | |
| 17:04:15 | bauzas | you could even use bfv | |
| 17:04:18 | sean-k-mooney | no resize to same flavor updates embeded extra specs | |
| 17:04:34 | sean-k-mooney | we agreeed i should write a spec for that | |
| 17:04:41 | sean-k-mooney | just didnt do it last cycle | |
| 17:04:51 | sean-k-mooney | still a move op with downtime | |
| 17:05:05 | sean-k-mooney | like normal resie just we don tallow resize to same flavor today | |
| 17:05:24 | sean-k-mooney | so you have to duplicate the flavor rather then update it and then update all your exsiting vms | |
| 17:09:43 | dansmith | resize to same flavor might involve a reschedule though right? | |
| 17:09:59 | dansmith | so you'd need to have a "move me if necessary" or "don't move me and abort if I would have to move" option | |
| 17:10:25 | sean-k-mooney | dansmith: yes its a normal resize just removing the requirement to have a different flavor | |
| 17:10:50 | dansmith | right but people wanting this will likely want to violate those assumptions | |
| 17:11:09 | dansmith | the person asking for this wanted to resize to the same flavor, but without moving or even rebooting, so they could then live migrate | |
| 17:11:11 | sean-k-mooney | i think the assumtion would be its alwasy going to change host | |
| 17:11:19 | sean-k-mooney | it might now but proably will | |
| 17:11:23 | sean-k-mooney | *not | |
| 17:11:23 | dansmith | that wouldn't do what the person wanted though | |
| 17:11:36 | dansmith | so I'm just saying, it's sticky :) | |
| 17:11:44 | dansmith | or slippery, or whatever | |
| 17:11:56 | sean-k-mooney | true its the only safe way to do it if we allow you to update anything | |
| 17:12:01 | sean-k-mooney | e.g. numa or cpu pinning | |
| 17:12:59 | sean-k-mooney | by the way we dont correctly update extra spec on resize https://review.opendev.org/c/openstack/nova/+/805882/1/nova/tests/functional/libvirt/test_pci_sriov_servers.py | |
| 17:13:05 | sean-k-mooney | artom is working on that | |
| 17:13:23 | artom | Once I surface from these esclations, but yes | |
| 17:13:27 | sean-k-mooney | https://launchpad.net/bugs/1941005 | |