| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-09-07 | |||
| 16:33:05 | gibi | force still runs the scheduler isn't it? | |
| 16:33:05 | bauzas | wait, was distracted, sorry | |
| 16:33:22 | bauzas | gibi: that depends on the microversion you ask | |
| 16:33:25 | gibi | true | |
| 16:33:38 | gibi | with old enough microversion you can skip the scheduler | |
| 16:33:42 | bauzas | mloza: which exact command do you run ? | |
| 16:33:43 | dansmith | I was going to say, I thought there was a way.. I mean that's how you break your AZ right? :) | |
| 16:34:23 | gibi | host=<new-host> force=True microversion <= 2.67 | |
| 16:34:32 | mloza | openstack server migrate --os-compute-api-version 2.30 --live-migration $id | |
| 16:34:49 | bauzas | with no target ? | |
| 16:34:59 | mloza | yep with no taret | |
| 16:35:02 | mloza | target* | |
| 16:35:04 | bauzas | if so, this goes to the scheduler | |
| 16:35:04 | gibi | you need < 2.30 and you nee d target | |
| 16:35:13 | bauzas | which checks this indeed | |
| 16:35:17 | gibi | https://docs.openstack.org/api-ref/compute/?expanded=live-migrate-server-os-migratelive-action-detail#live-migrate-server-os-migratelive-action | |
| 16:35:30 | dansmith | the scheduler is doing what you asked, in that case.. not sending the host to the aggregate that requires specific specs | |
| 16:35:35 | sean-k-mooney | mloza: if you dont pass a target then it will use the az form the request spec | |
| 16:35:37 | bauzas | gibi: or you can use 2.30 with the explicit force flag | |
| 16:35:52 | gibi | bauzas: yes, or <=2.67 and force=True | |
| 16:35:54 | bauzas | (which was deprecated later) | |
| 16:35:59 | bauzas | that, yes | |
| 16:36:35 | bauzas | I'd say, the contract is granted. | |
| 16:36:47 | bauzas | you're asking to migrate something you shouldn't migrate | |
| 16:37:02 | bauzas | I know this is weird | |
| 16:37:34 | sean-k-mooney | if you for the migration will that bypas the aggreate extra spec affintiy filter | |
| 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 | |