Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-09-07
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 bauzas we have the embedded flavor stored in two places
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: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 sean-k-mooney well k8 swould suport this too alto0ugh it would delete it and recreate it
17:04:00 bauzas resize --live ?
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 dansmith that wouldn't do what the person wanted though
17:11:23 sean-k-mooney *not
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
17:13:42 sean-k-mooney im pretty sure we regressed this at some point
17:13:56 sean-k-mooney but ya that is also a thing right now
17:16:42 sean-k-mooney although im slight confusted why this set of tempest test is passign https://review.opendev.org/c/openstack/whitebox-tempest-plugin/+/806239/6/whitebox_tempest_plugin/api/compute/test_vpmu.py
17:19:12 artom sean-k-mooney, maybe we update the request spec when we confirm the resize?
17:19:23 sean-k-mooney oh ya that could be it
17:19:40 sean-k-mooney so we need that refactoring i suggested where we can assert thing during resize verify
17:20:04 artom Aye
17:20:12 sean-k-mooney that would also explain why we have not notcied this if it update on confirm
17:20:47 sean-k-mooney the window to observe it would be only during the migration
17:21:50 artom And if it causes problems during scheduling...
17:55:02 opendevreview Sylvain Bauza proposed openstack/nova master: Add the Xena prelude section https://review.opendev.org/c/openstack/nova/+/807786
18:05:51 opendevreview Merged openstack/nova master: Parse alias from domain hostdev https://review.opendev.org/c/openstack/nova/+/806943
#openstack-nova - 2021-09-08
07:54:38 alexe9191 Good day everyone :)
07:55:28 alexe9191 I am planning on doing a nova upgrade from kilo to newton ( and then will upgrade up to train ) but I was wondering If I need to do a nova-compute start on all compute nodes between each version from kilo to newton?
07:56:05 alexe9191 do I need to do an upgrade to liberty, start the compute node services, turn them off again, and continue to mitaka and so on?
08:03:12 bauzas alexe9191: good mornign
08:03:22 bauzas alexe9191: you'd be more than happy to read https://docs.openstack.org/nova/latest/admin/upgrades.html

Earlier   Later