Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-10-08
00:51:22 opendevreview melanie witt proposed openstack/nova master: Add legacy limits and usage to placement unified limits https://review.opendev.org/c/openstack/nova/+/713498
00:51:23 opendevreview melanie witt proposed openstack/nova master: Update quota apis with keystone limits and usage https://review.opendev.org/c/openstack/nova/+/713499
00:51:23 opendevreview melanie witt proposed openstack/nova master: Add reno for unified limits https://review.opendev.org/c/openstack/nova/+/715271
00:51:25 opendevreview melanie witt proposed openstack/nova master: WIP Enable unified limits in the nova-next job https://review.opendev.org/c/openstack/nova/+/789963
01:22:27 gmann melwitt: its green now https://review.opendev.org/c/openstack/devstack/+/812092/4
01:22:44 melwitt gmann: \o/
01:25:29 opendevreview Merged openstack/nova master: Reproduce bug 1945310 https://review.opendev.org/c/openstack/nova/+/811394
02:36:42 opendevreview Merged openstack/nova master: Update min supported service version for Yoga https://review.opendev.org/c/openstack/nova/+/809932
03:25:07 opendevreview pengzhang proposed openstack/nova master: the vif_name error leads virsh domifstat cant work https://review.opendev.org/c/openstack/nova/+/813119
05:46:10 opendevreview pengzhang proposed openstack/nova master: the vif_name error leads virsh domifstat cant work https://review.opendev.org/c/openstack/nova/+/813119
07:33:04 opendevreview norman shen proposed openstack/nova master: Recreate mdev devices according to placement https://review.opendev.org/c/openstack/nova/+/810220
08:12:47 bauzas good (late) morning Nova
08:15:16 lyarwood \o
08:17:23 gibi o/
09:16:36 opendevreview Dmitriy Rabotyagov proposed openstack/nova master: Ensure MAC addresses characters are in the same case https://review.opendev.org/c/openstack/nova/+/811947
09:38:11 opendevreview Elod Illes proposed openstack/nova stable/train: Reject open redirection in the console proxy https://review.opendev.org/c/openstack/nova/+/791807
09:38:48 opendevreview Elod Illes proposed openstack/nova stable/train: address open redirect with 3 forward slashes https://review.opendev.org/c/openstack/nova/+/806629
10:20:15 gibi sean-k-mooney: what is the reason of not waiting for network-vif-plugged events during hard reboot? I hard reboot does unplug / plug but does not wait for plugged event. Compared that to boot where we do plug and then wait for plugged event before we let the VM to run
10:20:44 gibi in normal ovs case I see that during hard reboot neutron eventually sends the unplugged and plugged events to us we just not waiting for it
10:24:19 sean-k-mooney you are correct it will in most cases
10:24:39 sean-k-mooney technically linux bridge might miss the removal and not send it
10:24:48 sean-k-mooney for ovn and odl it wont
10:24:54 sean-k-mooney starnard ml2/ovs it will
10:25:15 sean-k-mooney so we dont wait because we need to know which ml2 driver bound the port and the behaivor of that driver
10:25:43 sean-k-mooney gibi: i likely will be looking at reqorkign how we do this in yoga its one of the things i want to talk about at the ptg
10:26:03 sean-k-mooney in train neutron started teilling us what driver bound the port
10:26:10 gibi OK I see, thanks
10:26:15 sean-k-mooney so we can actully no start using that info
10:26:35 sean-k-mooney we just need to add it to our vif objects and use it where it makes sense
10:26:49 sean-k-mooney e.g. wait for event on hard rebot if its ml2/ovs for example
10:26:57 sean-k-mooney but not if its odl
10:26:59 gibi I see
10:28:05 sean-k-mooney gibi: the short answer why we dont wait is we dont rebind the ports on hard reboot so we only get event for backend that send plug time event and since beforfe train we could not tell if ovs port were plug time or bind time we could not wait safly
10:28:30 sean-k-mooney gibi: are you seeing a issue wiht not waiting currently?
10:28:52 sean-k-mooney or was this just courisity
10:29:13 gibi I have a downstream case (on pike) where the nova unplug / replug behavior at openstack server start causes problems in ODL
10:29:40 gibi but you said that odl won't even send us plugtime events
10:30:00 gibi so waiting won't be the solution
10:30:17 gibi wondering if for backends not supporting plug time events we need to rebind
10:30:20 sean-k-mooney ah ml2/odl used to send events at bind time yes not at plug time but i think later version might have adress that
10:30:43 gibi ohh, good info, then I have to figure out the odl version too
10:31:05 sean-k-mooney give me to second and ill see if i can find that in the odl neutron driver
10:32:04 sean-k-mooney basically to support bind time event they had to open a websock that odl could call back to to send event to neutron which neuton could then send to nova
10:32:11 sean-k-mooney that was not part of the orginal ml2 driver
10:32:52 gibi you mean for plug time event
10:33:01 sean-k-mooney so in the legacy driver they just hardcoded the port as active as soon as the port was bound https://opendev.org/openstack/networking-odl/src/branch/master/networking_odl/ml2/legacy_port_binding.py#L58-L61
10:33:28 sean-k-mooney which resulted in network-vif-plugged beign sent at bind time only
10:34:03 sean-k-mooney then latere they added a way to get port status updates form odl https://opendev.org/openstack/networking-odl/commit/3432e0f875f8243a2c1febf2012bd0f58863c56b
10:34:34 sean-k-mooney https://opendev.org/openstack/networking-odl/src/branch/master/networking_odl/ml2/port_status_update.py#L91-L95
10:34:46 sean-k-mooney and then they would correctly send plug time events
10:35:02 sean-k-mooney gibi: but pike might predate that
10:35:32 gibi cool, I can check the dates then
10:35:36 gibi sean-k-mooney: thanks a lot
10:36:08 gibi so the solution is fresh enough networking-odl to have plug time event, and the in yoga think about waiting for plug time event at reboot as well
10:36:15 sean-k-mooney no worries assuming we can confirm this works today we could add odl also to the list of "send plug events" or whatever and then start waiting
10:36:29 sean-k-mooney yep
10:36:52 gibi does neutron have odl jobs in the upstream ci?
10:36:53 sean-k-mooney so we dont really need to wait for the ptg to discuss this i just have not had time to work on a spec
10:37:05 sean-k-mooney good question im not sure
10:37:10 gibi ok I will check that too
10:37:12 sean-k-mooney i suspect not
10:37:24 sean-k-mooney networking-odl should have jobs however
10:37:48 gibi ahh good point that is a separate repo with it own jobs
10:38:05 sean-k-mooney https://opendev.org/openstack/networking-odl/src/branch/master/.zuul.d/project.yaml#L51-L52
10:38:26 sean-k-mooney it also has multi node versions
10:38:38 gibi cool then we can have test coverage upstream about the change
10:39:06 sean-k-mooney am on thing i have been talking to artom about is possible adding some other network toplogies to nova's gate as a periodic
10:39:49 sean-k-mooney so right now we have ovs with iptables in nova-next, we have ovn for most things and linux bridge for some file changes
10:40:16 sean-k-mooney it might be nice to add a weekly multi node odl and ml2/ovs job
10:40:41 sean-k-mooney weekly multi-node job that is to tesst migration and resize ectra
10:41:09 gibi I would expect that some of this coverage is already running on the neutron side
10:41:34 gibi but if not then I agree we can add it
10:41:43 sean-k-mooney that will tell them if we break things but only if the project is activly beign developed
10:42:33 sean-k-mooney it looks like networking-odl for example only gets comiits every month or so
10:42:48 gibi yeah, that is a good point too
10:43:02 gibi then we need the periodic to trigger testing even if networking-odl is not changed
10:43:47 sean-k-mooney yep just to make sure we did not break something. but really weekly is more then enought i think
10:43:56 sean-k-mooney we can review it like the placment jobs
10:44:41 gibi yepp, agree
10:45:04 sean-k-mooney gibi: i would also like to add dpdk at some point but i have not been maintaining networking-ovs-dpdk so i will need to add devstack support for dpdk or fix it before thats even posible at this poing
10:45:07 sean-k-mooney *point
10:46:00 gibi I support that idea too. Downstream we use dpdk a lot, so would be nice to get coverage for it upstream.
10:46:15 sean-k-mooney fortunetly on the dpdk front its support by distros now so its now just a matter of turning it on and seting a few config values but still need to sit down and do that
10:46:38 gibi let me know if I can help
10:47:00 sean-k-mooney sure will do. when i get around to workign on the devstack patches ill let you know
11:09:46 opendevreview sean mooney proposed openstack/nova master: Ensure MAC addresses characters are in the same case https://review.opendev.org/c/openstack/nova/+/811947
11:14:44 sean-k-mooney noonedeadpunk: hopefully you dont mind me updateing ^
11:15:07 sean-k-mooney gibi: can you take a look at ^ when you have time
11:16:26 gibi ack I will try
11:19:48 noonedeadpunk sure I'm not!
12:20:59 opendevreview Lee Yarwood proposed openstack/nova-specs master: WIP libvirt: Allow Manila shares to be directly attached to instances https://review.opendev.org/c/openstack/nova-specs/+/813180
14:37:22 lyarwood stupid Friday question but can anyone think of an API where we've changed the return code in a microversion? I want to fix the POST os-volume_attachments method to return 202 but I can't think of the best way to do this
14:39:17 lyarwood ah nvm I see just duplicate the actual method and decorate it
15:00:02 bauzas lyarwood: correct, I was about to point it to you
15:00:09 bauzas (sorry for the late ping, kids taxi)
15:00:20 bauzas lyarwood: do you want to discuss on your spec ?
15:00:20 stephenfin lyarwood: There are quite a few APIs that suffer from that issue. Are you just going to do the one or multiple?
15:04:11 bauzas lyarwood: fwiw, I'm leaving in 25 mins for the weekend
15:06:43 lyarwood bauzas: sorry was just getting a drink, happy to chat now if you had any questions etc
15:06:59 bauzas I briefly looked at your spec

Earlier   Later