| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-25 | |||
| 12:35:43 | mriedem | jaypipes: i think i'm going to mark this done for pike https://blueprints.launchpad.net/nova/+spec/placement-allocation-requests | |
| 12:39:11 | jaypipes | mriedem: ack | |
| 12:39:39 | jaypipes | mriedem: I'll update the spec | |
| 12:41:38 | mriedem | thank | |
| 12:41:39 | mriedem | s | |
| 12:51:59 | openstackgerrit | Gábor Antal proposed openstack/nova master: use context mgr in instance.delete https://review.openstack.org/443764 | |
| 12:55:00 | s-dean | Hi, could someone take a look at this log this is really weird. compute01 connects to rabbit, but throws this error. https://pastebin.com/ZbpJtBq8 | |
| 12:55:19 | bauzas | jaypipes: I just thought about a possible problem with https://review.openstack.org/#/c/483566/10 | |
| 12:55:39 | bauzas | jaypipes: tl;dr how can we be sure that the first allocation request node is accepted by the filters ? | |
| 12:56:19 | openstackgerrit | Alexandra Settle proposed openstack/nova master: doc: Rework index page per new sections https://review.openstack.org/478485 | |
| 12:56:25 | bauzas | jaypipes: when we're getting a list of hosts after we run filters, we should possibly subset the alloc_reqs list to be only for accepted nodes, nope ? | |
| 12:56:43 | bauzas | jaypipes: unless you're changing it somewhere and I'm blind | |
| 13:02:03 | mriedem | TheJulia: looks like CI for https://review.openstack.org/#/c/215385/ has passed using https://review.openstack.org/#/c/485812/ yes? | |
| 13:02:13 | mriedem | although maybe not on the latest change? | |
| 13:03:43 | cdent | sdague: is this nutbar or crazy pants or hmmm? https://review.openstack.org/#/c/486829/ | |
| 13:03:53 | openstackgerrit | Chris Dent proposed openstack/nova master: Use wsgi-intercept in OSAPIFixture https://review.openstack.org/486825 | |
| 13:03:53 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Use wsgi_intercept in PlacementFixture https://review.openstack.org/486237 | |
| 13:04:18 | mriedem | TheJulia: or are you testing here now? https://review.openstack.org/#/c/485349/ | |
| 13:04:34 | bauzas | cdent: I'd be okay with wsgi-intercept but my concern goes with how many people are working for it | |
| 13:05:15 | cdent | bauzas: the crazy pants question was about modify MiniDNS not wsgi-intercept. | |
| 13:05:31 | cdent | on wsgi-intercept: we are already committed to using it because we are committed to using gabbi | |
| 13:05:40 | bauzas | cdent: I'm looking at its github page, and it means nova would have a dependency for a small package | |
| 13:05:55 | cdent | it’s had that dependency for over a year | |
| 13:05:57 | bauzas | cdent: sure, but gabbi looks pretty vibrant and I'm hoping it to have more contributors | |
| 13:06:13 | bauzas | cdent: do we use it elsewhere but in that fixture ? | |
| 13:06:18 | bauzas | if so, nevermind my concern | |
| 13:06:18 | cdent | in gabbi itself | |
| 13:06:30 | sdague | cdent: that's just optimizing for the opens? | |
| 13:06:31 | bauzas | a-ha, so a transitive dependency anyway | |
| 13:07:04 | cdent | sdague: that, and for avoiding on disk files when CONF.log_dir is not set. I was doing an strace and so many lines of open and closing dnstest.txt | |
| 13:07:24 | openstackgerrit | Alexandra Settle proposed openstack/nova master: doc: Rework index page per new sections https://review.openstack.org/478485 | |
| 13:07:24 | sdague | yeh, that seems reasonable | |
| 13:07:32 | bauzas | cdent: any plan to push wsgi-intercept to for example openstack ? | |
| 13:07:51 | sdague | cdent: I kind of wonder whether the write to disk path is needed at all | |
| 13:07:51 | TheJulia | mriedem: not ignoring you, presently debating a related grenade issue in another channel | |
| 13:08:12 | cdent | bauzas: neither wsgi-intercept nor gabbi will come to openstack because a few of the other contributors _really_ do not want that | |
| 13:08:19 | bauzas | cdent: that's understandable | |
| 13:08:39 | bauzas | well, if we already have that transitive dependency for gabbi, anyway... | |
| 13:08:51 | sdague | cdent: I remember seeing minidns spew a bunch in the past, and was always curious about getting it to stop that | |
| 13:09:00 | cdent | sdague: I tried that, and what I found was there are few different tests where there are more than one dns manager (instance/floating ip) that are sharing the same data file | |
| 13:09:03 | mriedem | TheJulia: np, take your time | |
| 13:09:29 | cdent | sdague: and I didn’t have the horsepower to go digging to see if that could be changed | |
| 13:10:38 | cdent | sdague: for most tests the in-memory thing is used | |
| 13:13:57 | mriedem | TheJulia: found what i was looking for http://logs.openstack.org/49/485349/4/check/gate-tempest-dsvm-ironic-ipa-wholedisk-bios-agent_ipmitool-tinyipa-ubuntu-xenial/376d4dd/console.html#_2017-07-25_04_37_15_094371 | |
| 13:14:26 | TheJulia | mriedem: I do love how much faster test runs :) | |
| 13:14:49 | mriedem | 4 minutes is faster? | |
| 13:15:42 | TheJulia | this can cut a reboot out of the process of handing a ready machine off, so naturally much faster :) | |
| 13:16:05 | mriedem | TheJulia: final questions when you get a moment are, i see some patches in flight on the ironic side, should we hold the nova change for those? or make the nova change depends-on them? | |
| 13:16:12 | mriedem | like https://review.openstack.org/#/c/484032/5 | |
| 13:19:50 | dtantsur | if jlvillal agrees, we can merge it now, and address the tests issues in a follow-up | |
| 13:20:03 | dtantsur | I suspect this is the only in-flight patch that matters | |
| 13:20:27 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Wrong href link returned when providing non-existed version in GET version API https://review.openstack.org/486850 | |
| 13:21:55 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Migration from ``ip`` commands to ``pyroute2`` https://review.openstack.org/484386 | |
| 13:22:04 | TheJulia | dtantsur: I already got agreement from him to do that last night :) | |
| 13:23:30 | TheJulia | dtantsur: well, agreement on the ironic patch :) | |
| 13:23:53 | dtantsur | okie, let's wait for Sam's review, and Just Do It (tm) | |
| 13:26:00 | TheJulia | Excellent! | |
| 13:26:13 | openstackgerrit | Gábor Antal proposed openstack/nova master: Transform missing delete notifications https://review.openstack.org/410297 | |
| 13:26:20 | openstackgerrit | Chris Dent proposed openstack/nova master: Optimize MiniDNS for fewer syscalls https://review.openstack.org/486829 | |
| 13:31:40 | s-dean | Hi, dont wana be a pest, any of you guys able to help me for 2 seconds ? | |
| 13:34:12 | mriedem | dtantsur: TheJulia: so i'm hearing we're good to go on the nova change then | |
| 13:34:20 | mriedem | if so, i will hassle mr dague | |
| 13:36:16 | jaypipes | bauzas: alloc_reqs_by_rp_uuid is a map of compute node UUID to list of allocation requests | |
| 13:36:19 | dtantsur | yeah, I suspect so | |
| 13:36:27 | dtantsur | the final word is for TheJulia though :) | |
| 13:38:58 | TheJulia | I think so | |
| 13:40:52 | bauzas | jaypipes: sure, but what if the first compute node UUID is not corresponding to the first host from the ones given by get_sorted_hosts() ? | |
| 13:41:08 | jaypipes | bauzas: it's a dict... | |
| 13:41:30 | jaypipes | bauzas: not sure what you're asking, sorry... | |
| 13:42:14 | bauzas | jaypipes: oh sorry, just saw edleafe's comment | |
| 13:42:23 | bauzas | https://review.openstack.org/#/c/483566/10/nova/scheduler/filter_scheduler.py@202 | |
| 13:42:52 | bauzas | we're getting a list of allocation requests *per* compute node | |
| 13:43:28 | jaypipes | bauzas: right | |
| 13:43:46 | sdague | mriedem: what's up now? | |
| 13:43:47 | bauzas | jaypipes: I was confused by your TODO in https://review.openstack.org/#/c/483566/10/nova/scheduler/filter_scheduler.py@270 | |
| 13:43:48 | edleafe | bauzas: don't feel bad - I had to read that over several times before it made sense to me, too | |
| 13:44:00 | jaypipes | bauzas: that alloc_reqs_by_rp_uuid is a dict, keyed by compute node UUID, of allocation requests that contain that compute node | |
| 13:44:07 | bauzas | jaypipes: so the same compute node could have more than one allocation request ? | |
| 13:44:23 | bauzas | just tbc | |
| 13:44:32 | edleafe | bauzas: there could be several allocs for a given compute node. The TODO is about being smarter about picking which one to use | |
| 13:44:56 | bauzas | the real problem I had is that allocation_candidates just was discussed when I was in and out, and now I'm paying the price by giving you silly comments :/ | |
| 13:44:58 | jaypipes | bauzas: yep. imagine in the future, nested r-p's there may be dozens of allocation requests that partially allocate resources on the compute node. | |
| 13:45:09 | jaypipes | bauzas: same with things like shared storage | |
| 13:45:25 | jaypipes | bauzas: not a problem, don't worry about it. | |
| 13:45:25 | mriedem | sdague: https://review.openstack.org/#/c/215385/ | |
| 13:45:28 | bauzas | jaypipes: ah, right | |
| 13:45:39 | bauzas | nested RPs is understandable by me | |
| 13:46:01 | bauzas | because you could consume more than one thing for a specific compute node | |
| 13:46:10 | bauzas | ah, and I see your point with shared storage | |
| 13:46:22 | jaypipes | bauzas: so, imagine a compute host with 2 NUMA nodes and 4 PCI devices, affined to the different NUMA cells. We might potentially have a lot of allocation requests (candidates) for those child providers plus resources on the compute host itself (like VCPU, etc) | |
| 13:46:30 | bauzas | we could potentially have the compute node having allocation request for local resources + shared resource ? | |
| 13:46:42 | jaypipes | bauzas: yep | |
| 13:46:46 | bauzas | jaypipes: that, I'm clear for nested RPs | |
| 13:46:53 | bauzas | okay, nevermind all my comments then | |
| 13:46:56 | bauzas | I'm on board now :) | |
| 13:46:57 | jaypipes | bauzas: one alloc request might have local disk, another consuming from shared disk. | |
| 13:47:00 | sdague | mriedem: ah, that one. Approved | |
| 13:47:09 | jaypipes | bauzas: of course, that's not currently possible, but you see the idea | |
| 13:47:09 | bauzas | jaypipes: thanks for explaning it | |
| 13:47:14 | jaypipes | no worries | |