Tuesday, 2021-05-11

*** hamalq has quit IRC00:06
*** sapd1 has quit IRC00:19
*** artom has quit IRC00:28
*** hemanth_n has joined #openstack-nova00:41
*** hemanth_n has quit IRC00:50
openstackgerritlikui proposed openstack/nova master: Replace getargspec with getfullargspec  https://review.opendev.org/c/openstack/nova/+/79040500:54
*** gyee has quit IRC01:06
*** hoonetorg has quit IRC01:06
*** __ministry has joined #openstack-nova01:12
openstackgerritlikui proposed openstack/nova master: Replace getargspec with getfullargspec  https://review.opendev.org/c/openstack/nova/+/79040501:28
*** hemanth_n has joined #openstack-nova02:09
*** whoami-rajat has quit IRC02:18
openstackgerritQiu Fossen proposed openstack/nova-specs master: Allow migrating PMEM's data  https://review.opendev.org/c/openstack/nova-specs/+/78556302:52
*** swp20 has joined #openstack-nova03:29
*** viks____ has joined #openstack-nova05:08
*** ralonsoh has joined #openstack-nova05:10
*** pmannidi has joined #openstack-nova05:12
*** pmannidi has quit IRC05:13
*** k_mouza has joined #openstack-nova05:14
*** k_mouza has quit IRC05:18
*** cgoncalves has quit IRC05:27
*** cgoncalves has joined #openstack-nova05:27
*** bnemec has quit IRC05:27
*** bnemec has joined #openstack-nova05:29
*** ratailor has joined #openstack-nova05:42
*** elzim has joined #openstack-nova05:51
*** vishalmanchanda has joined #openstack-nova06:22
*** elzim has quit IRC06:23
*** dklyle has quit IRC06:39
*** links has joined #openstack-nova06:51
*** macz_ has joined #openstack-nova07:02
gibisean-k-mooney: thank you07:06
*** macz_ has quit IRC07:07
*** andrewbonney has joined #openstack-nova07:23
*** aarents has quit IRC07:25
*** LinPeiWen80 has quit IRC07:27
*** aarents has joined #openstack-nova07:32
*** ociuhandu has joined #openstack-nova07:35
*** rpittau|afk is now known as rpittau07:38
*** tosky has joined #openstack-nova07:39
*** mgoddard has quit IRC07:45
*** ociuhandu has quit IRC07:45
*** ociuhandu has joined #openstack-nova07:46
*** mgoddard has joined #openstack-nova07:50
*** ociuhandu has quit IRC07:50
openstackgerritlikui proposed openstack/nova master: Replace getargspec with getfullargspec  https://review.opendev.org/c/openstack/nova/+/79040508:06
*** lucasagomes has joined #openstack-nova08:11
*** alexe9191 has joined #openstack-nova08:11
*** ociuhandu has joined #openstack-nova08:16
*** ociuhandu has quit IRC08:17
*** ociuhandu has joined #openstack-nova08:17
sean-k-mooneygibi: bauzas: im not going to make a commitment now but im going to explore if i can provide a limited replacement for upstream elk stack hosted on my home infrastucture08:22
bauzaswell08:22
*** lpetrut has joined #openstack-nova08:22
bauzasI can't say how I'm a sad panda08:22
sean-k-mooneymy basic plan is when i redeploy my home infrastucure in a week or two im going to redeply my ci and add a job that will trigger only on upstrem zuul -1/-2 comments and try and download the logs form those jobs and ingest them into elk08:23
sean-k-mooneyill start with just nova and see if i can get that to work08:24
sean-k-mooneyonly looking at failed jobs should keep the bandwith mangeable, the full ci generate maybe 4TB of logs a month which i cans store but my isp would not be happy with me downloadign that much08:27
*** martinkennelly has joined #openstack-nova08:31
*** rcernin has quit IRC08:32
swp20stephenfin: i use admin context to show a project's vm by id and it's success, but by name it says no name or id exist. is this a bug?08:33
stephenfinswp20: no, API resources are organized by ID. You need to list and manually search or use a specific search API. Look at the 'Resource.find' method in openstacksdk for an example08:40
*** macz_ has joined #openstack-nova08:45
*** macz_ has quit IRC08:50
swp20stephenfin: yeah, i find the 'Resource.find' has no 'all_tenants' param, if i add the {'all_tenants':1} to kwargs, then i can get the vm by name.08:50
swp20so need we claim this when we exec 'nova help show' command, it's really a bit confused.08:54
*** LinPeiWen93 has joined #openstack-nova09:01
*** rcernin has joined #openstack-nova09:09
*** avolkov has joined #openstack-nova09:21
*** rcernin has quit IRC09:27
openstackgerritlikui proposed openstack/osc-placement stable/ussuri: Update command help information  https://review.opendev.org/c/openstack/osc-placement/+/79061809:34
*** rcernin has joined #openstack-nova09:34
*** alexe9191 has quit IRC09:35
openstackgerritlikui proposed openstack/osc-placement master: setup.cfg: Replace dashes with underscores  https://review.opendev.org/c/openstack/osc-placement/+/79063009:41
*** ociuhandu has quit IRC09:52
*** rcernin has quit IRC09:53
*** macz_ has joined #openstack-nova09:55
openstackgerritDavid Vallee Delisle proposed openstack/os-vif master: Creating oslo.config.opts entry_points for plugins  https://review.opendev.org/c/openstack/os-vif/+/78964509:57
*** macz_ has quit IRC10:00
*** Luzi has joined #openstack-nova10:03
*** k_mouza has joined #openstack-nova10:05
*** k_mouza has quit IRC10:05
*** k_mouza has joined #openstack-nova10:07
*** ociuhandu has joined #openstack-nova10:10
*** dtantsur|afk is now known as dtantsur10:15
stephenfinlyarwood: Could you stick this on your review queue for the week, if you've time? https://review.opendev.org/c/openstack/nova/+/67620910:21
stephenfinbauzas: Any chance you could keep going through the instance_type -> flavor series? If any of them are too difficult to review, I can try break them up more https://review.opendev.org/q/topic:%2522compute_rpc_6.0%2522+status:open10:22
bauzassean-k-mooney: any reason why you try to plug vifs *after* we try to reboot the instance or restart it ? https://github.com/openstack/nova/blob/7953c0197d1a4466cb5b78070d47626c92f9db6e/nova/compute/manager.py#L113710:23
bauzasstephenfin: yup, I started to look at those10:23
bauzasstephenfin: today, I'll do some reviews, specs first but I can try to look at your series too10:23
stephenfingood enough for me, ty :)10:24
bauzasstephenfin: btw. I'm off tonight until next week10:24
stephenfinokay, gtk10:24
bauzas(perpetual PTOs as mriedem said, that's it)10:24
bauzasor... just May10:24
*** k_mouza_ has joined #openstack-nova10:25
*** k_mouza has quit IRC10:28
*** lpetrut has quit IRC10:30
sean-k-mooneybauzas: we plug before we start the instance10:30
sean-k-mooneyalthopugh i guess its after in some cases10:31
sean-k-mooneyhum10:31
bauzassean-k-mooney: look at the above10:31
sean-k-mooneyya i am10:31
bauzassean-k-mooney: we try to reboot the instance first10:31
bauzasand then we also try to restart it10:32
bauzas*before we plug the vifs*10:32
sean-k-mooneywe might be trying to plug wtice but i dont see any reason not to plug first10:32
sean-k-mooneythat would be more correct i think10:32
bauzasok, I'm asking this because I'd prefer to pass the allocations to the new driver method I created *before* the two above calls10:32
sean-k-mooneyya i also think that proably makes sense10:33
bauzasif you reboot the instance with not the mdevs, then you got a qemu exception10:33
sean-k-mooneyyep so it should be create mdevs then plug vifs then reboot10:33
* bauzas also needs to find a vGPU env, btw. :)10:33
sean-k-mooneymaybe see if you can borrow one form james if they are not using it for qe tests10:35
sean-k-mooneybauzas: so ya just checked the code10:36
sean-k-mooneythat is litgimatly a bug that plug vifs is after the vm start10:36
sean-k-mooneythe reboot code path is assumign its done before10:36
bauzaskk10:37
sean-k-mooneyit wont break things entirly in that we will fix it after but we should move it earlier10:37
bauzasok, so I'll write the code10:37
bauzassean-k-mooney: do you want me to write the bug report for the vifs one ?10:37
bauzasor you ?10:37
sean-k-mooneyhehe i mean if you feel like it go for it10:38
sean-k-mooneyyou can point to https://github.com/openstack/nova/blob/7953c0197d1a4466cb5b78070d47626c92f9db6e/nova/virt/libvirt/driver.py#L3773-L377510:38
sean-k-mooneyas evidnce that we expect ti to be alredy plugged10:38
bauzasok, gotta go lunching but I'll write it later10:38
* bauzas already has a shit ton of open tabs10:38
bauzashopefully, my new laptop would arrive...10:39
sean-k-mooneydid you get a ship date or just hoping its on its way10:39
bauzasI asked10:39
bauzas"I just checked with our vendor and the laptop is currently in the status 'Allocated', which means that it should be sent soon (in a matter of days)."10:39
bauzas(I know we are in an upstream channel, but that's not a secret phrase ;) )10:40
bauzasthis was 7 days ago, so I'm not against a delivery surprise10:40
bauzascontext : CPU shortages on vendors, leaving my refreshment order open for 6 months, craziness of the post-covid economy10:41
bauzas(also the fact that most of the vendors are fabless...)10:42
*** rcernin has joined #openstack-nova10:44
sean-k-mooneywell hopefully you will get it sooner then your broadband upgrade10:45
*** rcernin has quit IRC10:48
*** lpetrut has joined #openstack-nova10:56
openstackgerritLee Yarwood proposed openstack/nova master: Add regression test for bug #1928063  https://review.opendev.org/c/openstack/nova/+/79065811:06
openstackbug 1928063 in OpenStack Compute (nova) "SEV enabled instance unable to hard reboot" [Undecided,New] https://launchpad.net/bugs/1928063 - Assigned to Lee Yarwood (lyarwood)11:06
openstackgerritLee Yarwood proposed openstack/nova master: WIP compute: Persist image id within the system_metadata of an instance  https://review.opendev.org/c/openstack/nova/+/79065911:06
openstackgerritLee Yarwood proposed openstack/nova master: WIP hardware: Use image_meta.id within get_mem_encryption_constraint  https://review.opendev.org/c/openstack/nova/+/79066011:06
lyarwoodstephenfin: ack I'll review the mypy stuff this week, apologies for not getting to it before PTO11:07
stephenfinta11:14
*** k_mouza_ has quit IRC11:17
*** ociuhandu has quit IRC11:21
*** ociuhandu has joined #openstack-nova11:22
*** ociuhandu has quit IRC11:26
*** lpetrut has quit IRC11:27
gibisean-k-mooney: thanks for trying to cover some part of the ELK stack.11:38
sean-k-mooneygibi: ill be reinstalling my home system later in the week so ill try and see if i can get something working at the weekend11:44
sean-k-mooneyim hoping i can just use kolla's supprot for deploying elk or efk technically to maintian the stack11:45
sean-k-mooneywhat i need to figure out is what is the best way to upload the logs to it form the upstream jobs11:46
sean-k-mooneyim thinking of trying the http plugin for fluentd to submit the logs with basically curl.11:49
sean-k-mooneyhttps://docs.fluentd.org/input/http11:49
*** k_mouza has joined #openstack-nova11:53
*** mkrai has joined #openstack-nova11:56
*** ociuhandu has joined #openstack-nova11:58
*** ociuhandu has quit IRC12:02
*** dpawlik has quit IRC12:12
*** admin0 has joined #openstack-nova12:18
*** ociuhandu has joined #openstack-nova12:19
admin0hi guys .. is it possible to add bus and slot on pci_passthrough alias whitelist ?12:19
admin0alias = { "vendor_id":"8086", "product_id":"154d", "device_type":"type-PF", "name":"a1", "numa_policy":"preferred" }12:19
admin0if there is multiple network-cards or multiple pci cards or the same vendor and product-id , how do I differencitate it12:19
*** dpawlik3 has joined #openstack-nova12:20
*** ratailor has quit IRC12:22
admin0in whitelist we can specify the bus slot and function ..   but how to do it in alias ?12:22
admin0https://docs.openstack.org/nova/latest/configuration/config.html#pci.alias  -- does not show this feature12:23
*** dpawlik3 is now known as dpawlik12:26
admin0the use case is this ... say i have 4 devices, and i want to pick device 1 and 4 for vm1 and 2 and  3 for vm2 .. what happens is since i cannot pass the bus/slot on alias, it picks up device 1 and 2 for first vm and 3 and 4 for 2nd vm .. if its possible to pass the exact in alias somehow, it might solve that issue12:27
sean-k-mooneyadmin0: no12:30
sean-k-mooneyalias are not specifc to any host12:30
sean-k-mooneyor device12:30
admin0you mean there is no feature for me to alias 4 specifc device of the same kind ?12:31
sean-k-mooneywe do not allow alias to select a specifc devcie by design12:32
sean-k-mooneyyou can have muplite device of the same type on the host but an alais can only be used to select a device of a given type not a specific one12:32
admin0sean-k-mooney, thanks ... so what possbility exits if I have multiple devices of the same type and I want to target specific ones ?12:33
sean-k-mooneyyou cannot do that with nova12:33
sean-k-mooneywhat is your usecase for doing that12:33
sean-k-mooneyoh sorry you said it above just reading it again12:34
sean-k-mooneyam not we cant do the 1,4 2,3 split you want12:34
sean-k-mooneyare you doing that for numa reasons or soemthign else?12:35
admin0numa reasons12:35
sean-k-mooneyare tehy multi numa guest or singel numa12:35
sean-k-mooneyi assume the vm has 2 numa nodes and you want one form each numa node?12:36
sean-k-mooneyso you want to spread the allcoation across host numa nodes?12:36
admin0right12:37
*** ociuhandu has quit IRC12:43
sean-k-mooneyadmin0: we currentl do not have a feature to enable that and if you did it today it woudl reduce your performance13:02
sean-k-mooneywe have a downstream backlog item https://bugzilla.redhat.com/show_bug.cgi?id=1762119 which would allow use to create a pcie root complex per virtual guest numa node13:03
openstackbugzilla.redhat.com bug 1762119 in openstack-nova "[RFE] Create a virtual PCI root complex per guest NUMA node when using q35" [High,New] - Assigned to nova-maint13:03
sean-k-mooneybut without that today all pci device are effectivly assocated with the guest virtual numa node 013:04
sean-k-mooneyso you would have corss numa traffic if you enabeld it today13:04
sean-k-mooneyadmin0: if we create a virtual PCI root complex per guest NUMA node that will allow use to optimise the virtual toplogy but its a large change13:05
sean-k-mooneynova would have to fully generate the virtual pci topology and assign pci addres to each device13:06
*** hemanth_n has quit IRC13:06
sean-k-mooneyits not imposiable to do and we hope to do it eventually but its of similar complexity to cpu pinning13:06
admin0sean-k-mooney, thank you for the info13:08
*** ociuhandu has joined #openstack-nova13:09
*** rcernin has joined #openstack-nova13:13
*** ociuhandu has quit IRC13:14
sean-k-mooneygibi: by the way for the vdpa move ops are you oke with a specless blueprint or would you like a mini spec?13:18
sean-k-mooneyim working on the pci in placement spec draft first in either case but cant recall if what we said in the ptg13:19
sean-k-mooneyah we just said "do the life cycle operations except suspend and live migrate" but did not say how we would track13:20
*** ociuhandu has joined #openstack-nova13:23
*** rcernin has quit IRC13:26
*** ignaziocassano has joined #openstack-nova13:29
ignaziocassanoHello Everyone, I got issues on GARP during live migrations on Rocky and Stein with centos 7. I applyed some patches to force legacy port binding. Now I am igrating on train and I got same issues. Any help please ?13:31
openstackgerritTobias Urdin proposed openstack/nova master: Stop leaking ceph df cmd in RBD utils  https://review.opendev.org/c/openstack/nova/+/78937413:36
sean-k-mooneythere is not much more we can do really.13:37
ignaziocassanoTobias, did you solve your problems on train for live migration ?13:37
*** Roamer` has quit IRC13:38
sean-k-mooneyignaziocassano: remind me again are you using ml2/ovs with iptables13:38
sean-k-mooneyor are you suing the ovs firewall dirver or ovn?13:39
ignaziocassanomy configuration is firewall_driver = iptables_hybrid and I am not usinn ovn13:40
*** artom has joined #openstack-nova13:41
ignaziocassanoI applyed neutron patch for evacuate and nova patches but it does not solve13:42
ignaziocassano    https://review.opendev.org/c/openstack/neutron/+/640258/13:43
ignaziocassanohttps://review.opendev.org/c/openstack/neutron/+/753314/13:43
ignaziocassanohttps://review.opendev.org/c/openstack/neutron/+/766277/13:43
ignaziocassanohttps://review.opendev.org/c/openstack/nova/+/742180/1213:43
ignaziocassanohttps://review.opendev.org/c/openstack/nova/+/747454/413:43
sean-k-mooneyso for ovs with iptables we were already pluging the port into ovs in prelive migrate13:44
sean-k-mooneyand by that i mean creating the ovs port in the ovs db13:45
sean-k-mooneyso with https://review.opendev.org/c/openstack/neutron/+/640258/ and https://review.opendev.org/c/openstack/neutron/+/753314/13:45
sean-k-mooneyactully you dont need either of those pathces13:46
sean-k-mooneythe l2 agent woudl have wired it up because with iptabels we are createing a linux bridge and a veth pair13:46
ignaziocassanoI am facing same problems I got with stein13:46
sean-k-mooneyso the only neutorn patch you needed was https://review.opendev.org/c/openstack/neutron/+/766277/ to avoid the dhcp server race13:47
ignaziocassanoOn stein I solved with your workaround force legacy port binding13:47
sean-k-mooneywell that wont actuly solve it13:48
sean-k-mooneywhen you use legacy port bindign neutron has the port boudn to the souce node until much much later in the live migrtion13:48
sean-k-mooneywe still create the port on the destitaiton at the same time in both flows13:49
sean-k-mooneybut we use stale info form nuetorn to do it13:49
sean-k-mooneyignaziocassano: are you still forcing legacy mode in train13:50
sean-k-mooneyif you backport https://review.opendev.org/c/openstack/neutron/+/766277 it will only help if you are using multiple port bindings13:51
ignaziocassanoSean, I desabled the workaround for using legacy port binding. I think It is automatically disabled when I upgraded from stein to train because workaround.py is covered be new version. Right ?13:51
sean-k-mooneywell you are expecting the new install to overright the exsiting files13:52
sean-k-mooneyit should but that depens on how you isntalled13:52
ignaziocassanoyum update13:52
sean-k-mooneyi think that will yes the rpm should unpack over the modifed one13:53
sean-k-mooneyso on the neutron side you have backported https://review.opendev.org/c/openstack/neutron/+/766277 to train13:53
sean-k-mooneyand enabled it by seeing [nova]/live_migration_events=true13:54
sean-k-mooneyhttps://review.opendev.org/c/openstack/neutron/+/766277/10/neutron/conf/common.py#17713:54
ignaziocassanoSo13:54
ignaziocassanolet me to verify if I understodd well13:54
ignaziocassano766277 patch is alrady in centos 7 packages13:55
*** stephenfin has quit IRC13:56
ignaziocassanoand I must enable live_migration_events=true13:57
sean-k-mooneyam if 766277 patch is alrady in centos 7 packages its because we have backported that downstream and it got pulled into rdo that may be the case but i dont know why ralonsoh woudl not have also done an upstream backport13:58
sean-k-mooneybut yes enabling live_migration_events=true will prevent the race between the dhcp agent and the l2 agent13:58
*** mlavalle has joined #openstack-nova13:58
sean-k-mooneythat race exists for legacy and mutltiple prot binding workflows13:59
*** Luzi has quit IRC13:59
ignaziocassanoSo I must check if 766277 is in centos7 rpm packages ?13:59
ignaziocassanoSorry for my english14:00
sean-k-mooneyyes i am not sure if it will be14:00
ralonsohsean-k-mooney, what patch?14:01
ignaziocassanoOK. Let me to recap: 1) check if patch is includes. If not I patch code with patch command. 2) enable live_migration_events=true14:01
ignaziocassanothe patch is https://review.opendev.org/c/openstack/neutron/+/766277/10/neutron/conf/common.py#17714:02
ignaziocassanoor all 766277 patches ?14:03
ralonsohI didn't backported this patch because was not required and not supported in older versions14:03
sean-k-mooneyralonsoh: well the dhcp race has always exsited so that technially affecte every neutron release14:04
*** tbachman has joined #openstack-nova14:05
ralonsohonly for hybrid plugin14:05
ralonsohnow nova has this code, I can backport it in U/S14:05
ralonsohI'll do it today14:05
sean-k-mooneywell hybrid plug was the default deployment mode until very very recently14:06
gibisean-k-mooney: does the vdpa lifecycle operations handled as bugfix from API perspective or we bump a microversion for it?14:07
sean-k-mooneywe do not bump the microversion no14:07
sean-k-mooneywe are removing the 400 error and allowign the operations to proceed14:08
gibithen I think a specless bp is OK14:08
gibiexcept if you need RPC or DB changes14:08
ignaziocassanoRalonsoh and Sean, so what I must to do for solving the issue on centos 7 train ?14:08
sean-k-mooneyack ya if i need any rpc/object/db change ill file a spec14:08
ralonsohignaziocassano, wait until neutron and nova code is merged in stable/train14:09
sean-k-mooneyignaziocassano: we need to backport the pathces. honestly though im not planning to spend to much more time workign on this. ill start some of the backport but i started trying to get this fixed in 2018 so i dont  really have the energy to keep working on this after 3 years14:10
ignaziocassanoralonsoh  Can I tary to patch the code with patch command or by hand meanwhile the code is merged ?14:14
ignaziocassanosorry : tary = try14:14
ralonsohfor sure14:14
ralonsohI'm pushing now neutron stable patches14:14
ignaziocassanook14:14
ignaziocassanothen I must enable under [nova] section in neutron.conf live_migration_events=True ?14:15
*** macz_ has joined #openstack-nova14:15
gibisean-k-mooney: ack14:16
ignaziocassanoralonsoh then I must enable under [nova] section in neutron.conf live_migration_events=True ?14:16
ralonsohyes14:17
ignaziocassanoralonsoh Ok, so I wait your push. OK ? Many thanks14:18
ignaziocassanosean-k-mooney Many thks14:19
ignaziocassanoralonsoh: when I can try yum update to see new packages ?14:21
*** iurygregory has quit IRC14:22
*** iurygregory has joined #openstack-nova14:22
*** sapd1 has joined #openstack-nova14:23
*** happyhemant has joined #openstack-nova14:24
openstackgerritStephen Finucane proposed openstack/nova master: docs: Add image metadata property reference guide  https://review.opendev.org/c/openstack/nova/+/75686714:26
openstackgerritStephen Finucane proposed openstack/nova master: docs: Add 'nova:image-meta:' directive, role  https://review.opendev.org/c/openstack/nova/+/78153014:26
openstackgerritStephen Finucane proposed openstack/nova master: docs: Add cross-references to image metadata properties  https://review.opendev.org/c/openstack/nova/+/78153114:26
openstackgerritStephen Finucane proposed openstack/nova master: db: Remove dead code  https://review.opendev.org/c/openstack/nova/+/78629114:30
openstackgerritStephen Finucane proposed openstack/nova master: db: Remove 'nova.db.sqlalchemy.utils'  https://review.opendev.org/c/openstack/nova/+/78629214:30
openstackgerritStephen Finucane proposed openstack/nova master: db: Remove unused DB methods  https://review.opendev.org/c/openstack/nova/+/78629314:30
openstackgerritStephen Finucane proposed openstack/nova master: db: Use module-level imports for sqlalchemy  https://review.opendev.org/c/openstack/nova/+/78629514:30
openstackgerritStephen Finucane proposed openstack/nova master: db: Fold in indexes  https://review.opendev.org/c/openstack/nova/+/78629614:30
openstackgerritStephen Finucane proposed openstack/nova master: db: Fold in ForeignKey constraints  https://review.opendev.org/c/openstack/nova/+/78629714:30
openstackgerritStephen Finucane proposed openstack/nova master: db: Remove 'nova.db.base' module  https://review.opendev.org/c/openstack/nova/+/78629814:30
openstackgerritStephen Finucane proposed openstack/nova master: db: Copy docs from 'nova.db.*' to 'nova.db.sqlalchemy.*'  https://review.opendev.org/c/openstack/nova/+/78629914:30
openstackgerritStephen Finucane proposed openstack/nova master: db: Synchronize function signatures  https://review.opendev.org/c/openstack/nova/+/78630014:30
openstackgerritStephen Finucane proposed openstack/nova master: db: Clean up migration code  https://review.opendev.org/c/openstack/nova/+/78630114:30
*** stephenfin has joined #openstack-nova14:34
openstackgerritArtom Lifshitz proposed openstack/nova stable/wallaby: Test SRIOV port move operations with PCI conflicts  https://review.opendev.org/c/openstack/nova/+/79071014:38
openstackgerritArtom Lifshitz proposed openstack/nova stable/wallaby: Update SRIOV port pci_slot when unshelving  https://review.opendev.org/c/openstack/nova/+/79071114:38
*** ociuhandu has quit IRC15:09
*** dave-mccowan has quit IRC15:10
openstackgerritArchit Modi proposed openstack/nova stable/wallaby: Fix typo in test_utils  https://review.opendev.org/c/openstack/nova/+/79072415:10
*** ignaziocassano has quit IRC15:11
*** dklyle has joined #openstack-nova15:14
*** dave-mccowan has joined #openstack-nova15:15
*** ociuhandu has joined #openstack-nova15:17
*** ociuhandu has quit IRC15:22
*** ociuhandu has joined #openstack-nova15:22
openstackgerritMerged openstack/nova master: Fix typo in test_utils  https://review.opendev.org/c/openstack/nova/+/79051015:25
openstackgerritTobias Urdin proposed openstack/nova master: Stop leaking ceph df cmd in RBD utils  https://review.opendev.org/c/openstack/nova/+/78937415:29
*** ignaziocassano has joined #openstack-nova15:30
ignaziocassanoralonsoh I tried to apply this patch https://review.opendev.org/c/openstack/neutron/+/766277/10/neutron/conf/common.py#177 and I configured thhe section nova in neutron.conf with live_migration_events=True but when I migrate a vm on a provider network it stops to respond to ping requests. It starts to respond only when it initiate some traffic for15:31
ignaziocassanoexample when it search the ntp server15:31
ignaziocassanoIf I logon using the console (becuse network is unreacheable) and I ping the router, it starts to respond15:32
ralonsohignaziocassano, please open a LP bug for this15:33
ralonsohmaybe we need to force a GARP to refresh the APR tables15:33
ignaziocassanoralonsoh, How can open a bug ?15:33
ralonsohhttps://bugs.launchpad.net/neutron15:34
ralonsoh--> report a bug15:34
ignaziocassanothanks15:36
sean-k-mooneyralonsoh: qemu should be sendign GARP packet or thecnically RARP packets15:36
ralonsohright15:37
ralonsohso the arp table should be updated when the VM is migrated15:37
sean-k-mooneyand for hybrid plug nova added a veth pair to ovs so the l2 agent shoudl have wired that up before we migrated15:37
ralonsoharp tables, in all hosts15:37
ralonsohright15:37
sean-k-mooneyyep15:37
sean-k-mooneywhen qemu start on the dest it will send the RARP packets15:38
sean-k-mooneyso i dont really know how ignaziocassano is having issue unless that happend after the dhcp server responded but before the l2 agent finsihed wiring up the ports15:38
sean-k-mooneyon a system with a lot of port that could happen but with your patch it should not and it shoudl be rare without it15:39
sean-k-mooneyunless the l2 agent is consitntly slow for some reason on the host15:39
ignaziocassanoI have few virtual machines on this two kvm nodes15:41
ralonsohkvm?15:42
sean-k-mooneyralonsoh: as in libvirt/kvm15:42
sean-k-mooneythem mean compute nodes15:42
ignaziocassanoyes15:42
ignaziocassanokvm nodes15:42
ignaziocassanolibvirt kvm15:42
ignaziocassanocentos 715:42
ignaziocassanoI have just tryed again now. Startded I new vm. It responds to pings. Migrated it on new node. It stops to respond. I logged into vm using the console and I pinged the default router. It started immediately to respond to ping requests15:47
sean-k-mooneyignaziocassano: can you do that again but this time use tcpdump or tshark to dump the traffic15:49
ignaziocassanoon the vm ?15:50
*** elzim has joined #openstack-nova15:50
sean-k-mooneyon the destination host15:50
ignaziocassanoummh.... How can I do that ? On which interface ?15:51
sean-k-mooneyif you log into the souce node and check the name of the tap device you can set up a watch command that will try do start dumping the packets15:52
ignaziocassanook15:52
sean-k-mooneye.g. watch -n1 " tcpudump -i tap..."15:52
sean-k-mooneybasicaly what im wondering is will you see the RARP packets form qemu and will they be recived before ovs is configured15:53
sean-k-mooneyyou coudl similarly check on teh br-ex/phsyical interface connected to ovs15:54
sean-k-mooneyto see if they are sent onto the physical network15:54
ignaziocassanoon the source node the interfcace is tap11fdfb84-4a15:57
*** lucasagomes has quit IRC15:58
ignaziocassanoso I must run watch -n1 " tcpudump -i  tap11fdfb84-4a" on the destination node ?15:58
ignaziocassanotcpdump: verbose output suppressed, use -v or -vv for full protocol decode16:01
ignaziocassanolistening on tap11fdfb84-4a, link-type EN10MB (Ethernet), capture size 262144 bytes16:01
ignaziocassano18:00:49.552314 ARP, Request who-has 10.138.209.47 (Broadcast) tell 10.138.209.1, length 4616:01
ignaziocassano18:00:49.552325 ARP, Request who-has 10.138.209.47 (Broadcast) tell 10.138.209.1, length 4616:01
ignaziocassano18:00:49.556221 ARP, Request who-has 10.138.209.48 (Broadcast) tell 10.138.209.1, length 4616:01
ignaziocassano18:00:49.556230 ARP, Request who-has 10.138.209.48 (Broadcast) tell 10.138.209.1, length 4616:01
ignaziocassano18:00:49.855902 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 2816:01
ignaziocassano18:00:50.009075 IP6 fe80::fc16:3eff:fe6b:8bee > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 2816:01
ignaziocassano18:00:50.009117 IP6 fe80::fc16:3eff:fe6b:8bee > ff02::2: ICMP6, router solicitation, length 1616:01
ignaziocassano18:00:50.265259 ARP, Reverse Request who-is fa:16:3e:6b:8b:ee (oui Unknown) tell fa:16:3e:6b:8b:ee (oui Unknown), length 4616:01
ignaziocassano18:00:50.285607 ARP, Reverse Request who-is fa:16:3e:6b:8b:ee (oui Unknown) tell fa:16:3e:6b:8b:ee (oui Unknown), length 4616:01
ignaziocassano18:00:50.293932 ARP, Request who-has 10.138.248.68 tell 10.138.248.68, length 2816:01
ignaziocassano18:00:50.294153 IP6 fe80::f816:3eff:fe6b:8bee > ff02::1: ICMP6, neighbor advertisement, tgt is fe80::f816:3eff:fe6b:8bee, length 3216:01
ignaziocassano18:00:50.344367 ARP, Request who-has 10.138.248.68 tell 10.138.248.68, length 2816:01
ignaziocassano18:00:50.344397 IP6 fe80::f816:3eff:fe6b:8bee > ff02::1: ICMP6, neighbor advertisement, tgt is fe80::f816:3eff:fe6b:8bee, length 3216:01
ignaziocassano18:00:50.435854 ARP, Reverse Request who-is fa:16:3e:6b:8b:ee (oui Unknown) tell fa:16:3e:6b:8b:ee (oui Unknown), length 4616:01
ignaziocassano18:00:50.494425 ARP, Request who-has 10.138.248.68 tell 10.138.248.68, length 2816:01
ignaziocassano18:00:50.494456 IP6 fe80::f816:3eff:fe6b:8bee > ff02::1: ICMP6, neighbor advertisement, tgt is fe80::f816:3eff:fe6b:8bee, length 3216:01
ignaziocassanothe above is on destination node16:02
sean-k-mooneyso the  Reverse Request who-is fa:16:3e:6b:8b:ee (oui Unknown) tell fa:16:3e:6b:8b:ee16:02
sean-k-mooneyi think was the RARP packet16:03
sean-k-mooneyso the question is has the ovs agent finished installing the openflow rules wehn that was sent and did tha tpacket also get sent on the physical network correnctly encapsulated16:04
*** lbragstad has quit IRC16:04
sean-k-mooneyignaziocassano: can you confirm that fa:16:3e:6b:8b:ee is the vms mac address16:05
ignaziocassanofa:16:3e:6b:8b:ee ues16:06
ignaziocassanofa:16:3e:6b:8b:ee ues16:06
sean-k-mooneyignaziocassano: by the way longer message like logs are best shared using http://paste.openstack.org/16:06
ignaziocassanofa:16:3e:6b:8b:ee yes it is16:06
sean-k-mooney:)16:06
sean-k-mooneycool so we can see that the RARP packets are sent but we need to look at the timestamp and compore that to the neutron agent logs16:06
ignaziocassanodo you want I send on paste.openstack.org the openvswitch agent log related to destination node ?16:07
*** LinPeiWen93 has quit IRC16:08
ignaziocassanosean-k-mooney which logs do you need ?16:11
ignaziocassanoI have 3 controllers and 2 compute nodes16:11
*** ociuhandu_ has joined #openstack-nova16:13
sean-k-mooneyignaziocassano: if you have a subset of the log for the time perod whne it booted say a 2-5 minute span around 18:00:4916:14
sean-k-mooneythe we coudl take a look16:15
*** jamesden_ has joined #openstack-nova16:16
*** lbragstad has joined #openstack-nova16:16
ignaziocassanoPaste #52iiZxCu2PRtXAhf318N16:17
*** ociuhandu has quit IRC16:17
ignaziocassanois the dhacpagent log16:17
*** jamesdenton has quit IRC16:17
*** ociuhandu_ has quit IRC16:18
ignaziocassanosorry16:18
ignaziocassanohttp://paste.openstack.org/show/52iiZxCu2PRtXAhf318N/16:18
sean-k-mooneycan you do the same thing for the ovs l2 agent log, actully it might be better to grep by the port uuid or tap name16:19
sean-k-mooneye.g. grep -i -E "tap11fdfb84-4a|fa:16:3e:6b:8b:ee|<port uuid>"16:20
sean-k-mooneywhat im looking for specificly is the l2 agent in debug mode logs when ports are added to ovs and when the prot is "treated"16:21
sean-k-mooneywhich means it has configured ovs to handel data form the port16:21
ignaziocassanohttp://paste.openstack.org/show/805250/16:22
sean-k-mooneyhum i guess its only logged in dbug mode i assume you dont have this in debug16:23
ignaziocassanounfortunately it is not in debug mode16:24
*** ociuhandu has joined #openstack-nova16:25
sean-k-mooneyok16:25
*** ralonsoh has quit IRC16:25
sean-k-mooneyignaziocassano: i was trying to see if any of the logs form https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L1793 would be printed but the ones i wanted i think are debug only16:26
sean-k-mooneyignaziocassano: i belive the log we were seeing before was https://github.com/openstack/neutron/blob/a12d9e41fdaf16dfefc7fe30e6198984a7588036/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L193616:26
sean-k-mooneyboth of those logs are at 18:00:52.542 and 18:00:54.54116:28
sean-k-mooneywhich is after teh RARP packets were sent16:28
ignaziocassanoSo, what can I do to help ?16:29
sean-k-mooneythat is implying you are currntly hitting the race16:29
sean-k-mooneythe last log in the dhcp agent was at  18:00:48.40016:29
sean-k-mooneyright before the vm started on the dest16:29
sean-k-mooneyignaziocassano: so it does look like if the dhcp race is fixed then it would fix your issue16:30
*** ociuhandu has quit IRC16:30
sean-k-mooneyignaziocassano: so i think we just need to wait for rodolfo to finish backporting that patch to train16:30
sean-k-mooneythis is inline whit what i would expect without https://review.opendev.org/c/openstack/neutron/+/76627716:31
ignaziocassanoOk, I did not understand if when Rodolfo will finish I can apply new code with yum update command ....16:31
sean-k-mooneywell eventually yes. after teh backport is done a new rpm will have to be build by RDO16:32
sean-k-mooneyso it will be included in the next stable releas after its backported16:32
*** dtantsur is now known as dtantsur|afk16:32
ignaziocassanoSo I will wait. I am not running for upgrading to train. The first step will be update from queens to stein in the next month.16:33
* bauzas is done for the week, wrote some reviews16:33
sean-k-mooneybauzas: ack enjoy your pto16:34
ignaziocassanoThen I will upgrade to train.16:34
bauzassee you on Monday folks, but I'll errand on my laptop tomorrow morning16:34
bauzas(I have a few specs I'd continue to look)16:34
bauzasgibi: I was terrible with both of your specs, don't judge me.16:34
bauzas:p16:34
bauzassean-k-mooney: fwiw, I'm still blocked with the mdev recreate bugfix16:35
gibibauzas: thanks for the review16:35
sean-k-mooneybauzas: did you push anything yet16:35
gibibauzas: so I guess you will be back next week16:35
ignaziocassanosean-k-mooney  I must arrive to train and then I must decide which operating system I will use on newer openstack releases16:35
bauzassean-k-mooney: I can pass the allocations, but as we only have the rp uuid, I also need to get the provider tree16:36
sean-k-mooneyi can take a look while your off otherwise ping me on monday and i can take a look with you or talke things thorugh16:36
bauzasgibi: indeed, Monday that's it16:36
*** rpittau is now known as rpittau|afk16:36
gibiOK, then we I will prepare response for Monday16:37
sean-k-mooneyignaziocassano: ok well once an upstream backport is doen it shoudl flow into the distro versions16:37
bauzassean-k-mooney: basically, I'm torn between #A : look up the allocations in the compute first and pass the inventories16:37
gibibauzas: have a nice PTO16:37
bauzas#B : somehow get a provider tree *before* we call the RT16:37
bauzasgibi: well, I'll stay at home but sure16:37
ignaziocassanosean-k-mooney many thanks for your help. Bye16:37
gibibauzas: I hope you have beers at least16:38
sean-k-mooneyb seam more complex ok lets talk about it when your back16:38
bauzasgibi: I have coronas16:38
gibilol16:38
gibiI hope you refer to the beer not the virus16:38
bauzassean-k-mooney: I'll upload something tomorrow16:38
sean-k-mooneybauzas: gibi said beer :P16:38
bauzasgibi: I'm vaccinated against both :p16:38
*** ignaziocassano has quit IRC16:38
gibi:)16:39
sean-k-mooneycorona is the beer peopel recommend to people that like cider like i do but i cant stand it16:39
bauzasI really have coronas in my fridge but I don't want to drink them :)16:39
bauzasI don't like them16:39
bauzasand I'm also vaccinated (I'm an election official for some June regional elections, so I got a priority)16:40
bauzasfirst jab16:40
bauzasnext jab on June 7th16:40
sean-k-mooneyi see good way to get peopel to volenterr to do that i guess16:40
bauzassean-k-mooney: yup, indeed, a good way for a civic volunteering16:41
bauzas(but I wasn't knowing I could get vaccinated when someone asked me to be an official :) )16:41
bauzassean-k-mooney: fwiw, I'll upload my bugfix as a WIP tomorrow morning16:42
sean-k-mooneygibi: ill follow up with infra and see if the review priority lable is sticky or not16:42
sean-k-mooneyif it is or can be made sticky across patchset ill enable that16:43
bauzassean-k-mooney: gibi: I also reviewed this (the label thingie)16:43
gibisean-k-mooney: thanks16:43
bauzasand my only concern is that I wonder why we would need to have a label if only cores use it16:43
gibibauzas: I responded yesterday to your comments16:43
gibiohh, then you responded to me16:43
bauzasgibi: and I replied today16:43
gibicool16:43
bauzasyup16:43
gibiwe as cores need to know what are the reviews we should looking at16:44
bauzasmy take is that we know we have contributors that don't use IRC for pinging us to review16:44
bauzasand in between us, we already ping us for knowing what to review16:44
gibibauzas: true, you are doing it nicely and asking time to time that is there anything you should review16:45
gibiwhich is cool16:45
sean-k-mooneygibi: ah i think its configurable in the labe definiton16:45
gibibut if anybody can set priority label then every patch will have it as everybody wants to land their patch16:46
stephenfinyeah, this ^16:46
bauzasactually the question I have is "what do we want to do by using labels ?"16:46
stephenfinif everything is a priority, nothing is16:46
bauzasthat's why I proposed a second level16:46
bauzasor this could be a second label16:46
gibiand that is why I propose to have only the second level :)16:46
bauzasI guess I need to see how this works16:47
gibiwe can do an experiment16:47
stephenfinI don't think that's necessary. I occasionally review the list of open bugs looking for things that are important. I can set the label for anything I find16:47
stephenfinor anyone else16:47
bauzasgibi: yep, hence my concerns are nitty16:47
bauzasgibi: but again, I need to understand what we would do16:47
bauzaslike, I'm seeing some changes and think those are nice for other cores16:48
bauzasthen I'll set the label to +116:48
bauzasmagically, other cores will see those changes in their dashboards16:48
bauzasand will consider signing off for reviews16:48
bauzasso, the label is just a signal to the other cores ?16:49
bauzasor,16:49
bauzasthe other way16:49
bauzassomeone pings me on IRC begging for reviews16:49
bauzasi don't have time now but I want to review such16:49
gibiit is signal for other cores that this patch seems to be ready and important. And it is signal for the author to expect incoming reviews16:49
bauzasso I'd tag the change for later16:49
gibibauzas: your second use case already covered by starring a review16:49
bauzasgibi: right, I know16:50
bauzasgibi: okay, then the first usecase I mentioned, which I honestly think won't help16:50
bauzasbecause we assume the signal isn't lost16:50
gibieven if we look at the marked review on the weekly16:50
gibi?16:50
bauzasand we assume the cores will commit to it, whatever their respective bandwidthes are16:51
bauzasgibi: the only benefit I see honestly is the weekly meeting16:51
bauzasgibi: because we already signal important changes we care by other means, like pings16:52
gibiright. I consider adding +1 priority only to a patch when I commit to review it within a week or even less16:52
bauzasok, so the signal is different16:52
bauzasyou're not sending a signal that's "cores, please review"16:53
bauzasbut rather a signal saying "I have free time to this change and I commit to it"16:53
bauzasthat's not an actional item for others then, it's an actional item for the core16:53
bauzas(which is better than now, agreed=16:54
gibimy runway experience was that thing in the slot did not get review bandwidht because we missed the commitment part16:54
bauzasagreed16:54
bauzas100% to it16:54
bauzasbut I think I wasn't clear about the use of this new label16:54
bauzasand i also think the change isn't explaining how we'll use it16:55
bauzasif it's a label for me committing to a change, then OK16:55
bauzasthat being said, ones could tell we can just use gerrit CCs16:56
sean-k-mooneygibi: bauzas  so just asked fungi , the review priorty lable is not defiend globlly so we can define it as we want for nova and we can make it sticky yes16:56
fungiyeah, look at cinder's acl for an example16:56
bauzasI'm not debating over the label itself16:56
sean-k-mooneyhttps://opendev.org/openstack/project-config/src/branch/master/gerrit/acls/openstack/cinder.config#L25-L3516:56
bauzasI'm more concerned by the solely usage we, as nova contributors, will make of it16:56
gibibauzas: point taken. I need to write the procee up in a patch to the intree contributor doc16:56
sean-k-mooneybauzas: sure just confirm ing we can customise it to have the behavior we desire16:57
bauzasgibi: one last thing before I stop16:57
gibibauzas: I wanted to start the discussion before I do that. Now I think I got enough input from you to do it16:57
bauzasgibi: I'm not sure we need to restrict such label to the cores16:57
bauzasif it's a signal about committing to review16:57
bauzasthis could also be a way for attracting people to the vows of review16:58
gibigood point16:58
sean-k-mooneywell if you look at cinders usage its quite interesting16:58
sean-k-mooneyvalue = -1 Branch Freeze16:58
sean-k-mooneyvalue = 0 No Priority16:58
sean-k-mooneyvalue = +1 Important Change16:58
sean-k-mooneyvalue = +2 Gate Blocker Fix / Urgent Change16:58
bauzassean-k-mooney: that's very different from what gibi was suggesting16:59
sean-k-mooneythey have it resticted to the core group16:59
fungii have to agree, restricting access because of a fear of abuse is a premature optimization which can stifle involvement from newcomers. i recommend only restricting it if actual abuse is observed and is otherwise uncontrollable16:59
sean-k-mooneybauzas: it is which is why i was highigly a different usage patteren16:59
bauzassounds like we have a debate :)17:00
bauzassean-k-mooney: just before you came back, I was exposing to gibi the fact that I don't think the signal is useful if it's just a ask for cores to review17:00
sean-k-mooneyfungi: wel part of the idea was to use it to replace oru old runway proces where anyone could add something to the queue but only core move thing into the runway slots17:00
bauzassean-k-mooney: and gibi told me the crux of the idea was "commitment"17:01
sean-k-mooneybauzas: yes that is why it was going to be restrited to cores to set17:01
fungimaybe look at it as being similar to bug triage. do you restrict who can set the severity on bug reports?17:01
bauzassean-k-mooney: the problem is that we had a process with runways which didn't really work because of the lack of commitment17:01
bauzasfungi: nope17:01
sean-k-mooneyfungi: its an open team but ithink the motivates are different17:01
sean-k-mooneybauzas: well not entirly17:02
bauzassean-k-mooney: if we're creating labels for marking changes for reviews, we'll just recreate the runway process but gerrit driven this time17:02
bauzaswhich honestly didn't greatly work17:02
sean-k-mooneybauzas: partly17:02
bauzasgibi: sean-k-mooney: here is what I'm proposing17:02
* gibi listens but pretty out of steam already today17:03
bauzaswe should Depend-On the ACL change to some new change in the contribs docs17:03
bauzasthat would explain the process17:03
bauzasb/c the acl change is just implementation17:03
bauzasbut we miss the design phase17:04
sean-k-mooneysure no issue with that17:04
fungibut yes, if the goal is to only ever have x number of "priority" flagged reviews, and you expect to have a limited number of people with the necessary perspective to decide which those are, then restricting the label might be a way of avoiding problems with coordination. it all depends on how you expect to use that signal17:04
gibibauzas: I agree17:04
bauzasgibi: take a break and just commit yourself about describing your ideal view on what should be the process for those labels in a separate change17:04
gibibauzas: and I sign up to write the proposal17:04
bauzascool17:04
bauzasI'm way more interested in debating over this change rather than the gerrit one :p17:05
gibithank you all for the input I really appreciate it17:05
bauzasnp, and it's late and I'm thristy typing17:05
* bauzas will avoid the coronas and just use his keg again17:06
sean-k-mooneybauzas: i will happily try and translate what ever ye decied into gerrit17:06
bauzassean-k-mooney: thanks17:06
bauzasfolks, should be around unofficially tomorrow morning17:06
bauzas++17:06
*** elzim has quit IRC17:07
*** andrewbonney has quit IRC17:07
gibibauzas: o/.17:08
*** elzim has joined #openstack-nova17:15
*** sapd1 has quit IRC17:17
*** dklyle has quit IRC17:26
*** dklyle has joined #openstack-nova17:27
*** lpetrut has joined #openstack-nova17:55
*** lpetrut has quit IRC17:57
*** happyhemant has quit IRC18:23
*** whoami-rajat_ has joined #openstack-nova18:33
*** vishalmanchanda has quit IRC18:34
*** gyee has joined #openstack-nova18:45
*** hamalq has joined #openstack-nova18:50
*** yoctozepto has quit IRC19:13
*** yoctozepto6 has joined #openstack-nova19:14
*** links has quit IRC19:29
*** elzim has quit IRC20:07
*** hamalq has quit IRC20:09
*** macz_ has quit IRC20:09
*** rpioso has quit IRC20:09
*** erbarr has quit IRC20:11
*** hack-char has quit IRC20:12
*** hack-char has joined #openstack-nova20:12
*** hamalq has joined #openstack-nova20:13
*** macz_ has joined #openstack-nova20:13
*** rpioso has joined #openstack-nova20:13
*** erbarr has joined #openstack-nova20:13
*** damiandabrowski has quit IRC20:16
melwittdansmith: I noticed you reviewed the rbd error sanitize patch earlier today, it depends on this one below it that re-enables the rbd unit tests, if you wanted to hit that too https://review.opendev.org/c/openstack/nova/+/79051120:28
dansmithoh sorry20:40
dansmithI actually had that one open too and then just didn't look at it20:40
*** avolkov has quit IRC20:41
melwittthanks :)20:42
*** avolkov has joined #openstack-nova20:47
lyarwood*facepalm* sorry about that melwitt21:00
melwittnp lyarwood21:01
amodiStable branch requires either cherry-pick -x headers or [stable-only] tag!21:02
amodihttps://review.opendev.org/c/openstack/nova/+/790724 can i not cherry=pick from gerrit ui?21:02
amodiwhat did i miss21:02
openstackgerritMerged openstack/nova master: rbd: Get rbd_utils unit tests running again  https://review.opendev.org/c/openstack/nova/+/79051121:03
melwittamodi: the gerrit ui only does the needed "cherry-pick -x" after the change you want to backport has merged. if you do the cherry pick in the ui before it merges, it will miss the -x option to cherry-pick21:04
amodimelwitt: ohh, ok so i guess i need to abandon this and re-cherry-pick it? now that the change has merged21:05
melwittamodi: I'm not sure if there's a way to re-kick it from the ui perspective. you could try it but I'm not sure if that will work. usually we just do an edit to the commit message to add the line manually if this happens21:06
amodii want to try with ui itself, one sec21:06
openstackgerritmelanie witt proposed openstack/nova stable/wallaby: rbd: Get rbd_utils unit tests running again  https://review.opendev.org/c/openstack/nova/+/79083621:07
openstackgerritArchit Modi proposed openstack/nova stable/wallaby: Fix typo in test_utils  https://review.opendev.org/c/openstack/nova/+/79072421:07
amodimelwitt: yeah looks like it re-kicked it correctly, https://review.opendev.org/c/openstack/nova/+/79072421:08
amodithanks!!21:08
melwittkewl21:08
*** slaweq has quit IRC21:19
*** hack-char has quit IRC21:40
*** hack-char has joined #openstack-nova21:40
*** rcernin has joined #openstack-nova22:05
*** mkrai has quit IRC22:24
*** rcernin has quit IRC22:27
*** rcernin has joined #openstack-nova23:02
*** dave-mccowan has quit IRC23:02
*** rcernin has quit IRC23:02
*** rcernin has joined #openstack-nova23:02
*** whoami-rajat_ is now known as whoami-rajat23:05
*** macz_ has quit IRC23:17
*** tosky has quit IRC23:24
*** ebbex has quit IRC23:31
*** zzzeek has quit IRC23:34
*** zzzeek has joined #openstack-nova23:35
*** mlavalle has quit IRC23:44
*** ebbex has joined #openstack-nova23:51

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