Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-04-22
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.
23:39:55 sean-k-mooney i was expecting concurancy 1 to take maybe 3 hours with current tests set but 5+ is stupidly slow. ill let this finish and go back to the smaller test set. we can always add more after if there are specific test that make sense
23:40:06 sean-k-mooney anyway goodnight o/
23:43:28 mriedem yes just start with scenario tests in --serial or --concurrency=2 if you can
23:44:35 sean-k-mooney concurrency=2 was ocationally resulting in no valid host errors
23:45:04 sean-k-mooney pinning disable over subsription so its easy to end up running out for free cores
#openstack-nova - 2019-04-23
00:59:12 openstackgerrit Takashi NATSUME proposed openstack/python-novaclient master: Fix a description for config_drive parameter https://review.opendev.org/653683
01:14:13 openstackgerrit ya.wang proposed openstack/nova-specs master: Expose auto converge and post copy https://review.opendev.org/651681
01:20:45 openstackgerrit Takashi NATSUME proposed openstack/python-novaclient master: Updates for OpenDev transition https://review.opendev.org/654429
01:49:16 mnaser shopping an idea
01:49:22 mnaser how do you feel about killing devstack.
01:49:43 mnaser and replacing it by a deployment tool
02:08:19 openstackgerrit zhongshengping proposed openstack/nova master: Replace git.openstack.org URLs with opendev.org URLs https://review.opendev.org/654398
02:40:22 lbragstad efried get it figured out?
02:41:48 lbragstad efried as far as i know, the duplicated sessions were completely removed from the schedule
02:43:06 lbragstad https://www.openstack.org/summit/denver-2019/summit-schedule/events/23642/increasing-api-accessibility-with-granular-policy-and-default-roles is the one i have on my schedule
04:15:35 openstackgerrit Erik Olof Gunnar Andersson proposed openstack/nova master: Pass on region when we don't have a valid ironic endpoint https://review.opendev.org/654692
04:16:25 openstackgerrit Merged openstack/nova stable/rocky: libvirt: set device address tag only if setting disk unit https://review.opendev.org/653511
04:16:55 eandersson efried, ^ we could honestly just pass on the region, since region_name is only actually consumed if endpoint or session is missing.
04:17:06 eandersson But I am fine just passing it on when we don't have an endpoint.
07:37:47 openstackgerrit Boxiang Zhu proposed openstack/python-novaclient master: Add host and hypervisor_hostname to create servers https://review.opendev.org/647671
07:52:02 kashyap efried: Was on PTO yesterday. Just saw the scroll. I will address yours and mriedem's questions on that "CPU selection..." spec.
07:54:09 kashyap efried: I tried to be conscious to "not assume anything", _still_ my phrasing seems to be not sufficiently clear enough. Will rework.
07:55:58 sean-k-mooney kashyap: i think the issue is you assumed people understand and follow libvirt and did not present the usecase in terms of nova but instead present it as libvirt has this new api we shoudl use it with the assumtion people knew what libvirt api we currently use and what features it is used for
07:56:31 kashyap sean-k-mooney: I partly disagree. I didn't "assume" it that way.
07:56:49 kashyap How much more clearer can you phrase this:
07:56:52 kashyap [quote]
07:57:20 kashyap [/quote]

Earlier   Later