Monday, 2019-04-22

*** tetsuro has joined #openstack-nova00:20
*** whoami-rajat has quit IRC00:22
*** lbragstad has joined #openstack-nova00:42
*** d34dh0r53 has quit IRC01:09
*** yedongcan has joined #openstack-nova01:26
*** ileixe has joined #openstack-nova01:55
*** ircuser-1 has joined #openstack-nova02:03
openstackgerritBoxiang Zhu proposed openstack/nova master: Add host and hypervisor_hostname flag to create server  https://review.opendev.org/64552002:21
*** lbragstad has quit IRC02:46
*** d34dh0r53 has joined #openstack-nova02:46
openstackgerritTushar Patil proposed openstack/nova-specs master: Allow compute nodes to use DISK_GB from shared storage RP  https://review.opendev.org/65018802:54
*** yedongcan has quit IRC03:14
*** yedongcan has joined #openstack-nova03:14
*** psachin has joined #openstack-nova03:22
*** ileixe has quit IRC03:30
*** ileixe has joined #openstack-nova03:34
*** udesale has joined #openstack-nova03:56
*** yonglihe has quit IRC04:04
*** takashin has joined #openstack-nova04:18
*** ileixe has quit IRC04:37
*** ricolin has joined #openstack-nova04:38
*** ileixe has joined #openstack-nova04:42
*** tonyb has joined #openstack-nova04:46
*** ratailor has joined #openstack-nova05:07
openstackgerritBoxiang Zhu proposed openstack/nova master: Add host and hypervisor_hostname flag to create server  https://review.opendev.org/64552005:18
openstackgerritMerged openstack/nova stable/pike: Update instance.availability_zone during live migration  https://review.opendev.org/64763005:25
openstackgerritMerged openstack/nova stable/pike: Add functional recreate test for bug 1819963  https://review.opendev.org/64842105:25
openstackbug 1819963 in OpenStack Compute (nova) pike "Reverting a resize does not update the instance.availability_zone value to the source az" [Medium,In progress] https://launchpad.net/bugs/1819963 - Assigned to Matt Riedemann (mriedem)05:25
openstackgerritMerged openstack/nova stable/pike: Update instance.availability_zone on revertResize  https://review.opendev.org/64842205:25
openstackgerritMerged openstack/nova stable/pike: Add missing libvirt exception during device detach  https://review.opendev.org/65164205:25
openstackgerritMerged openstack/nova stable/queens: Fix incomplete instance data returned after build failure  https://review.opendev.org/64791305:25
*** sridharg has joined #openstack-nova05:34
*** cfriesen has quit IRC05:35
*** tonyb has quit IRC06:13
*** tonyb has joined #openstack-nova06:14
*** ccamacho has joined #openstack-nova06:58
*** alex_xu has joined #openstack-nova07:14
*** ralonsoh has joined #openstack-nova07:16
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (8)  https://review.opendev.org/57531107:17
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (8)  https://review.opendev.org/57531107:17
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (9)  https://review.opendev.org/57558107:18
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (10)  https://review.opendev.org/57601707:19
*** pcaruana has joined #openstack-nova07:19
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (11)  https://review.opendev.org/57601807:19
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (12)  https://review.opendev.org/57601907:19
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (13)  https://review.opendev.org/57602007:20
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (14)  https://review.opendev.org/57602707:20
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (15)  https://review.opendev.org/57603107:21
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (16)  https://review.opendev.org/57629907:21
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (17)  https://review.opendev.org/57634407:21
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (18)  https://review.opendev.org/57667307:21
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (19)  https://review.opendev.org/57667607:22
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (20)  https://review.opendev.org/57668907:22
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (21)  https://review.opendev.org/57670907:22
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (22)  https://review.opendev.org/57671207:22
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in virt/test_block_device.py  https://review.opendev.org/56615307:23
openstackgerritTakashi NATSUME proposed openstack/nova master: Add a live migration regression test  https://review.opendev.org/64120007:23
*** huachang has joined #openstack-nova07:28
openstackgerritzhongshengping proposed openstack/nova master: Replace git.openstack.org URLs with opendev.org URLs  https://review.opendev.org/65439807:29
*** slaweq has joined #openstack-nova07:30
*** dikonoor has quit IRC07:31
boxianghi does anyone know why my nova-next fails http://logs.openstack.org/20/645520/11/check/nova-next/afbb160/?  only nova-next of zuul fails. thanks :)07:42
boxiangis it necessary for me to do 'recheck'?07:42
openstackgerritBoxiang Zhu proposed openstack/python-novaclient master: Add host and hypervisor_hostname to create servers  https://review.opendev.org/64767107:58
*** yedongcan has quit IRC08:22
*** yedongcan has joined #openstack-nova08:22
*** tkajinam has quit IRC08:24
*** yikun has joined #openstack-nova08:41
*** pcaruana has quit IRC08:45
*** rcernin has joined #openstack-nova09:03
*** slaweq has quit IRC09:17
*** slaweq has joined #openstack-nova09:35
*** slaweq has quit IRC09:40
*** yan0s has joined #openstack-nova09:41
*** hoonetorg has quit IRC10:00
*** hoonetorg has joined #openstack-nova10:13
*** tetsuro has quit IRC10:20
*** huachang has quit IRC10:20
*** boxiang has quit IRC10:25
*** boxiang has joined #openstack-nova10:26
*** boxiang has quit IRC10:31
*** boxiang has joined #openstack-nova10:32
*** yedongcan has left #openstack-nova10:37
*** ttsiouts has joined #openstack-nova10:40
*** pcaruana has joined #openstack-nova10:58
*** ttsiouts has quit IRC11:04
*** ttsiouts has joined #openstack-nova11:05
*** avolkov has joined #openstack-nova11:05
*** ttsiouts has quit IRC11:10
*** tbachman has joined #openstack-nova11:29
*** udesale has quit IRC11:34
*** slaweq has joined #openstack-nova11:43
openstackgerritTakashi NATSUME proposed openstack/python-novaclient master: Updates for OpenDev transition  https://review.opendev.org/65442911:45
*** tbachman has quit IRC11:47
*** lpetrut has joined #openstack-nova11:47
*** slaweq has quit IRC11:47
*** tbachman has joined #openstack-nova11:48
*** tbachman has quit IRC11:56
*** tbachman has joined #openstack-nova12:16
*** shilpasd has joined #openstack-nova12:19
*** _erlon_ has joined #openstack-nova12:41
*** yan0s has quit IRC12:48
*** mriedem has joined #openstack-nova12:50
*** yan0s has joined #openstack-nova12:56
*** jmlowe has quit IRC13:00
*** lbragstad has joined #openstack-nova13:09
*** ratailor has quit IRC13:16
openstackgerritMatt Riedemann proposed openstack/nova master: Add functional recreate test for regression bug 1825537  https://review.opendev.org/65406613:26
openstackbug 1825537 in OpenStack Compute (nova) "finish_resize failures incorrectly revert allocations" [Medium,In progress] https://launchpad.net/bugs/1825537 - Assigned to Matt Riedemann (mriedem)13:26
openstackgerritMatt Riedemann proposed openstack/nova master: Drop source node allocations if finish_resize fails  https://review.opendev.org/65406713:26
openstackgerritTakashi NATSUME proposed openstack/python-novaclient master: Drop py35 tests  https://review.opendev.org/64387313:29
*** psachin has quit IRC13:39
mriedembauzas: can you review this functional recreate test for a stein regression bug? https://review.opendev.org/#/c/653268/13:42
*** jmlowe has joined #openstack-nova13:44
mriedemjaypipes: thanks for looking at https://bugs.launchpad.net/nova/+bug/1825435 - replied to your oslo.config question13:45
openstackLaunchpad bug 1825435 in OpenStack Compute (nova) "TestRPC unit tests intermittently fail with "'>' not supported between instances of 'NoneType' and 'datetime.datetime'" - maybe due to "Fatal Python error: Cannot recover from stack overflow."" [High,Confirmed]13:45
openstackgerritEric Fried proposed openstack/nova master: Fix {min|max}_version in ironic Adapter setup  https://review.opendev.org/65445713:45
efriedeandersson: ^13:45
efriedmriedem: Just grinding into action here - any progress on that bug?13:46
mriedemefried: no13:46
efriedk13:46
lpetruthey, I was wondering which criteria were used when defining the list of cpu traits: https://github.com/openstack/os-traits/blob/master/os_traits/hw/cpu/x86.py13:46
lpetrutI mean, why not use all the cpu features defined here? https://github.com/libvirt/libvirt/blob/master/src/cpu_map/x86_features.xml13:46
mriedemalex_xu: ^13:46
jaypipesmriedem: ack. still, the collections code does seem suspiciously related, given that stacktrace.13:47
mriedemjaypipes: yeah i'm trying to find the python3.6 package change log for bionic13:48
mriedemb/c i started seeing seg faults in pip3.6 last week also13:48
jaypipeslpetrut: I added those x86 traits.13:48
jaypipeslpetrut: I didn't use libvirt's XML files13:49
*** eharney has joined #openstack-nova13:49
mriedemhmm http://changelogs.ubuntu.com/changelogs/pool/main/p/python3.6/python3.6_3.6.7-1~18.04/changelog isn't very helpful13:49
*** awaugama has joined #openstack-nova13:49
*** tbachman has quit IRC13:50
lpetrutgot it, I was wondering how you've picked them, whether there was already some list at the libvirt driver level. also, would it make sense to extend this list? fetching all the features from the libvirt xml may be the easiest option13:50
jaypipeslpetrut: there are more hypervisors than libvirt. :)13:51
jaypipeslpetrut: and the content of the libvirt XML file changes over time of course.13:52
jaypipeslpetrut: we've added things to os-traits as needed. if there's a particular instruction set extension you want/need, don't hesitate to throw up a patch adding it. :)13:52
lpetrutjaypapipes: indeed, in fact I was looking into implementing 'update_provider_tree' for the hyper-v driver :) but those should probably be standardized at the openstack level13:53
jaypipes++13:53
jaypipeslpetrut: to answer your question, I don't remember there being any rhyme or reason to the ones I added. probably I just scraped things from unit tests or boxes I had lying around ;)13:53
lpetrutgot it, so basically each feature/trait was defined as needed (as opposed to having an extensive list)13:54
mriedemlpetrut: do you guys plan on upstreaming feature parity stuff like this at some point? https://opendev.org/x/compute-hyperv/commit/d4f1fa457a0fcbd1ac84c816157175c090958d6f13:55
mriedemhttps://opendev.org/x/compute-hyperv/commit/f615b509a2022025f2465341922a2e11427f882213:55
mriedemhttps://opendev.org/x/compute-hyperv/commit/8326d2c43c3e464f0c2e3b58bf57b4ffb9a344e713:55
lpetrutthose patches look straight forward, should be easy to review/merge13:56
lpetrutwell, maybe not the last one :)13:56
mriedemthey are at least a specless blueprint just since they are feature additions, but it seems all the feature work on the driver has been out of tree for the last couple of years13:56
jaypipeslpetrut: yes, exactly.13:57
mriedemlpetrut: anyway, just a thought, those first 2 look simple. i'm not looking to generate work, but i'd like to see the in-tree driver close some of these feature gaps that are already in the out of tree driver.13:58
lpetrutmriedem: yep, we can start with a few patches to close the gap a bit. thanks for bringing this up13:59
mriedembauzas: this is another simple functional recreate test for a stein regression: https://review.opendev.org/#/c/653098/14:01
*** huachang has joined #openstack-nova14:02
mriedemjaypipes: trying to think of ways to maybe debug that oslo.config getattr thing - we could maybe have a DNM patch to oslo.config that counts the number of times we've recursed into that getattr loop and log a traceback to see what's triggering it, then push a nova change that depends-on that oslo.config debug patch?14:05
*** takashin has left #openstack-nova14:07
gansomriedem: hey Matt! sorry for interrupting the current convo, but just a heads up of https://review.opendev.org/#/c/652153 ... I tested in my env and it did not work. It could be perhaps because I run stable packages instead of directly from source. Did it work in your env?14:09
mriedemganso: i saw your comment but i haven't yet tried to recreate in a queens devstack14:11
mriedemdo you see errors in the source node compute logs?14:11
mriedemdid you try rocky?14:11
gansomriedem: no I did not see any errors. It just did not remove the allocations14:11
gansomriedem: no I haven't tried rocky14:11
mriedemhmm, i'm not sure what the problem would be since it's calling the same method14:12
mriedemalternatively i could write a functional test to recreate it14:13
mriedemif you can debug it would obviously speed things up14:14
jaypipesmriedem: yeah, the issue is we don't really know where the original call site is for the getattr that is causing the stack exhaustion. if we did know what is the thing that is the base object or thing that is being called there, we could swap out that for either a mock or an actual collections.Mapping etc and see if the issue is in the ovo code, the oslo.cfg code, or something else.14:25
*** luksky has joined #openstack-nova14:26
jaypipesmriedem: I'm wondering if there's a way to limit the Python stack recursion size to a smallish number so that the stacktrace would show the entire traceback instead of just the last hundred or so repeated recursive calls to getattr.14:26
jaypipeshttps://docs.python.org/3/library/sys.html#sys.setrecursionlimit14:26
jaypipesmight be worth throwing that in a test, mriedem? ^14:27
jaypipesjust to get the whole traceback.14:27
jaypipeswhich might give us a better starting point.14:27
*** openstackgerrit has quit IRC14:28
*** huachang has quit IRC14:31
mriedemjaypipes: that's what i'm working on - dump the traceback to the logs before we get too far into the recursion14:32
jaypipesmriedem: coo.14:34
mriedemi'll push a nova change which depends-on it and see if we can recreate14:34
gansomriedem: thanks!14:35
*** openstackgerrit has joined #openstack-nova14:38
openstackgerritMatt Riedemann proposed openstack/nova master: DNM: debug config opts infinite recursion  https://review.opendev.org/65446814:38
*** mlavalle has joined #openstack-nova14:46
*** tbachman has joined #openstack-nova14:47
*** huachang has joined #openstack-nova14:48
*** hongbin has joined #openstack-nova14:55
*** hemna has joined #openstack-nova14:56
*** belmoreira has joined #openstack-nova14:59
*** lpetrut has quit IRC15:00
*** dklyle has joined #openstack-nova15:03
*** hemna has quit IRC15:08
*** hemna has joined #openstack-nova15:08
*** gyee has joined #openstack-nova15:11
openstackgerritMerged openstack/nova stable/pike: Fix incomplete instance data returned after build failure  https://review.opendev.org/64791615:13
efriedmriedem: Where are the logs you inserted?15:15
*** imacdonn has joined #openstack-nova15:17
efriedI don't see 'em in the job output or subunit results15:18
efriedmaybe logger config is set higher for oslo?15:22
mriedemefried: it won't dump the logs unless we hit a failure i don't think...15:24
mriedemmaybe i need to use prints15:24
mriedembecause what fails (TestRPC) isn't where the stack overflow happens i don't think15:24
*** yan0s has quit IRC15:25
efriedUse prints... and hope the stdout fixture isn't set up15:26
mriedemi don't see any default log level set for oslo.config either https://github.com/openstack/oslo.log/blob/22e8a347c8ba914cefa26df42dde632937259a79/oslo_log/_options.py#L1915:26
efriedso what's the default default if there's no default?15:26
mriedemin unit tests it'd be INFO15:27
efriedokay15:27
mriedemwhich is why we have the OS_DEBUG env var15:27
*** tbachman has quit IRC15:27
*** awaugama has quit IRC15:27
*** openstackgerrit has quit IRC15:58
*** huachang has quit IRC15:59
*** avolkov has quit IRC16:05
*** wwriverrat has joined #openstack-nova16:05
*** ivve has joined #openstack-nova16:11
eanderssonLooks good efried16:20
eanderssonAs for your devstack comment, that was never meant to break16:20
eanderssonas you are passing on endpoint = None16:20
eanderssonhttps://review.opendev.org/#/c/653839/16:20
eanderssonThis was the actual test16:21
efriedeandersson: But that test only reports that our endpoint lookup failed16:22
eanderssonExactly16:22
efriedeandersson: ...which is still a valid code path16:22
eanderssonSure16:22
efriedlike, if you specify a bogus region name or whatever.16:22
eanderssonBut regions don't actually work16:22
efriedright16:22
eanderssonNot sure what your point is16:22
efriedsee latest comment in the devstack patch.16:22
*** tosky has joined #openstack-nova16:22
eanderssonWell that patch was not to prove that multi region was broken16:22
efriedeandersson: My point is: I'm happy to have the behavior fixed, but it would be nice to have a regression test in place.16:22
eanderssonThat patch was to prove that get_endpoint was broken if region is supplied16:23
eanderssonOf course if you introduced multi-region it would have been way worse16:23
efriedokay, and that proof is the presence of that log message...16:23
eanderssonSince that would never have worked16:23
efriedso now if we reinstate that patch and rebase it onto the fix, the log message should be absent.16:23
eanderssonExactly16:24
efriedIn fact, we could just raise an exception and blow up the world if the endpoint is None there.16:24
eanderssonI think we should.16:24
efriedcool, you or me? :)16:24
eanderssonI can follow up after your patch so people can git blame me :p16:24
efriedSo hold on a sec16:25
efriedI'm not completely convinced we should be doing this for real16:25
efriedjust to prove the fix16:25
eanderssonWe can also take path nr 216:25
eanderssonjust pass on the region_name to the ironic client16:25
efriedIf ironicclient has a way to recover, and we disable/disallow it, that could piss off some operators :)16:25
efriedSo yeah, passing the region_name to the ironicclient's recovery dealy would be better I guess.16:26
eanderssonThe problem is really that we are letting the ironic client handle a failure scenario, but not actually giving it the context it needs16:26
efriedThough once again we're throwing good code after bad.16:26
efriedokay, to pass the region_name through, we only need changes on the nova side, right? ironicclient is already set up to handle it if it's in kwargs?16:26
eanderssonhttps://github.com/openstack/python-ironicclient/blob/master/ironicclient/client.py#L12116:27
eanderssonLooks like it yea16:27
efriedCool. So two things:16:28
efried1) Test patch that raises an exception if the ksa endpoint lookup fails, based on top of the fix https://review.opendev.org/654457 <== expect it *not* to blow up16:28
efried2) New patch to pass region_name through to irocicclient setup16:28
eanderssonPerfect!16:28
efriedI wonder if 2) should actually take two completely separate code paths.16:28
efriedOne if ksa endpoint lookup succeeds, that passes in no additional kwargs16:28
eanderssonYes - that would be fine16:28
eanderssonAnd safer16:28
efriedand a separate one if ksa lookup fails, that passes in basically all the ksa opts :(16:29
efriedIf you have the time to propose those, I'll happily review. I'm in the midst of summit chart prep hell.16:29
eanderssonSure - I'll try. I am also slammed this week though.16:30
efriedlooks like interface is already passed through. service_type *should* be unnecessary, but <shrug> guess it wouldn't hurt to pass it through.16:31
efriedand those are the only three used at the moment.16:31
eanderssonYea - was thinking the same.16:31
eanderssonUnrelated to this discussion. Is it just for me that I can't open links on review.opendev.org in new tabs anymore?16:32
eandersson(right click, Open link in new tab)16:34
efrieduh16:36
* efried tries16:36
efriedeandersson: wfm16:36
efriedwhat happens when you try it?16:36
eanderssonNothing16:36
eanderssonHmm works on Firefox16:36
eanderssonI guess my browser is just acting up.16:37
efriedI'm Chrome 73.0.3683.75 on Bionic fwiw16:37
efriedkashyap: I'm reading https://review.opendev.org/#/c/645814/4/specs/train/approved/cpu-selection-with-hypervisor-consideration.rst and not understanding it, at I think a more fundamental level than other reviewers.16:38
efriedI suspect I would be able to infer more if you addressed mriedem's comments16:39
efriedDo you have a sec to give me a brief rundown on what actual operations or behaviors are affected by these *HypervisorCPU() calls?16:40
*** openstackgerrit has joined #openstack-nova16:41
openstackgerritEric Fried proposed openstack/nova master: Fix {min|max}_version in ironic Adapter setup  https://review.opendev.org/65445716:41
*** sridharg has quit IRC16:48
*** lpetrut has joined #openstack-nova16:49
*** eharney has quit IRC17:00
*** tbachman has joined #openstack-nova17:20
*** lpetrut has quit IRC17:32
openstackgerritNikolay Fedotov proposed openstack/nova master: Fix disappearing ironic hypervisors after rebuilding hashring  https://review.opendev.org/65458417:47
sean-k-mooneyefried: kashyap spec is mainly techdebt removal through the use of newer libvirt apis that would allow nova to validate that the configuration specified in the nova.conf is valid17:54
efriedsean-k-mooney: Resulting in... earlier failures in spawn()? Refusal to start nova-compute?17:55
sean-k-mooneyi was suggesting failing to start the agent if the cpu flags were not compatible with the host/model specifed17:55
*** zbr is now known as zbr|pto17:56
sean-k-mooneybut the spec does not really make it clear17:56
*** eharney has joined #openstack-nova17:57
sean-k-mooneyit will in theroy also make the traits we report more acurate as it would take into account if kvm or qemu/which version of qemu is used too.17:57
sean-k-mooneywith all that said i agree with mriedem commets. the spec does not really spell out how useing the new apis deliver a new feature or capablity to operators/users form a nova perspecitve18:00
efriedthanks sean-k-mooney. I'm putting together charts for the project update at the summit and need to understand to *some* extent what each blueprint is about.18:03
sean-k-mooneyefried: from kasyaps top comment on the rewview 'Nova will now be able to answer: "Is this combination of IvyBridge + 'pcid' & 'pdpe1gb' supported by KVM, QEMU and libvirt on the host?"'18:04
efriedRight, "be able to answer" doesn't help me understand what will actually *happen*18:05
efriedso, detect whether A+B+C is copacetic and... what?18:05
sean-k-mooneyso really kashyap is trying to turn the a possible runtime failure when you boot the first vm into hopefully a startup failure of the agent with a detailed error message18:06
efriedwhen you say "agent", you mean n-cpu?18:06
sean-k-mooneyya at least that what i hope is the plan18:06
efried...by blowing up the virt driver init, I guess18:06
sean-k-mooneyyep18:06
efriedCool. Definitely needs to be spelled out in the spec.18:06
efriedThat is *not* an implementation detail :)18:07
sean-k-mooneyya kasap has a second spec that he inherited that is related18:07
sean-k-mooneyi think the agent stoping might be in that one18:07
sean-k-mooneyhttps://review.opendev.org/#/c/642030/18:08
sean-k-mooneyya line 71 https://review.opendev.org/#/c/642030/6/specs/train/approved/cpu-model-selection.rst@7118:09
*** ricolin has quit IRC18:10
*** rnoriega has quit IRC18:11
*** rnoriega has joined #openstack-nova18:12
openstackgerritsean mooney proposed openstack/nova master: [WIP] Libvirt: add nfv job  https://review.opendev.org/65219718:14
efriedstephenfin: mriedem: I don't see a bp for nova-console removal. Who was going to be spearheading that?18:15
sean-k-mooneyefried: fyi its a bankholiday here in ireland so stephenfin proably wont see that until tomorrow18:16
efriedsean-k-mooney: ack, thx18:16
openstackgerritMatt Riedemann proposed openstack/nova master: WIP: Add placement request filter for disabled computes  https://review.opendev.org/65459618:16
mriedemefried: sean-k-mooney: dansmith: belmoreira: ^ here is a PoC for the disabled compute pre-filtering stuff we talked about in berlin18:16
mriedemmelwitt: ^18:16
efriedmdbooth_: nudge, dud you see http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005366.html ?18:16
mriedemefried: i don't think there is a blueprint or a driver18:16
efriedack18:17
sean-k-mooneyoh cool18:17
mriedemefried: i wouldn't probably move forward with nova-console removal without a definitive ack from the citrix team18:17
dansmithisn't jaypipes going to lose his mind about that trait?18:17
mriedemwhy?18:17
sean-k-mooneymetadata in placement18:18
mriedemthat's what traits are18:18
dansmithbecause it's not a capability18:18
efriedmriedem: That's a pretty big "bug fix"18:19
sean-k-mooneywell if a compute service is disable its not capable of booting a node18:19
sean-k-mooney*vm18:19
sean-k-mooneythe other way to do it if traits were not used would be a aggregate18:20
sean-k-mooneyjust add the root rps of all disabled nodes to an aggreate and frobid it18:20
mriedemefried: see the todo18:20
sean-k-mooneybut a trait works too18:20
mriedemso, this is a poc hacked together for discussion at the ptg18:20
mriedemi would write a spec18:21
mriedembut wanted to post this first after working on it one morning18:21
efrieddig18:21
sean-k-mooneyan active service aggrate + member of is likely less of a sticking point in that an aggrate is just a bunch of resouce providers18:21
*** cfriesen has joined #openstack-nova18:29
mriedemefried: i thought i had something in the ptg etherpad for this bug but can't find it now - what would you prefer? nova general etherpad or the xp one with placement?18:32
efriedmriedem: "this bug" - disabled CPU prefiltering?18:33
mriedemyes18:33
efriedDoesn't require any placement changes (I don't count os-traits really) so nova etherpad.18:33
*** ivve has quit IRC18:33
efriedbut please ask yourself: does it need PTG time?18:33
mriedemalright18:33
efriedI haven't read your patch yet18:34
mriedemgiven the questions i just got after posting this...18:34
efriedsure, questions that would be answered in a spec; I guess I'm asking whether discussion in the spec wolud suffice.18:34
efriedwould18:34
sean-k-mooneyam it might help to do some of it in real time too18:35
mriedemyeah idk, i guess i was thinking i'd rather crank it out in 15 minutes rather than waffle on a spec for 2 months18:35
sean-k-mooneybut i think the idea of adressing this in placment in some way is a good one18:35
efriedsean-k-mooney: Do you mean you think there's potential placement API changes needed?18:36
mriedemsean-k-mooney: it has to be if cern (and huawei public cloud) want to grab more allocation candidates from placement during scheduling, cern is currently hacking around this18:36
sean-k-mooneyefried: no this should not need any api changes in placment18:36
*** ttsiouts has joined #openstack-nova18:37
sean-k-mooneybut we need to either use a trait or aggrage of some kind to track it in placement so placment can use its existing apis to filter out disabled hosts18:37
sean-k-mooneymriedem: right if you use limit its going to be a huge pain18:37
mriedemcern limits their allocation candidate results to like 20 and as a result were only getting back disabled computes in some cases18:38
sean-k-mooneyi left a quick comment https://review.opendev.org/#/c/654596/1/nova/scheduler/request_filter.py@104 by the way ill review it properly tomorow18:38
* jaypipes flies in18:38
efriedYeah, so the concept seems pretty simple to me, but if you think we need PTG time...18:38
mriedemefried: i just assume that like all things placement related there will be a holy war18:39
efriedI really hope we're getting close to having an established process for these GET /a_c-based filters18:39
efriedto the point where soon we'll be able to have specless bps for them. "Add trait called X. Set trait X on compute RP when Y. Add filter for X a) in flavor, b) in image, c) when condition Z is present. Done."18:40
sean-k-mooneythat would make my "port num instance filter to placemtn"  personal backlog item simpler :)18:41
efriedmelwitt, lbragstad: I seem to recall this session https://www.openstack.org/summit/denver-2019/summit-schedule/events/23712/migrating-nova-apis-to-keystone-scope-types being merged with another - link please?18:42
efriedd'oh, never mind.18:43
jaypipesmriedem: https://review.opendev.org/#/c/623558/ addresses the *reason* why CERN limits to 20. That's a more appropriate solution IMHO than making placement into another servicegroup API where we will need to sync active status between the nova cell DB tables and placement.18:45
jaypipesmriedem: it's not a holy war. it's just fundamentally you'll get into a situation where there are two sources of truth for whether a provider is active or not.18:46
jaypipesI'd prefer to avoid that if possilbe.18:47
mriedemwe already have 2 sources of truth for aggregates yeah?18:47
mriedemi thought one of the goals of placement was to do as much filtering in sql as possible to avoid the slower post-filtering in python we have18:47
mriedemso this would also align with that18:48
mriedemi realize the downside of this is nova and placement are out of sync on the status of the thing - we could potentially heal that in our compute update_available_resource periodic18:48
efriedMaybe eventually placement can be the sole source of truth18:48
jaypipeserm, not really if it doesn't usually filter anything at all...18:48
mriedemi imagine in a large cloud the ComputeFilter gets used a lot18:49
mriedemduring maintenance and such18:49
jaypipesmriedem: we could run the servicegroup API ahead of time and pass a parameter like ?uuids=!in:<DISABLED_SET>18:50
jaypipeswhich actually *would* be an efficient filter.18:50
jaypipesbut I digress.18:50
sean-k-mooneythat could be a long list of uuids18:51
sean-k-mooneywhich is why an aggregate would make more sense18:51
jaypipessean-k-mooney: rarely.18:51
jaypipessean-k-mooney: you're going to keep an aggregate membership sync'd with yet another periodic task? :(18:51
sean-k-mooneyno on servcei startup have the compute node remove itself form the aggrrate if its currently listed18:52
mriedemsean-k-mooney: i don't think you'd want an aggregate for all non-disabled computes if you have 14K computes18:52
sean-k-mooneythen we can add it if we  miss a heartbeat or someone use force down18:52
jaypipesmriedem: I think he's saying the opposite. an agg for disabled providers.18:53
sean-k-mooneymriedem: sure but you can do it the other way around too as you said in the review18:53
mriedemsean-k-mooney: if we did aggregates for this yes that's what i'd do, an aggregate for only disabled computes18:53
jaypipesoh look, a case for forbidden aggregates :)18:53
mriedemand yeah that's what we'd use ^18:54
sean-k-mooneyjaypipes: orgiginly in the code is said an aggrate for enabled because i fogot negitive member of was merged18:54
jaypipessean-k-mooney: it's the forbidden fruit.18:54
sean-k-mooneyfrom a db perspecitve this really would not be that expensice either way18:55
sean-k-mooneythe negitive case would be better but it will be similar18:55
jaypipesso, I suppose, in order of preference, I would personally go with: a) finish up https://review.opendev.org/#/c/623558/ and the other cell-specific-service-listing thing mentioned in there, b) use an aggregate for disabled computes and member_of=!<uuid> placement request filter18:55
sean-k-mooneythe aggrates table is just too uuid fields both of which are indexed18:55
jaypipesactually, it's not really an either/or. can/should do https://review.opendev.org/#/c/623558/ as well as a placement request filter for !member_of a disabled aggregate.18:56
sean-k-mooneyyes they are not mutally exclucive and i think both are useful18:57
jaypipesmriedem, sean-k-mooney: maybe adding a CONF.disabled_aggregate_uuid option that would be used to construct a placement request filter that used a member_of=!<uuid> query parameter to allocation candidates?18:58
jaypipesor something like that..18:58
sean-k-mooneyjaypipes: well it would be a prefilter so it would be enabled via config18:59
sean-k-mooneyor are you also suggesting a config option for the compute node too18:59
mriedemif we use an aggregate we have to use the same uuid everywhere,18:59
mriedemeither via config or hard-coded in api/compute/scheduler18:59
sean-k-mooneyya that is simple however18:59
sean-k-mooneyjust use a uuid5 that we caluate for a constat or hardcode it19:00
*** tbachman has quit IRC19:06
*** slaweq has joined #openstack-nova19:08
*** nicolasbock has joined #openstack-nova19:08
efriedoo, a special aggregate UUID. It's almost like... metadata.19:14
sean-k-mooneythat is sotred in nova19:15
sean-k-mooneynot placement19:15
sean-k-mooneyclinets of placement are free to use aggreate to group rps whatever way the like19:15
*** tbachman has joined #openstack-nova19:25
*** amodi has quit IRC19:27
sean-k-mooneyby the way before i go  i noticed some strange errors in the nfv-ci job19:27
sean-k-mooneylibvirtError: Cannot access storage file '/opt/stack/data/nova/instances/b4afcea9-12d0-4f79-953c-d09dad3e5515/disk' (as uid:107, gid:107): Permission denied19:27
sean-k-mooneyi also got DiskNotFound: No disk at /opt/stack/data/nova/instances/f5f5ce5f-a616-4e5e-aa35-d3cc469f869a/disk19:27
*** amodi has joined #openstack-nova19:28
sean-k-mooneyi have set the concurance to 1 and its reruning currently as i think that is part of the issue but i have no iday way those disk errors are showing up19:28
sean-k-mooneyif people want to take a look the logs are here http://logs.openstack.org/97/652197/11/check/tempest-nfv-multinode/e1fa793/compute/logs/screen-n-cpu.txt.gz?level=TRACE#_Apr_20_22_14_03_50348619:30
mriedemefried: except metadata that is unparseable by the human eye :)19:32
sean-k-mooneyother vms worked fine so im wondering if this is related to load/memory pressure.19:32
*** dasp has joined #openstack-nova19:33
*** lbragstad has quit IRC19:40
mriedemd15ab1ed-0000-0000-0000-00000000000 :)19:41
efriedsean-k-mooney: speaking of CI...19:43
sean-k-mooneywhat did i break now :)19:44
efriedI got an extremely vague question from within the blue walls today about what kinds of tests the PCI job ought to be running.19:44
efriedI hadn't a clue, but thought you might.19:44
sean-k-mooneyideally pci passthough via alaise in the flavor + neutron sriov interface, then it would be nice to alos test cold migration/resize  and possibly live migration in the neutron case19:46
efriedsomeone said something like the PCI job was just setting up devstack and not running any actual tests. I'm not sure how accurate that could be, or if they were looking at the wrong thing, or if at some point we disabled all the actual tests while we were working on the infra, or what.19:46
sean-k-mooneyi would just run the standared tempest test with tweeked flavors and different vnic_types19:46
*** dakshina-ilangov has joined #openstack-nova19:46
sean-k-mooneyefried: it runs test but it boots like 1 vm or very few tests19:46
efriedwas the PCI job just hitting SR-IOV?19:48
efriedCause there's an SRIOV job that runs against neutron19:48
efriednot sure if those are related19:48
sean-k-mooneythe pci job was ment for testing QAT integration with flavor bassed passthough19:49
sean-k-mooneythere was a seperate one for neutron sriov testing19:49
sean-k-mooneylooking at http://52.27.155.124/pci/482200/7/19:49
sean-k-mooneythere are not test in the test repofrt19:50
sean-k-mooneybut im not sure that means threare are not test19:50
sean-k-mooneyit looks like some test are run http://52.27.155.124/pci/482200/7/console_status.log.gz19:51
efriedI can't tell if they pass19:52
sean-k-mooneynor can i19:54
sean-k-mooneylooking at the devstack output and the tempest config i cant see tehm creating any custom flavor either19:54
efriedhow did you know where to find these logs?19:55
efriedthe CI is running, just not reporting?19:56
*** slaweq has quit IRC19:56
sean-k-mooneyi clicked on an old log got a 404 and went up one directory19:56
efriedhow did you know this patch had any results? Did you search for reviewedby:Intel PCI?19:57
* efried tries to learn how to fish19:57
sean-k-mooneyi looked at one of my patches that i knew it had commented on in the past19:57
sean-k-mooneyhttp://52.27.155.124/ you can see the rest of the logs are here for the other intel cis19:58
*** jmlowe has quit IRC19:58
efriedIC19:58
sean-k-mooneythis is a ovh log server that i used ot own/payfor via intel for the ci logs19:59
openstackgerritMatt Riedemann proposed openstack/nova master: DNM: debug config opts infinite recursion  https://review.opendev.org/65446819:59
sean-k-mooneyor maybe it moved20:00
sean-k-mooneyit used to be http://intel-openstack-ci-logs.ovh20:00
efriedI think the 52. is aws20:00
sean-k-mooneyya the pci ci used an aws log server. they moved to using our ovh one for a while i guess it moved back to aws at some point20:01
efriedyeah, that whole class A is amazon's. Not sure if that means aws, but probably20:01
sean-k-mooneybasicaly it just had to be a server that was not on the intel network20:01
efriedright, so the outside world could see it.20:02
sean-k-mooneyactully no os that you did not have to go through a 3 level security review to host an external facing service on the coperate network20:02
*** belmoreira has quit IRC20:02
efriedyeah, that too20:03
sean-k-mooneyif its not on the copreate network it was way eaiser aslo the pci ci was originally in china which casued issues20:03
efriedokay, I'm going to dive over the firewall and throw some of this intel back at intel. Thanks for the help.20:04
sean-k-mooneycool anyway my adivice would be to do something like im doing in the nfv ci test job20:04
sean-k-mooneye.g. run standared tempest test but use a custom flavor or tweek teh vnic_type used in the tempest config20:05
sean-k-mooneythat will test 90% of the edgecases20:05
sean-k-mooneyat that point if the ci is stable it can be extended to test more neich things20:05
mriedemdansmith: despite my typo in https://review.opendev.org/#/c/640197/ i'd like to get that in so we can move the grenade live migration job in-tree (this is under the queens backport) - because of devstack changes in queens + grenade i have to disable the ceph stuff in the grenade case, but it's either that or just drop the job altogether from queens which i'd like to avoid20:07
mriedemthe commit message attempts to explain the mess and reasoning for just punting and disabling the ceph case20:07
dansmithokay20:09
*** jmlowe has joined #openstack-nova20:14
*** ralonsoh has quit IRC20:14
sean-k-mooneymriedem: speaking of ceph we have a downstream request to backport two of your patches to newton wich is eol upstrema. https://review.opendev.org/#/q/topic:bug/1635008+(status:open+OR+status:merged) i know its been quite a while but are you aware of any reaon of the top of your head why that woudl be a bad idea.20:14
openstackgerritMatt Riedemann proposed openstack/nova master: Add functional recreate test for regression bug 1825537  https://review.opendev.org/65406620:15
openstackbug 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
openstackgerritMatt Riedemann proposed openstack/nova master: Drop source node allocations if finish_resize fails  https://review.opendev.org/65406720:15
sean-k-mooneyit looked resonable to me at first glance but just said i woudl ask20:15
mriedemsean-k-mooney: yes20:15
mriedemthere was a regression introduced20:16
sean-k-mooneyoh im glad i asked :)20:16
mriedemfor $5 i'll tell you the secret20:16
mriedemhttps://review.opendev.org/#/q/I6fc7108817fcd9df4a342c9dabbf14ab7911d06a20:17
sean-k-mooneyhttps://bugs.launchpad.net/charm-nova-compute/+bug/1671422?20:18
openstackLaunchpad 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
mriedemthat might be the other one20:18
mriedemhttps://review.opendev.org/#/q/Ieba216275c07ab16414065ee47e66915e9e9477d20:18
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 too20:19
mriedemsure20:19
mriedemor just tell the bank to upgrade20:19
sean-k-mooneyi mean if i could i would but...20:20
sean-k-mooneythat said depending on how invasive the other fixes are that might be answer20:20
sean-k-mooneyhuh the last one was only fixed recently in the grand scheme fo things20:23
*** lpetrut has joined #openstack-nova20:29
*** lpetrut has quit IRC20:33
efriedsean-k-mooney: I can see whitelist/alias stuff in the nova.confZ20:41
efriedpci_passthrough_whitelist = [{"vendor_id":"8086","product_id":"1520"}]20:42
efriedpci_alias = {"name":"pci_network_card","vendor_id":"8086","product_id":"1520"}20:42
efriedPresumably that does no good without a flavor requesting something at that alias?20:42
efriedwell, 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:42
efriedDo you have any idea where a guy could find the script that's running the show here?20:43
*** pcaruana has quit IRC20:46
sean-k-mooneycorrect20:47
sean-k-mooneyunless the flavor request the alaise it does not do anything20:47
sean-k-mooneyfor the device to be useable for neutron the physnet would have to be set in the whitelist20:47
sean-k-mooneythey could be using a local.conf like i am. my guess would be it burried in a jenkins job somewhere20:48
efriedthat's what I figured20:48
efriedI also really, really don't want to get too deeply involved here.20:48
sean-k-mooneyha to late :P20:48
efriedI recognize it's a Learning Opportunity20:49
sean-k-mooneywell its being converted to zull v3 right20:49
efriedbut if I go start debugging the CI, my life is over.20:49
efriedyes, afaik20:49
sean-k-mooneyso i woudl ignore how its currently running20:49
sean-k-mooneyand plan for how it will run20:50
efriedI 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
efriedAnd those left behind are scrambling to figure out wtf is going on.20:50
sean-k-mooneywell yes but that happened liek 2 years ago :P20:51
efriedoh20:51
sean-k-mooneyactully the pci ci was always different20:51
*** seyeongkim has quit IRC20:51
efriedwell, I know it would take *me* at least two years to figure out how this stuff works...20:51
sean-k-mooneybut the nfv ci was run by me an waldek but he left to joing redhat 2 years ago20:52
sean-k-mooneythe pci ci was run by a team of 1 person out of the PRC site but they had other respociblityes20:52
efrieddifferent 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
*** icey has quit IRC20:53
sean-k-mooneyya basically what i want to get out of that topic it the direct20:53
*** fyx has quit IRC20:53
sean-k-mooneyi could just repopose the old spec20:53
sean-k-mooneywhich say use a flavor/image property to specify the policy20:53
*** yikun has quit IRC20:53
sean-k-mooneyor i could pass the policy via a neutron port20:54
efriedis there any in-person design work needed?20:54
sean-k-mooneyas this is numa affinty for neutron interfaces20:54
*** jungleboyj has quit IRC20:54
sean-k-mooneywell it will need a spec in either case the quest is nova or neutron20:54
sean-k-mooneyi also want to expand it to all neutron ports not just sriov to pick up the numa awrere vswitch work stephenfin did20:55
efriedNot 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:55
sean-k-mooneyyes but the question is where is the policy for the numa afinity expressed20:56
sean-k-mooneyper neutron port? or in the flavor/image20:56
efriedEven 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:56
*** seyeongkim has joined #openstack-nova20:56
sean-k-mooneybinding profile is admin only20:57
sean-k-mooneyso that is one of the questions use binding profile or add it as a new qos policy20:57
efriedIs this something to discuss in the nova/neutron xproj?20:57
*** icey has joined #openstack-nova20:57
*** jungleboyj has joined #openstack-nova20:57
sean-k-mooneywell that is why i addeed it there20:58
efriedoh look20:58
*** seyeongkim has quit IRC20:58
efriedit's already in there20:58
sean-k-mooneyis it also in the main nova one20:58
sean-k-mooneyif so kill the nova one20:58
efriedso can I nix it from the main nova one?20:58
sean-k-mooneyya20:58
efriedcool20:58
sean-k-mooneysorry that was added before the cross project etherpad i forgot to kill it when i move it over20:59
*** gmann has quit IRC20:59
efriedyeah, 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
sean-k-mooneyim debating if we should drop one of the other topic i have in the xproj doc21:00
sean-k-mooneyi 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 work21:03
*** zbr|pto has quit IRC21:03
*** icey has quit IRC21:04
*** jungleboyj has quit IRC21:04
*** mnaser has quit IRC21:04
*** gmann has joined #openstack-nova21:07
*** fyx has joined #openstack-nova21:07
*** jungleboyj has joined #openstack-nova21:07
*** mnaser has joined #openstack-nova21:07
*** icey has joined #openstack-nova21:07
*** seyeongkim has joined #openstack-nova21:08
*** yikun has joined #openstack-nova21:09
efriedjaypipes: 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:13
*** Sundar has joined #openstack-nova21:16
openstackgerritMerged openstack/nova-specs master: Tools & docs for backlog & abandoned spec process  https://review.opendev.org/64880021:17
*** ttsiouts_ has joined #openstack-nova21:24
*** ttsiouts has quit IRC21:25
*** boxiang has quit IRC21:27
*** boxiang has joined #openstack-nova21:27
jaypipesefried: yessir.21:44
efriedthankyousir21:44
jaypipesnpsir21:45
*** ttsiouts has joined #openstack-nova21:50
*** ttsiouts_ has quit IRC21:52
*** rchurch_ has joined #openstack-nova21:57
*** bauzas_ has joined #openstack-nova21:58
*** manjeets_ has joined #openstack-nova21:58
*** bauzas has quit IRC21:58
*** tonyb has quit IRC21:58
*** johanssone has quit IRC21:58
*** bauzas_ is now known as bauzas21:58
*** panda has quit IRC21:58
*** sambetts_ has quit IRC21:58
*** odyssey4me has quit IRC21:58
*** rchurch has quit IRC21:59
*** Zara has quit IRC21:59
*** edleafe has quit IRC21:59
*** manjeets has quit IRC21:59
*** dansmith has quit IRC21:59
*** irclogbot_3 has quit IRC21:59
*** imacdonn has quit IRC21:59
*** panda has joined #openstack-nova22:00
*** odyssey4me has joined #openstack-nova22:00
*** seyeongkim has quit IRC22:01
*** dansmith has joined #openstack-nova22:01
*** imacdonn has joined #openstack-nova22:01
*** sambetts_ has joined #openstack-nova22:01
*** johanssone has joined #openstack-nova22:02
*** irclogbot_3 has joined #openstack-nova22:02
*** seyeongkim has joined #openstack-nova22:03
*** boxiang has quit IRC22:03
*** cfriesen has quit IRC22:03
*** boxiang has joined #openstack-nova22:04
efriedmriedem: https://review.opendev.org/#/c/645316/ is related to https://bugs.launchpad.net/nova/+bug/1817927 yah?22:06
openstackLaunchpad bug 1817927 in OpenStack Compute (nova) "device tagging support is not checked during move operations" [Undecided,New]22:06
*** jungleboyj has quit IRC22:07
*** gmann has quit IRC22:07
*** amodi has quit IRC22:07
*** nicolasbock has quit IRC22:07
*** jungleboyj has joined #openstack-nova22:07
*** nicolasbock has joined #openstack-nova22:07
*** mdbooth has joined #openstack-nova22:09
*** NewBruce0 has joined #openstack-nova22:10
*** tjgresha_nope has joined #openstack-nova22:10
*** irclogbot_3 has quit IRC22:11
*** amotoki_ has joined #openstack-nova22:11
*** sambetts has joined #openstack-nova22:12
*** gmann has joined #openstack-nova22:12
*** kinrui has joined #openstack-nova22:13
*** mlavalle has quit IRC22:14
*** NewBruce has quit IRC22:16
*** amotoki has quit IRC22:16
*** sambetts_ has quit IRC22:16
*** alex_xu has quit IRC22:16
*** wwriverrat has quit IRC22:16
*** yankcrime has quit IRC22:16
*** mdbooth_ has quit IRC22:16
*** kashyap has quit IRC22:16
*** dansmith has quit IRC22:16
*** jenglisch has quit IRC22:16
*** fungi has quit IRC22:16
*** tjgresha has quit IRC22:16
*** dansmith has joined #openstack-nova22:17
*** kinrui is now known as fungi22:19
*** irclogbot_0 has joined #openstack-nova22:19
*** irclogbot_0 has quit IRC22:19
*** edleafe has joined #openstack-nova22:19
*** irclogbot_3 has joined #openstack-nova22:20
*** ttsiouts_ has joined #openstack-nova22:22
*** ttsiouts has quit IRC22:23
*** jenglisch_ has joined #openstack-nova22:30
*** ttsiouts has joined #openstack-nova22:36
*** ttsiouts_ has quit IRC22:38
*** rcernin has quit IRC22:45
*** rcernin has joined #openstack-nova22:45
*** luksky has quit IRC22:50
*** tkajinam has joined #openstack-nova22:57
openstackgerritMichael Still proposed openstack/nova master: Remove fake_libvirt_utils from connection tests.  https://review.opendev.org/64255722:58
openstackgerritMichael Still proposed openstack/nova master: Remove fake_libvirt_utils from snapshot tests.  https://review.opendev.org/64255822:58
openstackgerritMichael Still proposed openstack/nova master: Remove fake_libvirt_utils from virt driver tests.  https://review.opendev.org/64389422:58
openstackgerritMichael Still proposed openstack/nova master: Remove fake_libvirt_utils from libvirt imagebackend tests.  https://review.opendev.org/64389522:58
openstackgerritMichael Still proposed openstack/nova master: Remove remaining vestiges of fake_libvirt_utils from unit tests.  https://review.opendev.org/64389622:58
openstackgerritMichael Still proposed openstack/nova master: Remove fake_libvirt_utils users in functional testing.  https://review.opendev.org/64479322:58
*** threestrands has joined #openstack-nova23:04
*** cfriesen has joined #openstack-nova23:07
*** tosky has quit IRC23:09
*** ttsiouts has quit IRC23:11
*** ttsiouts has joined #openstack-nova23:12
openstackgerritGhanshyam Mann proposed openstack/os-traits master: Dropping the py35 testing  https://review.opendev.org/65465123:13
*** alex_xu has joined #openstack-nova23:15
*** rcernin has quit IRC23:15
*** rcernin has joined #openstack-nova23:16
openstackgerritGhanshyam Mann proposed openstack/os-resource-classes master: Dropping the py35 testing  https://review.opendev.org/65465323:16
*** ttsiouts has quit IRC23:17
openstackgerritMerged openstack/nova stable/queens: Fix legacy-grenade-dsvm-neutron-multinode-live-migration  https://review.opendev.org/64019723:18
mriedemefried: yeah somewhat23:24
mriedemtonyb[m]: can you get this queens backport? https://review.opendev.org/#/c/640198/223:24
*** mriedem has quit IRC23:24
*** mriedem has joined #openstack-nova23:25
mriedemefried: 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 output23:27
mriedemmaybe i can speed that up23:31
openstackgerritMatt Riedemann proposed openstack/nova master: DNM: debug config opts infinite recursion  https://review.opendev.org/65446823:31
sean-k-mooneymriedem: 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
sean-k-mooneyrun with concurancy 1 is... slow23:32
*** hongbin has quit IRC23:33
mriedemsean-k-mooney: those don't test nfv things do they? or are you making the ports sriov ports or something?23:33
sean-k-mooneyim using flavors that enable hugepage pinning realtime eumlator thread polices a cpu topolgies23:34
sean-k-mooneyi 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:34
sean-k-mooneybut 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 hour23:36
sean-k-mooneyits multinode so the senario test will also chack migrations/resize.23:37
sean-k-mooneyi 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 sense23:39
sean-k-mooneyanyway goodnight o/23:40
mriedemyes just start with scenario tests in --serial or --concurrency=2 if you can23:43
sean-k-mooneyconcurrency=2 was ocationally resulting in no valid host errors23:44
sean-k-mooneypinning disable over subsription so its easy to end up running out for free cores23:45

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!