Monday, 2021-10-11

*** bhagyashris is now known as bhagyashris|rover04:43
*** abhishekk is now known as akekane|home04:50
*** akekane|home is now known as abhishekk04:50
bauzasgood morning Nova07:45
opendevreviewDmitriy Rabotyagov proposed openstack/nova master: Ensure MAC addresses characters are in the same case  https://review.opendev.org/c/openstack/nova/+/81194707:52
plibeau4hello, I need your help about this proposal change: https://review.opendev.org/c/openstack/nova/+/803713.08:24
gibigood morning08:50
gibithis week feels to be as crazy as the last was for me. you can ping me but I cannot promise things :/08:51
bauzasplibeau4: ack, will add your change for a review08:55
bauzasthanks for reaching us08:56
plibeau4thx guys take your time it's just to have your feedback It's already in production on myside :)09:24
plibeau4and if you have time -> https://review.opendev.org/c/openstack/nova/+/80360009:25
sean-k-mooneyto me https://review.opendev.org/c/openstack/nova/+/803713 kind of feels like intoducing a race condetion09:26
sean-k-mooneyi guess its not a race as it does not quiesce the disk until after the dev rebase is complete deterministically09:29
sean-k-mooneyplibeau4: im not conviced moving the quiece is safe to have in production09:43
sean-k-mooneyplibeau4: i think it can lead to data currportion if we are not very careful09:44
gibisean-k-mooney: re: waiting for vif-plugged during hard reboot. What is the piece of information in the port that can be used to decide if the networking backend sends plug event at plug time?09:50
sean-k-mooneygibi: https://specs.openstack.org/openstack/neutron-specs/specs/train/port-binding-extended-information.html09:53
sean-k-mooneybinding_details: {09:53
sean-k-mooney    ...09:53
sean-k-mooney    "connectivity": "l2",09:53
gibithanks09:53
sean-k-mooney    "bound_drivers": {"0": "openvswtich"}09:53
sean-k-mooney}09:53
sean-k-mooneygibi: we could use the bound_drivers to infer this09:54
sean-k-mooneythe spec orginaly had an events section that told use when it sent events09:54
sean-k-mooneythat was unfrotunetly removed because we could not agree on how to model that09:54
sean-k-mooneyso we would have to create a lookup table in nova and map the driver name to it09:55
sean-k-mooneyopendaylight was bind time, opendaylight_v2 is plug time09:55
gibiack. I might need to create a solution on Pike level downstream hence my continued digging in it09:56
sean-k-mooneythe conneectivy field is waht we need to use to know if we can safely allow unadress port too09:56
gibibut if the infor is in train then I cannot use that in Pike09:56
sean-k-mooneyif its l2 it does not need an ip09:56
sean-k-mooneygibi: i think a workaround config option to force_rebind_on_reboot is the way to go and backport that09:57
gibiyeah I thinking about a config too09:57
sean-k-mooneythere are reasons to have that on master by the way09:58
sean-k-mooneycombidnind with unpluging on reboot09:58
sean-k-mooneybasically if you make reboot:  power off-> unplug-> unbind->rebind->plug->spwan09:58
sean-k-mooneythen you can do things like change the firewall driver or maybe even ml2/backend09:59
gibiwhy do you want to add bind to the picture?09:59
gibiahh I see09:59
sean-k-mooneycurrently you have to live migrate09:59
gibito allow change thing that needs a binding09:59
sean-k-mooneybut we have some customer saying they want to do it inplace and are ok with stoping the vm09:59
sean-k-mooneyyes09:59
sean-k-mooneybasicaly some large customes have said to use we cant live migrate every vm we have but we can stop them cause we run everything in duplex mode and can go simplex for a period of time without issue10:00
gibiOK so there is two parallel direction to pursue. 1) add a workaround flag for something like wait_for_plug_event_at_reboot and 2) force_rebind_on_reboot to allow in place update of binding related data10:01
sean-k-mooneyso they are fine with stop(tearing down all networking) and start(setting up all networking) to "migrate" form one firewall driver to another (iptables->ovs) or between mech drvers(ml2/ovs->,l2/ovn)10:02
sean-k-mooneygibi: am yes i guess so10:02
gibithe problem (most probably) on my side is that they do VM reboots in big batches due to upgrade and nova sends a lot of unplug - plug event to ODL which fails to finish setting up OVS before the VM starts requesting IP via DHCP10:02
gibiso if they can set a WA flag in nova that nova should wait for the network-vif-plugged before letting the VM run at reboot would help to control the situation10:04
sean-k-mooneyyep10:04
gibiand they need it on Pike :/10:04
gibiI will go with a backportable WA flag10:05
sean-k-mooneyya so on master i think we need to look at how and when we use events and for pike workaround flag is definetly the simplest thing as only the custoemr that is affect can opt in by settting it minimising the risk to others that dont need the change10:07
sean-k-mooneygibi: i had planned to bring up ovn live migration at the ptg(which is affected by the vif-plugged-events) but i might just make tha ta general topic since i think the ovn issue will require ovn changes to fully resolve10:09
jpichi all, i don't understand what is supposed to keep the websocket between the spice html5 client and the spice server? browsers will kill inactive websockets after 60 secs of inactivity, so i suppose the server is supposed to send ping packets regularily10:19
gibisean-k-mooney: ack10:40
gibisean-k-mooney: one more thing, I don't see "bound_drivers" ever got implemented in neutron. Only neturon-lib has the field definition https://review.opendev.org/c/openstack/neutron-lib/+/645288/6/neutron_lib/api/definitions/portbindings.py#55 but neutron does not use that 10:47
gibiI only see the connectivity field being implemented10:47
gibiin https://review.opendev.org/c/openstack/neutron/+/645645/10:47
sean-k-mooney i see... am i think it was ment to be implemented at the ml2 plugin level above the drivers but you might be right11:05
sean-k-mooneyhttps://review.opendev.org/c/openstack/neutron-lib/+/645288/6/neutron_lib/api/definitions/portbindings.py added bound_drivers to the extension11:06
sean-k-mooneybut im not sure if they have used it11:06
sean-k-mooneylooks like its only in neutron-lib https://codesearch.opendev.org/?q=VIF_DETAILS_BOUND_DRIVERS&i=nope&literal=nope&files=&excludeFiles=&repos=11:08
gibiyeah that matches with my grep results11:08
sean-k-mooneyso ya looks like we would need to actully implement that on master before we can use it11:09
gibiyepp, it looks like11:09
sean-k-mooneyi feel less bad for not using it yet11:09
gibi:)11:10
sean-k-mooneyhas anyone else had devstack time out on pip resolver issues12:15
sean-k-mooneyCollecting oslo.policy>=3.8.112:22
sean-k-mooney  Using cached oslo.policy-3.8.2-py3-none-any.whl (86 kB)12:22
sean-k-mooneyINFO: This is taking longer than usual. You might need to provide the dependency resolver with stricter constraints to reduce runtime. If you want to abort this run, you can press Ctrl + C to do so. To improve how pip performs, tell us what happened here: https://pip.pypa.io/surveys/backtracking12:22
gibisean-k-mooney: I haven't seen that pip issue yet12:40
opendevreviewBalazs Gibizer proposed openstack/nova master: Add a WA flag waiting for vif-plugged event during reboot  https://review.opendev.org/c/openstack/nova/+/81341912:47
gibisean-k-mooney: ^^ this is my first try on the hard reboot - vif plug issue12:47
sean-k-mooneyi think its cause by cinder's dep on oslo.vmware which is pulling in suds-jurko12:48
sean-k-mooneywhich is an unmaintained soap lib fork12:49
sean-k-mooneygibi: that is just the events right are you working on a second patch for rebinding12:50
sean-k-mooneyi guess you might not need that in your case12:51
gibisean-k-mooney: it is jut the event waiting12:51
sean-k-mooneywas pikes version of netwokring-odl new enough to send plug time events12:51
gibisean-k-mooney: yes, the plug time event patch was merged in pike12:51
sean-k-mooneyah ok cool12:51
gibihttps://review.opendev.org/c/openstack/networking-odl/+/46546312:52
gibithis is the patch12:52
sean-k-mooneydo you have a DNM patch that sets that to true or set it in the job so we can see it work12:52
gibisean-k-mooney: good point I will add that12:52
gibisean-k-mooney: ml2/ovs works for me with this locally 12:52
gibisean-k-mooney: so we can enable this WA in our normal ovs jobs12:53
sean-k-mooneycool, ya currently its disabled so we wont see if this breaks anything although it will break ovn actully12:53
sean-k-mooneyya we could enable it in nova-next12:53
gibiI think I will enable this flaf in nova-next12:53
gibiexactly :D12:53
sean-k-mooneyyep also we might want to renable a multinode jobs with ml2/ovs at some point12:53
sean-k-mooneyim not sure what coverage we have/have lost with the ovn default swap12:54
sean-k-mooneyi think nova-next might be the only job that is still using ml2/ovs (other then linuxbrige job) in our gate today12:55
sean-k-mooneyi dont think we have a multi node job with a backend that send plugtime events currently12:55
gibisean-k-mooney: nova-next is multinode afaik12:56
gibi    name: nova-next12:57
gibi    parent: tempest-multinode-full-py312:57
gibiyepp it is multinode12:57
opendevreviewBalazs Gibizer proposed openstack/nova master: Add a WA flag waiting for vif-plugged event during reboot  https://review.opendev.org/c/openstack/nova/+/81341912:58
sean-k-mooneygibi: oh ok cool13:05
gibibauzas: fyi, I now remember that there will by TC + PTL discussion slot on the PTG. https://etherpad.opendev.org/p/tc-yoga-ptg L15 (Monday 15 UTC)13:20
gibibauzas: https://etherpad.opendev.org/p/tc-ptl-interaction13:20
gibiI will join too13:20
gibijust to listen in 13:20
gibior fill in info from the past if needed13:20
bauzasgibi: sorry was off13:44
bauzasgibi: ack, I was wondering when the slot was there13:44
opendevreviewBalazs Gibizer proposed openstack/nova stable/pike: Add a WA flag waiting for vif-plugged event during reboot  https://review.opendev.org/c/openstack/nova/+/81343714:02
opendevreviewnorman shen proposed openstack/nova master: Add a timeout for waiting volume snapshot ready  https://review.opendev.org/c/openstack/nova/+/81344314:26
dansmithgibi: wow, pike huh? :)15:13
gibidansmith: last week I was pulled into a discussion upgrading Mitaka deployments to Victoria. Pike is easy compared to that15:13
dansmithhah15:14
gibitelcos are slooow15:14
dansmith:)15:14
melwittbauzas: these backports are finally ready for review after the stable/train gate fixes https://review.opendev.org/c/openstack/nova/+/806629 and the patch under it, if you could take a look15:24
bauzasmelwitt: ack, opening a tab and looking at them once we discuss about other issues ;)15:25
melwittthanks :)15:25
opendevreviewElod Illes proposed openstack/nova stable/stein: [stable-only] Pin virtualenv and setuptools  https://review.opendev.org/c/openstack/nova/+/81345115:35
opendevreviewDmitrii Shcherbakov proposed openstack/nova master: [yoga] Add PCI VPD Capability Handling  https://review.opendev.org/c/openstack/nova/+/80819917:31
opendevreviewDmitrii Shcherbakov proposed openstack/nova master: [yoga] Support remote-managed SmartNIC DPU ports  https://review.opendev.org/c/openstack/nova/+/81211117:31
mdboothNot really an OpenStack issue, but as I'm hitting it running devstack on Ubuntu Focal I'm hoping somebody here has seen it before 🤞 c-vol fails to come up because lvcreate fails to create a thin volume due to: "modprobe: FATAL: Module dm-thin-pool not found in directory /lib/modules/5.4.0-1047-kvm". Anybody seen that?19:39
mdboothMy google-fu is unfortunately not up to the task.19:41
clarkbmdbooth: you might have to install something like linux-image-extra-virtual but for the kvm kernel19:57
mdboothclarkb: Thanks. I was just coming to the realisation that this image might have a stripped down kernel for kvm in it. I think I'm going to toss it and try a different cloud image.19:58
clarkblinux-image-virtual doesn't have that module either fwiw, but they do ship linux-image-extra-virtual which I expect includes it19:59
mdboothThanks!20:00
clarkbI don't see a virtual package for extra kvm image kernel modules but there are package for specific kernel versions like linux-modules-5.4.0-1009-kvm20:00
clarkbI did check the kernel config for the linux-image-virtual kernel I've got and it lists DM_THIN_PROVISIONING=m so there should be a module for it in a package somewhere20:01
mdboothLooking good: # find /usr/lib/modules/5.4.0-88-generic/ -name "*thin*"20:21
mdbooth /usr/lib/modules/5.4.0-88-generic/kernel/drivers/md/dm-thin-pool.ko20:21
mdboothclarkb: Thanks again :)20:21

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!