Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-04-22
20:15:30 openstack bug 1825537 in OpenStack Compute (nova) "finish_resize failures incorrectly revert allocations" [Medium,In progress] https://launchpad.net/bugs/1825537 - Assigned to Matt Riedemann (mriedem)
20:15:34 sean-k-mooney it looked resonable to me at first glance but just said i woudl ask
20:15:58 mriedem sean-k-mooney: yes
20:16:20 mriedem there was a regression introduced
20:16:39 sean-k-mooney oh im glad i asked :)
20:16:50 mriedem for $5 i'll tell you the secret
20:17:54 mriedem https://review.opendev.org/#/q/I6fc7108817fcd9df4a342c9dabbf14ab7911d06a
20:18:00 sean-k-mooney https://bugs.launchpad.net/charm-nova-compute/+bug/1671422?
20:18:01 openstack Launchpad bug 1671422 in OpenStack nova-compute charm "charms: nova/cinder/ceph rbd integration broken on Ocata" [Critical,Fix released] - Assigned to James Page (james-page)
20:18:08 mriedem that might be the other one
20:18:37 mriedem https://review.opendev.org/#/q/Ieba216275c07ab16414065ee47e66915e9e9477d
20:19:01 sean-k-mooney ok so it did not handel olde connection info. so if we are to backprot it we need to backport the fixes for the regression too
20:19:35 mriedem sure
20:19:48 mriedem or just tell the bank to upgrade
20:20:16 sean-k-mooney i mean if i could i would but...
20:20:44 sean-k-mooney that said depending on how invasive the other fixes are that might be answer
20:23:28 sean-k-mooney huh the last one was only fixed recently in the grand scheme fo things
20:41:44 efried sean-k-mooney: I can see whitelist/alias stuff in the nova.confZ
20:42:04 efried pci_passthrough_whitelist = [{"vendor_id":"8086","product_id":"1520"}]
20:42:05 efried pci_alias = {"name":"pci_network_card","vendor_id":"8086","product_id":"1520"}
20:42:23 efried Presumably that does no good without a flavor requesting something at that alias?
20:42:51 efried well, I mean, I guess it at least proves that the parts of the pci subsystem that parse those and generate the list of legal devices don't explode.
20:43:58 efried Do you have any idea where a guy could find the script that's running the show here?
20:47:00 sean-k-mooney correct
20:47:21 sean-k-mooney unless the flavor request the alaise it does not do anything
20:47:41 sean-k-mooney for the device to be useable for neutron the physnet would have to be set in the whitelist
20:48:21 sean-k-mooney they could be using a local.conf like i am. my guess would be it burried in a jenkins job somewhere
20:48:33 efried that's what I figured
20:48:47 efried I also really, really don't want to get too deeply involved here.
20:48:59 sean-k-mooney ha to late :P
20:49:04 efried I recognize it's a Learning Opportunity
20:49:25 sean-k-mooney well its being converted to zull v3 right
20:49:26 efried but if I go start debugging the CI, my life is over.
20:49:29 efried yes, afaik
20:49:51 sean-k-mooney so i woudl ignore how its currently running
20:50:02 sean-k-mooney and plan for how it will run
20:50:07 efried I sort of get the impression that there was someone competent doing all the work here, and then whoever that is left the company.
20:50:58 efried And those left behind are scrambling to figure out wtf is going on.
20:51:17 sean-k-mooney well yes but that happened liek 2 years ago :P
20:51:23 efried oh
20:51:34 sean-k-mooney actully the pci ci was always different
20:51:46 efried well, I know it would take *me* at least two years to figure out how this stuff works...
20:52:01 sean-k-mooney but the nfv ci was run by me an waldek but he left to joing redhat 2 years ago
20:52:48 sean-k-mooney the pci ci was run by a team of 1 person out of the PRC site but they had other respociblityes
20:53:05 efried different topic: "completing numa affinity polices for neutron sriov interfaces." <== on the PTG agenda. What's the status of this? Bullet says you were going to write a spec or something?
20:53:26 sean-k-mooney ya basically what i want to get out of that topic it the direct
20:53:36 sean-k-mooney i could just repopose the old spec
20:53:51 sean-k-mooney which say use a flavor/image property to specify the policy
20:54:02 sean-k-mooney or i could pass the policy via a neutron port
20:54:11 efried is there any in-person design work needed?
20:54:13 sean-k-mooney as this is numa affinty for neutron interfaces
20:54:43 sean-k-mooney well it will need a spec in either case the quest is nova or neutron
20:55:16 sean-k-mooney i also want to expand it to all neutron ports not just sriov to pick up the numa awrere vswitch work stephenfin did
20:55:27 efried Not understanding the subject, it sounds like you need to a) put things into a port def (neutron), and then b) process them into affinity thingies (nova)
20:56:07 sean-k-mooney yes but the question is where is the policy for the numa afinity expressed
20:56:17 sean-k-mooney per neutron port? or in the flavor/image
20:56:41 efried Even if it's on the port, would the neutron side require any actual code change, or is it just stuffing whatever into the already-garbage-in-garbage-out binding profile dict?
20:57:06 sean-k-mooney binding profile is admin only
20:57:24 sean-k-mooney so that is one of the questions use binding profile or add it as a new qos policy
20:57:45 efried Is this something to discuss in the nova/neutron xproj?
20:58:04 efried oh look
20:58:04 sean-k-mooney well that is why i addeed it there
20:58:08 efried it's already in there
20:58:11 sean-k-mooney is it also in the main nova one
20:58:15 efried so can I nix it from the main nova one?
20:58:15 sean-k-mooney if so kill the nova one
20:58:22 sean-k-mooney ya
20:58:24 efried cool
20:59:03 sean-k-mooney sorry that was added before the cross project etherpad i forgot to kill it when i move it over
21:00:01 efried yeah, that's cool, I'm just desperately trying to figure out how to schedule everything, and my first look is always going to be, "can we get rid of this??"
21:00:31 sean-k-mooney im debating if we should drop one of the other topic i have in the xproj doc
21:03:25 sean-k-mooney i have moved https://review.opendev.org/#/c/645173/ down in the xprojc etherpad by one as i think its something we shoudl discuss but im not sure ill have time to work on it. that said it might still be good to start the neutron work
21:13:33 efried jaypipes: Would you please put https://review.opendev.org/#/c/641994/ (AMD SEV reproposal) on your radar for review? There has been a nontrivial change of direction: namely making SEV contexts a quantifiable resource and therefore a resource class.
21:17:17 openstackgerrit Merged openstack/nova-specs master: Tools & docs for backlog & abandoned spec process https://review.opendev.org/648800
21:44:45 jaypipes efried: yessir.
21:44:51 efried thankyousir
21:45:49 jaypipes npsir
22:06:15 efried mriedem: https://review.opendev.org/#/c/645316/ is related to https://bugs.launchpad.net/nova/+bug/1817927 yah?
22:06:16 openstack Launchpad bug 1817927 in OpenStack Compute (nova) "device tagging support is not checked during move operations" [Undecided,New]
22:58:45 openstackgerrit Michael Still proposed openstack/nova master: Remove fake_libvirt_utils from snapshot tests. https://review.opendev.org/642558
22:58:45 openstackgerrit Michael Still proposed openstack/nova master: Remove fake_libvirt_utils from connection tests. https://review.opendev.org/642557
22:58:46 openstackgerrit Michael Still proposed openstack/nova master: Remove fake_libvirt_utils from libvirt imagebackend tests. https://review.opendev.org/643895
22:58:46 openstackgerrit Michael Still proposed openstack/nova master: Remove fake_libvirt_utils from virt driver tests. https://review.opendev.org/643894
22:58:47 openstackgerrit Michael Still proposed openstack/nova master: Remove fake_libvirt_utils users in functional testing. https://review.opendev.org/644793
22:58:47 openstackgerrit Michael Still proposed openstack/nova master: Remove remaining vestiges of fake_libvirt_utils from unit tests. https://review.opendev.org/643896
23:13:31 openstackgerrit Ghanshyam Mann proposed openstack/os-traits master: Dropping the py35 testing https://review.opendev.org/654651
23:16:39 openstackgerrit Ghanshyam Mann proposed openstack/os-resource-classes master: Dropping the py35 testing https://review.opendev.org/654653
23:18:31 openstackgerrit Merged openstack/nova stable/queens: Fix legacy-grenade-dsvm-neutron-multinode-live-migration https://review.opendev.org/640197
23:24:22 mriedem efried: yeah somewhat
23:24:44 mriedem tonyb[m]: can you get this queens backport? https://review.opendev.org/#/c/640198/2
23:27:01 mriedem efried: unfortunately because i changed nova/test.py in https://review.opendev.org/#/c/654468/ it runs a full tempest run and all so i'm sitting in the check queue for 3.5 hours waiting to see if that makes any difference in the output
23:31:08 mriedem maybe i can speed that up
23:31:20 openstackgerrit Matt Riedemann proposed openstack/nova master: DNM: debug config opts infinite recursion https://review.opendev.org/654468
23:32:37 sean-k-mooney mriedem: so.... if i just run the compute and networking senario test and dont run all the api test in the nfv job do you think that is enough?
23:32:59 sean-k-mooney run with concurancy 1 is... slow
23:33:35 mriedem sean-k-mooney: those don't test nfv things do they? or are you making the ports sriov ports or something?
23:34:15 sean-k-mooney im using flavors that enable hugepage pinning realtime eumlator thread polices a cpu topolgies
23:34:49 sean-k-mooney i can also add custom tests but i wanted a baseline of tests we know work as a base and add to it if needed.
23:36:10 sean-k-mooney but ya its still rung the tests but the job has been running for a little over 5 hours and 20 minutes. if i just run the senario test that will drop back to about an hour
23:37:02 sean-k-mooney its multinode so the senario test will also chack migrations/resize.

Earlier   Later