| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-09-07 | |||
| 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 | `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: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: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 | |
| 17:32:30 | fungi | no worries, take your time, i simply didn't want an exploitable vulnerability hanging out there any longer than necessary | |
| 17:32:42 | sean-k-mooney | ya fair | |
| 17:32:53 | sean-k-mooney | ill see if i can get to it but that all that is holding it up | |
| 17:33:07 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/806626/1//COMMIT_MSG#16 | |
| 17:33:09 | fungi | okay, cool. thanks again | |
| 19:03:37 | opendevreview | Elod Illes proposed openstack/nova stable/victoria: address open redirect with 3 forward slashes https://review.opendev.org/c/openstack/nova/+/806626 | |
| 19:06:49 | elodilles | sean-k-mooney: i've updated the commit message ^^^ please edit it if it is needed o:) | |
| 20:45:08 | mnaser | anyone by any chance the historical reasoning of instance_id_mappings table? | |
| 20:46:05 | mnaser | wait, they don't even match up | |
| 20:46:24 | mnaser | i mean, uuid = uuid, but id != id | |
| 21:38:22 | melwitt | mnaser: found this with git blame https://github.com/openstack/nova/commit/0dc32690fe158e4cb11c2c9bcc65acaf73b94a7a | |
| 21:39:11 | mnaser | melwitt: oooooooooh nice find | |
| 21:39:42 | melwitt | :) | |
| #openstack-nova - 2021-09-09 | |||
| 07:12:29 | gibi | good morning | |
| 07:56:48 | bauzas | gibi: good morning | |
| 07:57:12 | bauzas | was mostly off the grid yesterday due to a hell day with customer escalations | |
| 08:01:28 | gibi | not much happened upstream yestrday here either | |
| 08:10:30 | bauzas | gibi: in case you haven't seen it, i eventually found the problem with my prelude change | |
| 08:10:52 | bauzas | one single line was badly indented by one char | |
| 08:11:03 | bauzas | but not the one which was returning the error | |
| 08:11:08 | bauzas | ... | |
| 08:13:08 | gibi | yepp, I +2d the prelude yestearday. thank you for writing it | |
| 08:19:41 | kashyap | bauzas: Then how did you discover it? If it's not the line that caused the error :-) | |
| 08:20:10 | bauzas | kashyap: I still use my eyes in general | |
| 08:20:20 | kashyap | Hehe | |
| 08:20:29 | bauzas | automated coding isn't an option yet, I'm afraid | |
| 08:20:34 | bauzas | I should ask elon to propose it | |
| 08:23:27 | kashyap | bauzas: GitHUb has some ideas with their <clears-throat> "Copilot" | |