| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-09-07 | |||
| 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 | |
| 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 | |
| 09:16:22 | lyarwood | alexe9191: oh sorry you're going from K to N, same applies | |
| 09:16:42 | lyarwood | alexe9191: but from N to T you should be fine given what TripleO has already tested | |
| 09:17:03 | lyarwood | alexe9191: I can point you to the code that handles this in TripleO if you want an idea of what it's actually doing | |
| 09:19:21 | lyarwood | alexe9191: for N to Q - https://github.com/openstack/tripleo-heat-templates/blob/0f47a4de9b5e64023ddc594d6106fff2c053bcfb/docker/services/nova-api.yaml#L365-L469 - that's with the computes stopped, for queens it then does a normal deployment that is defined above these tasks | |
| 09:20:31 | lyarwood | alexe9191: it's not a seperate set of tasks for Q to T but it's the same pattern, the same commands as a N to N+1 upgrade with the computes down | |
| 09:20:32 | alexe9191 | Thank you all! This is useful information | |
| 09:21:44 | lyarwood | alexe9191: np, good luck :) | |
| 09:22:55 | alexe9191 | One more question just to be sure :) which version do I need to create the cell database for when upgrading ? I understand that from mitaka I need to create an API database. It seems that only in newton I need to start creating the cell0 database and map it using the nova manage commands | |
| 09:22:57 | alexe9191 | correct? | |
| 09:34:31 | opendevreview | Merged openstack/python-novaclient stable/wallaby: When creating a client, pass the default logger https://review.opendev.org/c/openstack/python-novaclient/+/804440 | |
| 09:35:44 | lyarwood | alexe9191: I think TripleO did that during the Ocata upgrade | |
| 09:37:01 | alexe9191 | Ok so it's way more ahead than I though :) I am testing now | |
| 09:37:03 | alexe9191 | thank you all | |
| 09:37:36 | lyarwood | alexe9191: https://docs.openstack.org/releasenotes/nova/ocata.html#relnotes-15-0-0-origin-stable-ocata-prelude | |
| 09:37:52 | lyarwood | be confused with the first version of cells). In Newton, it was possible to deploy a single cell V2 and schedule on it but this was optional. Now in Ocata, single CellsV2 deployments are mandatory. More details to be found when reading the release notes below.` | |
| 09:37:52 | lyarwood | `Ocata contains a lot of new CellsV2 functions, but not all of it is fully ready for production. All deployments must set up their existing nodes as a cell, with database connection and MQ transport_url config items matching that cell. In a subsequent release, additional cells will be fully supported, as will a migration path for CellsV1 users. By default, an Ocata deployment now needs to configure at least one new “Cell V2” (not to | |
| 09:38:49 | slaweq | stephenfin: hi, I'm not sure if You have +2 powers on nova's stable branches, but if so, can You maybe check https://review.opendev.org/c/openstack/nova/+/791421 ? | |
| 09:38:53 | slaweq | thx in advance | |
| 09:41:02 | lyarwood | he doesn't but I do, looking now | |
| 10:04:17 | slaweq | lyarwood: thx a lot | |
| 11:51:13 | opendevreview | Lee Yarwood proposed openstack/nova stable/ussuri: Add regression test for bug #1899649 https://review.opendev.org/c/openstack/nova/+/764625 | |
| 11:51:21 | opendevreview | Lee Yarwood proposed openstack/nova stable/ussuri: compute: Don't detach volumes when RescheduledException raised without retry https://review.opendev.org/c/openstack/nova/+/764626 | |
| 12:00:46 | opendevreview | Balazs Gibizer proposed openstack/nova stable/wallaby: Parse alias from domain hostdev https://review.opendev.org/c/openstack/nova/+/807767 | |
| 13:36:02 | opendevreview | Elod Illes proposed openstack/nova stable/ussuri: Allow X-OpenStack-Nova-API-Version header in CORS https://review.opendev.org/c/openstack/nova/+/796862 | |
| 13:39:32 | opendevreview | Elod Illes proposed openstack/nova stable/train: Allow X-OpenStack-Nova-API-Version header in CORS https://review.opendev.org/c/openstack/nova/+/796863 | |
| 17:28:30 | fungi | sean-k-mooney: any idea what the wait is on https://review.opendev.org/806626 (victoria backport for the second ossa-2021-002 fix)? i'm in a holding pattern on publishing errata for the advisory until both that one and the ussuri backport merge | |
| 17:29:04 | fungi | just making sure it's not slipped through the cracks | |
| 17:30:55 | sean-k-mooney | i need to readd the conflcit lines | |
| 17:31:07 | sean-k-mooney | but i have been swapped with downstream issues | |
| 17:31:29 | sean-k-mooney | so i have not had time to work on it | |