Earlier  
Posted Nick Remark
#openstack-nova - 2021-11-09
17:53:19 sean-k-mooney the curernt host appears to be compute0
17:55:31 sean-k-mooney the revision_number 23->24 update is fefintly going form bound to compute0 with status down to compute0 with status up
17:56:30 sean-k-mooney which corralates with the 21->22 detail above
17:56:52 sean-k-mooney it looks like the issue is else where perhaps in the the dhcp agent or neutorn server
17:57:22 sean-k-mooney kevko: for the event to be sent both the l2 agnet and dhcp agent need to notify the neutron server that the provisioning is complete
17:58:22 sean-k-mooney since the l2 agent seams to be working correctly the next most likely candiate is the dhcp agent being slow whne many vms are created
17:58:36 kevko 6 vms ? :/
18:01:16 sean-k-mooney its likely that there is a bug in the configutaion that is cause the agent to block/hang for some reason if this is the issue
18:01:36 sean-k-mooney its not really a perfroamce issue
18:01:54 sean-k-mooney we have had bugs in the interactio nwith dnsmasque in the past
18:02:33 sean-k-mooney kevko: in any case when the l2 agent set the port status as active it execution this code which mare it complete for the l2 agent
18:02:35 sean-k-mooney https://github.com/openstack/neutron/blob/9241c76b04e6745cc648ee42037cfe6ddad3600a/neutron/plugins/ml2/rpc.py#L312-L331
18:02:50 sean-k-mooney if both sides had complted the provision the event would have been sent
18:03:45 kevko bug in configuration ?
18:04:08 kevko yeah, i saws some fixed bugs on launchpad
18:05:35 sean-k-mooney in the neutron server you should see one of these two logs notign that the l2 agent has complted its provisioning https://github.com/openstack/neutron/blob/9241c76b04e6745cc648ee42037cfe6ddad3600a/neutron/db/provisioning_blocks.py#L133-L140
18:10:37 kevko sean-k-mooney: nothing, i have wallaby btw
18:11:30 sean-k-mooney i dont think this has changed much form wallaby to master
18:12:09 sean-k-mooney it might be best to take this to then neutron channel butit would seam for whateer reason that the port status chagne is not propagating to the nutron server then
18:12:44 kevko do you want ssh key to that lab ?
18:13:27 sean-k-mooney unfortunetly i have some other work i need to get done so im not sure i can really supprot debuging this much beyond what i have already done
18:14:20 kevko sean-k-mooney: ok, no problem, thank you very much ...
18:14:41 kevko btw, I have neutron server set to Debug = False ..so that's the reason why I am not seeing that debug messages ..
18:15:04 sean-k-mooney ah ya these are debug only since its a bit verbose
18:16:06 kevko ok, have to go ...thank you very much
20:16:21 opendevreview Artom Lifshitz proposed openstack/nova master: DNM: Run OVS job with hybrid plug https://review.opendev.org/c/openstack/nova/+/817303
20:18:47 opendevreview Artom Lifshitz proposed openstack/nova master: DNM: Run OVS job with hybrid plug https://review.opendev.org/c/openstack/nova/+/817303
20:26:20 opendevreview Dan Smith proposed openstack/nova master: WIP: Revert project-specific APIs for servers https://review.opendev.org/c/openstack/nova/+/816206
20:26:42 dansmith gmann: lbragstad: my brain is fried from ^ so use extra caution while reviewing
20:27:06 dansmith however, I do think that's much easier to read than what was there before, and hopefully makes the iteration from current..scope..nolegacy more clear
20:35:12 gmann dansmith: thanks, ack
20:45:40 lbragstad dansmith sweet - thanks
21:06:22 hyang[m] Hi there, can someone help to review https://review.opendev.org/c/openstack/nova/+/811521? It can help to close both https://bugs.launchpad.net/nova/+bug/1943969 and https://bugs.launchpad.net/neutron/+bug/1942615
22:14:57 artom Hah, so revert resize is broken with ovs + hybrid plug
22:15:01 artom https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_f60/817303/2/check/nova-ovs-hybrid-plug/f60d54c/testr_results.html
22:15:13 artom We first noticed this downstream, and now that ^^ tested it upstream, same result
22:19:18 gmann dansmith: lbragstad johnthetubaguy[m] I created this wikitable to audit all the nova API policy - https://wiki.openstack.org/wiki/Nova/rbac
22:20:20 gmann few I have kept as ? mainly multi-policy one. for example showing host_status policy in GET /servers please review those.
22:24:38 gmann dansmith: lbragstad johnthetubaguy[m] I have updated those as per my understanding and with new direction we agreed on Wed. My eyes are paining now after listing/auditing these ~225 policies . will catch up on this tomorrow.
22:32:09 dansmith gmann: wow, I thought you were going to do it in a google sheet or something
22:32:23 dansmith I'm sure your eyes are literally bleeding now :/
#openstack-nova - 2021-11-10
02:19:15 opendevreview Wenping Song proposed openstack/nova master: Fill the AcceleratorRequestBindingFailed exception msg info https://review.opendev.org/c/openstack/nova/+/817326
02:52:28 opendevreview Wenping Song proposed openstack/nova master: Fill the AcceleratorRequestBindingFailed exception msg info https://review.opendev.org/c/openstack/nova/+/817326
09:09:22 opendevreview likui proposed openstack/osc-placement master: Replace deprecated assertRaisesRegexp https://review.opendev.org/c/openstack/osc-placement/+/817365
09:52:04 stephenfin lyarwood: the py36 tox environment is failing for me locally (F34). I proposed this to fix it https://github.com/powervm/pypowervm/pull/17
09:53:18 stephenfin We'll need that to merge and a new release of pypowervm be cut before we can get things running again. I suspect we're not seeing issues in the gate yet because an older dependency resolver that doesn't care about these things is being used there
09:53:26 stephenfin Just FYI since you're also using Fedora :)
10:07:46 gibi elodilles, lyarwood: hi! re: kernel panic in stable/victoria with volume detach: https://bugs.launchpad.net/nova/+bug/1950310 yesterday I backported the libvirt event based detach series to victoria but top of that series the kernel panic still happens (links in the bug for the recent failures)
10:08:02 gibi I'm out of ideas now
10:24:44 sean-k-mooney[m] gibi i could maybe try to revive my attempts to add support for alpine to dib so that we could use it instead of cirros
10:25:33 sean-k-mooney[m] i started that orignally due to kernel bugs in the cirros kernel
10:26:27 gibi sean-k-mooney[m]: I'm not sure if it is really cirros. i) it happens with both cirros 0.5.1 and 0.5.2 but it does not happen on master just on stable/victoria
10:26:42 gibi s/i)//
10:26:52 sean-k-mooney[m] i see
10:27:52 sean-k-mooney[m] if its still happening with you event based detach patch the only other thing i can think of is changing the qemu version we are using
10:29:11 sean-k-mooney[m] i used to maintain a devstack plugin to compile qemu form git but i have not updated it to support the mason build systme wich they now use. we could try changing the qemu we use either via a ppa or compiling it
10:29:16 gibi hm interesting, I don't know how different the qemu version between master and stable/victoria but I can check that
10:29:40 sean-k-mooney[m] master would be focal is stable victoria on bionic?
10:33:14 frickler gibi: sean-k-mooney[m]: if you want newer qemu, could you try running on bullseye instead ubuntu?
10:34:53 sean-k-mooney[m] frickler: bullseye and centos would be options. its not really about newer it could be older. if the panics are caused by a kvm or qemu bug then just using a diffent disto with different verions might fix the problem
10:36:06 lyarwood gibi: yeah I didn't think it would help tbh, you're still firing device_del down to QEMU and the ACPI requests to the guestOS, are we pinning tempest on stable/victoria? There was an effort recently to force tempest to wait until the guestOS was up before attaching and detaching volumes, I wonder if that logic is there?
10:36:43 lyarwood gibi: I've had my head downstream on something since yesterday but I'll try to help out some more for the rest of the week
10:37:27 sean-k-mooney[m] you mean adding the validation so that we ssh into the vm before atching/detaching
10:37:33 sean-k-mooney[m] or something else
10:37:55 lyarwood sean-k-mooney: yeah that's it
10:38:09 lyarwood stephenfin: ack not seen that personally but will keep it in mind
10:39:02 sean-k-mooney[m] lyarwood has anyone submited patches for that
10:39:20 lyarwood I had thought it already landed in master tbh
10:41:01 lyarwood okay no it hasn't
10:41:25 lyarwood I was sure I saw a change land for this or maybe my dreams are really becoming boring now I'm half way through my 30's
10:42:45 sean-k-mooney[m] we spoke about it in out inernal meeting last week but unless you wrote it i dont think it happened.
10:43:19 sean-k-mooney[m] if i remember correctly we just need to set validation=true on the create server line in the test
11:30:33 gibi lyarwood: do you have a link for the patch that adds that validation? I can add a depends-on somewhere in nova to see if that helps
12:10:10 lyarwood gibi: no sorry I couldn't find it, I was sure I saw something in the scenario manager for attempted to do it, I'll look again after lunch and throw something up on gerrit if I can't find it
12:11:38 gibi ack thanks
13:33:40 opendevreview Balazs Gibizer proposed openstack/nova stable/xena: Define new functional test tox env for placement gate to run https://review.opendev.org/c/openstack/nova/+/817256
13:35:05 opendevreview Balazs Gibizer proposed openstack/placement stable/xena: Use 'functional-without-sample-db-tests' tox env for placement nova job https://review.opendev.org/c/openstack/placement/+/817255
13:35:44 gibi gmann: ^^ added the missing cherry-pick lines in these ^^
14:25:39 gmann gibi: thanks
15:05:11 opendevreview Balazs Gibizer proposed openstack/nova stable/xena: Fix interference in db unit test https://review.opendev.org/c/openstack/nova/+/817240
15:25:57 opendevreview Stephen Finucane proposed openstack/nova master: Use unittest.mock instead of third party mock https://review.opendev.org/c/openstack/nova/+/714676
15:43:34 lyarwood Just when you thought the nova codebase was safe from stephenfin ;)
15:44:09 lyarwood Can we give you the Friday nick of SirChangeALot?
15:44:20 stephenfin someone complained about us still using it recently. blame that person
15:44:28 stephenfin whose name I can't remember
15:44:36 lyarwood ^_^
15:44:43 lyarwood I'll queue that up later in the week
15:44:57 dasm "it's them, not us" :)
15:49:24 sean-k-mooney lyarwood: for what its worth its really pretty tirvial
15:49:45 lyarwood yeah I know I was only jesting
15:49:54 sean-k-mooney most of it was find replace and one or two other changes which are ease to fined by the change size beside the file
15:50:20 sean-k-mooney it made me sad you cant sort the list of files in the gerrit review by changed lines
15:50:32 sean-k-mooney it would be a nice feature for that type of change
15:53:01 EugenMayer holds that data
15:53:01 EugenMayer Ah nova backup process was queued, but it was queue since i had not enough space. I removed the queued images in the ui (glance images), but now instances show up a task `image backup` and i cannot see how to remove it. Is that a nove tasks i can list (cannot find anything with the nova cli) or is that rather a glance task? A little confused who
15:54:43 EugenMayer `glance task-list` does not show up those tassks
16:00:40 EugenMayer is `nova reset-state --active` the way to solve this
16:41:05 opendevreview Alexey Stupnikov proposed openstack/nova master: Test aborting queued live migration https://review.opendev.org/c/openstack/nova/+/776250
17:37:13 sean-k-mooney gibi: good to see the neutron sepc is apporved ill try to rereview https://review.opendev.org/c/openstack/nova-specs/+/787458 this week but i belive its largely the same as v9 and i was ok with the overall design a that point.
17:37:53 sean-k-mooney by the way when was/is the spec review day

Earlier   Later