Earlier  
Posted Nick Remark
#openstack-nova - 2018-03-16
12:39:15 openstackgerrit Yikun Jiang (Kero) proposed openstack/nova master: WIP: complex policy https://review.openstack.org/553776
12:45:31 figleaf ugh - tempest failed again. Is it worth rechecking yet again?
12:51:29 tssurya figleaf: guess not :(
12:51:48 Spazmotic heh
13:02:15 Roamer` a couple of years ago I proposed https://review.openstack.org/#/c/137830/ and then Things Happened(tm) and we stopped working on the StorPool Nova image backend. Looks like we'll write it after all (even if we have to maintain it out-of-tree); if I un-abandon that spec and propose it for inclusion, will somebody be very much against it?
13:10:30 fried_rice artom_: Thank you very much sir.
13:10:46 fried_rice alex_xu_: Thanks!
13:11:29 fried_rice figleaf: I win!
13:12:17 figleaf fried_rice: You probably sabotaged tempest so that you could win :)
13:12:17 fried_rice figleaf: To save some heartache, consider rebasing on top of https://review.openstack.org/#/c/548934/ (which is already in the gate) instead of master.
13:12:37 fried_rice figleaf: Oh, I totally did. I didn't know it was gonna *work* though.
13:13:11 figleaf fried_rice: that patch has a tempest failure, too
13:13:20 figleaf you forgot to un-bork tempest
13:16:59 fried_rice those volumes...
13:22:08 openstackgerrit Merged openstack/nova master: New-style _set_inventory_for_provider https://review.openstack.org/537648
13:22:25 mriedem https://review.openstack.org/553786
13:25:32 figleaf mriedem: <fingers crossed>
13:32:42 mnaser how do we feel about having 'ComputeCapabilitiesFilter' but instead parses image properties rather than instance type
13:33:27 mnaser (reason is, i have X customer which needs Y feature, i dont want to start maintaining instance types for every single one, but rather give the ability for the customer to add propreties)
13:36:11 leakypipes mnaser: https://review.openstack.org/#/c/541507/ will make your day.
13:37:20 mnaser leakypipes: i love how the "example" is exactly what we're looking for .. trait:HW_CPU_X86_AVX2=required
13:38:03 mnaser (like, the exact instruction set too)
13:38:43 leakypipes mnaser: bingo.
13:39:01 mnaser i guess i'll have to live with custom flavors till this code gets shipped
13:39:17 leakypipes mnaser: should be done in <2 months
13:39:34 leakypipes right arvindn05? ;P
13:39:59 mnaser well isnt it nice we have 6 month release cycles so i can pick it up in a release in 6 months max
13:40:06 mnaser ok it's friday i'll be nice
13:42:37 leakypipes mnaser: :)
13:46:08 openstackgerrit sahid proposed openstack/nova-specs master: virt: allow instances to be booted with trusted VFs https://review.openstack.org/485522
13:51:11 openstackgerrit Ed Leafe proposed openstack/nova master: Add 'member_of' param to GET /allocation_candidates https://review.openstack.org/552098
13:51:14 figleaf fried_rice: ^^ rebased
13:53:26 openstackgerrit Merged openstack/nova-specs master: Fix spec name for "report CPU features as traits" https://review.openstack.org/552159
13:53:28 mriedem sahid: i see the problem in that linuxbridge multinode job
13:54:48 mriedem posted a new version
13:55:34 leakypipes figleaf: +2
13:57:48 sahid mriedem: cool thanks, it's that change in "hosts", right?
13:58:59 mriedem yeah
13:59:13 mriedem subtle differences in the ansible playbook for a multinode job
14:00:14 sahid ok, i also working on backporting the change in one of our rhos version. so i hope we could do some internal tests
14:02:20 stephenfin lyarwood: Been looking at this oslo.config bug https://bugs.launchpad.net/nova/+bug/1755783 It seems nested_parse is getting confused with our output for that option http://paste.openstack.org/show/703014/
14:02:22 openstack Launchpad bug 1755783 in OpenStack Compute (nova) "PCI configuration documentation renders with smart quotes" [Undecided,In progress] - Assigned to Stephen Finucane (stephenfinucane)
14:02:40 stephenfin lyarwood: So it's probably going to need a significant rewrite of that extension to unconfuse it :(
14:03:02 stephenfin (all that stuff in the <paragraph> tag should have been parsed itself but wasn't)
14:03:42 dansmith sahid: I thought you said you already tested this locally back in an earlier version
14:03:58 dansmith sahid: does that mean you haven't actually tested this manually yet?
14:04:27 dansmith specifically "I'm making tests locally and everything seemed to work"
14:04:46 mnaser are live migration job failures common-ish in gate? aka safe to recheck?
14:06:00 fried_rice figleaf: I'm sorry I'm just getting to this, but I've got some comments on that guy.
14:06:27 figleaf fried_rice: go for it
14:07:21 sahid dansmith: that was for a previous version of that patch
14:08:00 dansmith sahid: right, the version that _couldn't_ work...so you haven't tested the latest approach locally?
14:08:56 fried_rice figleaf, leakypipes: The thing so far that we might potentially want to hold up for is that the syntax isn't consistent with member_of in GET /resource_providers. Looks like this discussed earlier in the life of this patch, but not addressed.
14:09:16 sahid dansmith: no sure what you mean by the version that _counldn't work
14:09:23 dansmith heh
14:17:09 figleaf fried_rice: what are the differences that you see?
14:18:12 fried_rice figleaf: GET /resource_providers?member_of=in:<list of UUIDs> -- yours has no 'in:'. Personally I think 'in:' is silly and would like to see it go away. But it's inconsistent. But I don't like it. But it's inconsistent. I'm torn.
14:19:33 openstackgerrit Merged openstack/nova master: Updated from global requirements https://review.openstack.org/553211
14:20:18 figleaf fried_rice: what do you mean? Because 'in:' is optional with a single UUID?
14:20:28 leakypipes fried_rice: I used to think I was indecisive. Now I'm not so sure.
14:20:35 fried_rice cdent: Do we have a blueprint for placement split?
14:20:43 stephenfin Can someone send this on its merry way through the gate? https://review.openstack.org/#/c/553751/ Fixes an issue I introduced with 'tox -e docs' locally (which the gate no longer runs)
14:20:45 fried_rice https://review.openstack.org/#/c/553149/ should be tagged with it.
14:20:45 leakypipes fried_rice: no, it's more a collection of things.
14:21:04 mriedem mdbooth: dansmith: Kevin_Zheng: cfriesen: re: the abort queued live migration spec, i did some digging and i think the futures library/module is what we'd want https://review.openstack.org/#/c/536722/
14:21:20 mriedem throw futures into a thread pool executor and you can cancel them if they haven't already started
14:21:23 fried_rice figleaf: I haven't gotten all the way through the patch yet (in a meeting atm) but it looks to me like your GET /a_c member_of doesn't use 'in:' at all.
14:21:35 leakypipes stephenfin: gerrit is telling me it needs a rebase
14:21:42 dansmith mriedem: that's one way to do it yeah
14:21:43 mriedem reminds me of when i used to use https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/package-summary.html
14:21:45 fried_rice figleaf: In GET /r_p if I'm not mistaken, you *can't* specify a list without 'in:'
14:22:13 stephenfin leakypipes: It is? I'm not seeing anything in the UI
14:23:00 cdent fried_rice: no, there's no spec or blueprint at this stage, mostly because of what leakypipes says: there's a suite of vaguely connected lots of things. Do you think we should have something?
14:23:04 mriedem mnaser: yes we hit live migration failures in the gate intermittently
14:23:07 figleaf fried_rice: https://review.openstack.org/#/c/552098/8/nova/api/openstack/placement/util.py@333
14:23:15 mriedem mnaser: there are some known issues with libvirt in the versions we use
14:23:27 mnaser mriedem: ah bummer, i'll throw a recheck then
14:23:29 leakypipes finucannot: it says Cannot Merge for me.
14:23:37 mriedem mnaser: e.g. http://status.openstack.org/elastic-recheck/#1706377
14:24:16 fried_rice cdent: Seems like it would be nice. At least a common topic so we can see everything. I guess that would be sufficient.
14:24:48 cdent i'll make something
14:25:39 fried_rice figleaf: Okay; So far I had only read the explanation comment in microversion.py and it's not listed in there. I'll stay quiet til I finish the patch.
14:25:56 mriedem Kevin_Zheng: so i think we create a ThreadPoolExecutor, submit the live migration calls on that, which returns Future objects, and we map those to the migration id which we can later lookup to then call Future.cancel()
14:26:07 fried_rice I see it in the reno.
14:26:19 finucannot fried_rice: Oh, right. Weird that the UI didn't say that.
14:26:46 superdan mriedem: we need to make sure we don't .cancel() after it's started really running
14:26:54 superdan mriedem: does futures handle that or do we need to?
14:27:09 openstackgerrit Jay Pipes proposed openstack/nova master: mirror nova host aggregate members to placement https://review.openstack.org/553597
14:27:27 figleaf fried_rice: if the comments can be made clearer, that can always be done in a follow-up patch, no?
14:27:29 leakypipes lyaaaaaaaaaaaaar: ahoy, matey.
14:27:39 fried_rice figleaf: Yes, certainly.
14:28:05 Kevin_Zheng mriedem: Thanks for reviewing, I’m not familiar with this lib, have to do some reading first
14:28:21 openstackgerrit Stephen Finucane proposed openstack/nova master: Follow the new PTI for document build https://review.openstack.org/553751
14:28:22 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Correct documentation for '[pci] passthrough_whitelist' https://review.openstack.org/552874
14:28:53 finucannot johnthetubaguy, leakypipes: and fixed. A global requirements messed with the sphinx version, causing a merge conflict ^
14:30:22 mriedem superdan: cancel() returns False if the task has already starte
14:30:24 mriedem *started
14:30:28 superdan mriedem: ack, col
14:30:30 superdan *cool
14:30:31 mriedem you can also add a callback function to the future

Earlier   Later