| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-11-03 | |||
| 17:20:36 | sean-k-mooney | proably but i tought we benchmarked it with tunnels at one point | |
| 17:20:49 | sean-k-mooney | i think your are right that the nova side will work | |
| 17:21:12 | sean-k-mooney | what then need to be carful of is not assuming the tunnel bandwith is independnet of the physnet bandwith | |
| 17:21:30 | sean-k-mooney | it can be | |
| 17:22:03 | sean-k-mooney | but it would be the less common deployment model | |
| 17:23:43 | gibi | yeah, if the tunelled networks using the same phyiscal interface than a physnet uses then the currently proposed model doesn't work as the physnet and the tunelled bandwidth then cannot be represented separately | |
| 17:25:10 | sean-k-mooney | well that is what ooo should be doing today (sharing one interface for tunneled and notn tunneled traffic) by default | |
| 17:28:59 | opendevreview | Dan Smith proposed openstack/nova master: Test ceph-multistore with a real image https://review.opendev.org/c/openstack/nova/+/860864 | |
| 17:33:56 | gibi | sean-k-mooney: OK, I see you highlighted that in a comment. cool. the current proposal only works if the tunelled traffic has its own dedicated interface | |
| 17:38:44 | sean-k-mooney | that wont work for ovs-dpdk or hardware offloads really | |
| 17:39:07 | sean-k-mooney | you can confirue it so that they could use a dedicated interface but not without more work and cost | |
| 17:39:32 | sean-k-mooney | im actully not sure about hardwar offloaded ovs | |
| 17:40:19 | gibi | if they share interface then the deployer should statically split bw inventory between the RPs representing the physnet and the tunnel | |
| 17:41:36 | gibi | sean-k-mooney: could there be more than one interface for the tunneled traffic ? | |
| 17:43:38 | opendevreview | Alex Chan proposed openstack/nova master: record action log when deleting shelved instance Closes-Bug: #1993736 Change-Id: I9ce18cbba5083c55d15d9b7c2a89133d227754ea https://review.opendev.org/c/openstack/nova/+/863547 | |
| 17:46:03 | sean-k-mooney | gibi: there is only one local tunnel ip | |
| 17:46:23 | sean-k-mooney | gibi: so yes but its defiend by the routing table which interface is used | |
| 17:46:36 | sean-k-mooney | there are two way to do this | |
| 17:47:05 | sean-k-mooney | either you have a singel intterface (can be a bond or bridge) that has the tunnel local ip | |
| 17:47:19 | sean-k-mooney | and you confiure the route to all remote host via that | |
| 17:47:34 | sean-k-mooney | the simples way is to use a single subnet for all compute/network nodes | |
| 17:47:52 | sean-k-mooney | or you can deviced your tunneld network in to multipel l3 subnets | |
| 17:48:05 | sean-k-mooney | in which case if you have a multi homed server the multipel interface can be used | |
| 17:48:37 | sean-k-mooney | i dont see a go way to suppor the multi homed case simply | |
| 17:49:48 | sean-k-mooney | how the tx path works is ovs pushes a vxlan/geneve header on the packet and looks at a cache of the host routing tabel to 1 determin the source interface to use to reach the destination tunnel endpoint | |
| 17:50:44 | sean-k-mooney | if the source interafeace is an ovs bridge it just uses the normal action to transmit the tunneld packet onto the physical netowrk via normal mac larning | |
| 17:51:23 | sean-k-mooney | if the tunnel local ip is not assocated with an ovs brige it passes the encpsulated packet to the host kernel netowrk stack and it routes it | |
| 17:52:01 | sean-k-mooney | passing it to the host kernel routign stack is best avoided becasue its slower and hard to do qos for if there are potitally mulitiple paths | |
| 18:03:33 | opendevreview | Alexey Stupnikov proposed openstack/nova master: Add functional tests to reproduce bug #1994983 https://review.opendev.org/c/openstack/nova/+/863416 | |
| 18:06:17 | opendevreview | Alexey Stupnikov proposed openstack/nova master: Add functional tests to reproduce bug #1994983 https://review.opendev.org/c/openstack/nova/+/863416 | |
| 18:10:27 | sean-k-mooney | gibi: i linked to this converation in the spec ill try and find time to follow up with rodolfo next week some time | |
| 18:10:45 | gibi | cool, thanks | |
| 18:19:16 | opendevreview | Alex Chan proposed openstack/nova master: record action log when deleting shelved instance https://review.opendev.org/c/openstack/nova/+/862404 | |
| 19:30:52 | dansmith | remember when I volunteered to do the stable compute uuid thing at ptg? | |
| 19:30:58 | dansmith | why TF didn't anyone slap me? | |
| 20:19:48 | darkhorse | dansmith: I added the assert as you suggested. https://review.opendev.org/c/openstack/nova/+/862404 | |
| 20:20:08 | dansmith | darkhorse: yeah, just to the first one.. is the second one just as easy? | |
| 20:20:14 | dansmith | I was also waiting to see tests pass | |
| 20:22:09 | darkhorse | excuse me I did not know there was second one. it should be as easy. let me check and add assert to second too. | |
| 20:23:43 | dansmith | darkhorse: I said "same below" in my comment, but I should have been more explicit | |
| 20:24:17 | dansmith | darkhorse: https://review.opendev.org/c/openstack/nova/+/862404/4/nova/tests/unit/compute/test_api.py#7914 | |
| 20:24:22 | dansmith | that ^ one | |
| 20:25:29 | darkhorse | dansmith: thank you for clarification. | |
| 20:47:23 | opendevreview | Alex Chan proposed openstack/nova master: record action log when deleting shelved instance https://review.opendev.org/c/openstack/nova/+/862404 | |
| 20:56:39 | dansmith | darkhorse: it's on its way | |
| 23:57:05 | opendevreview | Merged openstack/nova master: record action log when deleting shelved instance https://review.opendev.org/c/openstack/nova/+/862404 | |
| #openstack-nova - 2022-11-04 | |||
| 00:46:58 | darkhorse | dansmith: thank you very much! | |
| 11:55:24 | elodilles | bauzas sean-k-mooney : if you are around: the final wallaby release patch has merged, so a formal +1 would be good for the transition patch: https://review.opendev.org/c/openstack/releases/+/862298 | |
| 12:52:07 | sean-k-mooney | this si EM os-vif too | |
| 12:52:32 | sean-k-mooney | elodilles: i think we need a release of os-vif to get the correct upperconstrati | |
| 12:52:54 | sean-k-mooney | i was going to do a release of that this week for that reason | |
| 12:53:39 | sean-k-mooney | elodilles: ya we still need to do that for wallaby we noticed it downstream last week | |
| 12:53:46 | sean-k-mooney | https://github.com/openstack/os-vif/blob/2.4.0/tox.ini#L12 | |
| 12:54:05 | sean-k-mooney | let me do a 2.4.1 release quickly then we can tansiation it to EM | |
| 12:56:39 | elodilles | sean-k-mooney: i heard that RH uses the releases a bit differently (i guess building the packages from based on tags) but most users tend to consume the released pypi packages and tarballs, and upper-constraints are not compiled in those packages | |
| 12:57:16 | sean-k-mooney | we actully dont use the tox env in general but it confused some | |
| 12:57:34 | elodilles | sean-k-mooney: so that's why it should not be released, because it would contain the very same content as the previous relese, and would just confuse operators | |
| 12:57:38 | sean-k-mooney | rdo only packages the released rpm in general | |
| 12:57:59 | sean-k-mooney | well are you saying we dont include tox.ini in the package | |
| 12:58:11 | sean-k-mooney | i woudl have expected that to be in the tar | |
| 12:58:14 | sean-k-mooney | so you can run the tests | |
| 12:58:30 | sean-k-mooney | if its not then we dont need to do anything | |
| 12:58:46 | sean-k-mooney | i guess i can check | |
| 12:59:22 | elodilles | in pypi packages i'm sure we don't have it | |
| 12:59:55 | elodilles | besides, the code would be the very same either way | |
| 13:00:05 | sean-k-mooney | its in the tar | |
| 13:00:07 | sean-k-mooney | https://tarballs.opendev.org/openstack/os-vif/os_vif-2.4.0.tar.gz | |
| 13:00:20 | sean-k-mooney | and the tar is the primary release artifact | |
| 13:00:35 | sean-k-mooney | the tar is what the rpm and deb packages are built form | |
| 13:01:23 | sean-k-mooney | elodilles: you are correct that its not in the wheel | |
| 13:02:20 | sean-k-mooney | elodilles: so its in the tar published to pypi but not the whl | |
| 13:02:39 | sean-k-mooney | https://files.pythonhosted.org/packages/14/2a/dc1cac486333a725c3835b9e8d33ec4ab3bb0ed3e0f49d6354548c8cde1f/os_vif-2.4.0.tar.gz | |
| 13:03:11 | sean-k-mooney | elodilles: so i think we should like fix this unless you strongly disagree | |
| 13:05:41 | elodilles | sean-k-mooney: i'd rather not release this, but maybe it's just me :/ | |
| 13:10:09 | elodilles | sean-k-mooney: anyway, please propose the patch if you think it should be released, i'll comment on it, and let's see others opinion about it | |
| 13:11:00 | sean-k-mooney | https://review.opendev.org/c/openstack/releases/+/863644 | |
| 13:11:22 | sean-k-mooney | i had the patch ready locally i ment to do it last week | |
| 13:11:58 | sean-k-mooney | lets see what bauzas thinks | |
| 13:12:08 | sean-k-mooney | other then that im fine with movign things to em now | |
| 13:23:12 | sean-k-mooney | elodilles: i set +1 on the em transition patch so if others dont think we need the os-vif release you can just proceed with merging the em patch | |
| 13:26:16 | elodilles | sean-k-mooney: ack, thanks! | |
| 13:27:17 | sean-k-mooney | elodilles: part of why i at least wanted to push the patch is i told peole i would do it downstream in a ci escalation bug | |
| 13:27:55 | sean-k-mooney | this was not actully the cause of the downstream issue https://bugzilla.redhat.com/show_bug.cgi?id=2109536 | |
| 13:27:55 | elodilles | i see | |
| 13:28:04 | sean-k-mooney | stestr was just not installed in the correct location | |
| 13:30:34 | elodilles | i'll ask about this release on the weekly relmgmt meeting, which will start soon (14:00 UTC) | |
| 13:31:06 | sean-k-mooney | sure | |
| 15:23:09 | elodilles | sean-k-mooney: fyi, there were no strong objection about the os-vif release, so it is +2+W'd (and even released already) | |
| 15:23:27 | elodilles | i'll update the wallaby-em patch in a minute | |
| 15:23:33 | sean-k-mooney | ack i saw the email come in | |
| 15:23:40 | sean-k-mooney | cool | |
| 15:23:48 | sean-k-mooney | ill set +1 on it when done | |
| 15:27:21 | elodilles | sean-k-mooney: https://review.opendev.org/c/openstack/releases/+/862298 | |
| 15:34:55 | opendevreview | Jean-Sébastien Bevilacqua proposed openstack/nova master: Add Lustre support to nova https://review.opendev.org/c/openstack/nova/+/853786 | |
| 15:38:13 | opendevreview | Alexey Stupnikov proposed openstack/nova master: Don't ignore InstanceNotFound exception by libvirt https://review.opendev.org/c/openstack/nova/+/863665 | |
| 18:45:10 | atmark | hello, is it posible to set `resume_guests_state_on_host_boot=true` in nova and then `virsh autostart $domainname --disable` a selected VMs that I don't want to start | |
| 18:45:23 | atmark | will two conflict with each other? | |
| 18:47:13 | dansmith | pretty sure they're unrelated and so the nova one will win, | |
| 18:47:17 | dansmith | but let me see if I can find it | |
| 18:51:05 | dansmith | atmark: by my reading, if the nova tunable is enabled, this is the only logic that might cause us not to take hard_reboot() action on the guest: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L4150-L4172 | |