| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-09-07 | |||
| 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 | |
| 08:09:47 | opendevreview | Federico Ressi proposed openstack/nova master: Check Nova project changes with Tobiko scenario test cases https://review.opendev.org/c/openstack/nova/+/806853 | |
| 08:10:05 | opendevreview | Federico Ressi proposed openstack/nova master: Debug Nova APIs call failures https://review.opendev.org/c/openstack/nova/+/806683 | |
| 08:27:08 | alexe9191 | bauzas: thank you. Do I gather that I can only do an N+1 upgrade? I can not skip mitaka and go from Liberty to newton? | |
| 08:51:47 | bauzas | alexe9191: that's called here in OpenStack "Fast-Forward Upgrades" | |
| 08:52:01 | bauzas | some distributions support it | |
| 08:52:27 | bauzas | eg. https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/post_deployment/upgrade/fast_forward_upgrade.html | |
| 08:55:10 | opendevreview | Elod Illes proposed openstack/os-vif stable/train: [stable-only] Fix lower-constraints https://review.opendev.org/c/openstack/os-vif/+/807839 | |
| 08:56:31 | alexe9191 | buazas: I am not using any distributions and that FFU is probably a wrapper around what nova/openstack services support. :) My question is, does nova support this behaviour or not? | |
| 09:03:52 | bauzas | alexe9191: well...yes, somehow | |
| 09:04:57 | bauzas | given the deployment services provide FFU, nova tries to help them | |
| 09:05:51 | bauzas | alexe9191: see this session https://www.youtube.com/watch?v=YJXem5d6fkI you'll understand the strategy | |
| 09:12:40 | lyarwood | if you can understand the chap mumbling along in the video yeah | |
| 09:13:07 | lyarwood | alexe9191: so there's no official support in Nova for anything other than N to N+1 as that's all we test upstream | |
| 09:13:58 | lyarwood | alexe9191: as you can guess there's a huge matrix of N to N+$x releases we would need to cover to support anything else offically | |
| 09:14:34 | lyarwood | alexe9191: TripleO supports N to Q and Q to T at the moment with T to W being worked on at the moment | |
| 09:15:21 | lyarwood | alexe9191: In all three examples we didn't need the computes to start between the initial release and the final release | |
| 09:15:56 | lyarwood | alexe9191: for L to M I can't think that you would but it's something you would have to test yourself tbh | |