| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-30 | |||
| 17:06:17 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: _schedule_instances() supporting a RequestSpec object https://review.openstack.org/469037 | |
| 17:06:34 | bauzas | jaypipes: https://review.openstack.org/#/c/469037/ rev'd for just amending the bp name and a nit | |
| 17:06:55 | bauzas | jaypipes: will look at the shared RP spec later tonight | |
| 17:07:16 | openstackgerrit | Rafael Folco proposed openstack/nova master: placement: Specific error for inventory in use https://review.openstack.org/460231 | |
| 17:09:07 | openstackgerrit | Rafael Folco proposed openstack/nova master: Delete all inventory has its own method DELETE https://review.openstack.org/460147 | |
| 17:11:11 | rfolco | jaypipes, like your portuguese. Thanks :) | |
| 17:11:56 | openstackgerrit | Jay Pipes proposed openstack/nova master: Delete all inventory has its own method DELETE https://review.openstack.org/460147 | |
| 17:11:57 | jaypipes | rfolco: :) | |
| 17:12:05 | edleafe | bauzas: ok, had a few minutes between meetings. Looking at the difference between my last patch and yours (https://review.openstack.org/#/c/465171/7..9), the only change I see is the cell0 context change | |
| 17:12:07 | jaypipes | rfolco: ^^ just fixed a typo and repushed. | |
| 17:12:20 | edleafe | bauzas: that doesn't appear to be related to this patch at all | |
| 17:12:33 | edleafe | bauzas: shouldn't it be a separate patch? | |
| 17:26:52 | efried | jaypipes Got a minute? | |
| 17:28:26 | jaypipes | efried: can you give me about 30 mins to review your get_inventory() patch? :) | |
| 17:29:01 | openstackgerrit | Merged openstack/nova master: Add recreate functional test for regression bug 1689692 https://review.openstack.org/468549 | |
| 17:29:01 | openstack | bug 1689692 in OpenStack Compute (nova) "MarkerNotFound when limit>num(instances) and marker starts in cell0" [High,In progress] https://launchpad.net/bugs/1689692 - Assigned to Matt Riedemann (mriedem) | |
| 17:29:07 | efried | jaypipes Absolutely, thanks. I think I missed you on Friday, but here are the questions/uncertainties I had: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-05-26.log.html#t2017-05-26T19:55:33 | |
| 17:29:57 | jaypipes | efried: heh. "claimified" :) nice. | |
| 17:30:06 | efried | (TM) | |
| 17:30:45 | jaypipes | efried: :) so, the answer to your question #1 is yes, exactly. we handle allocations totally separately now. | |
| 17:31:10 | jaypipes | efried: as for the second question, can you give me examples of these resource classes that will not be consumed? | |
| 17:31:18 | efried | k. That's gonna make 'reserved' way more important (and harder to handle for us). | |
| 17:31:23 | sdake | is there any recent regression in the nova client or nova itself in master? | |
| 17:31:41 | efried | jaypipes I'm not sure they were being consumed in the first place. There's a link: https://github.com/openstack/nova/blob/master/nova/virt/powervm/host.py#L55-L64 | |
| 17:31:59 | efried | I noticed similar resources from get_available_resource in one of the other drivers - ironic, I think. | |
| 17:32:06 | jaypipes | efried: oh, yeah, those aren't resources. :) | |
| 17:32:12 | efried | Which, as far as I can tell, are also going to be ignored under get_inventory | |
| 17:32:42 | jaypipes | well, the numa_topology may be a resource in the (hopefully near) future. but things like hypervisor_type and supported_instances, etc, are not resource classes. | |
| 17:32:59 | jaypipes | efried: yes, those are ignored by get_inventory() | |
| 17:33:00 | efried | jaypipes Okay, so when I remove get_available_resource, those will just vanish and nobody will care? (Assuming I'm correct in my assessment that nobody's using them today?) | |
| 17:33:40 | efried | It's possible those guys had their origin by us looking at the other drivers and trying to emulate them. | |
| 17:33:50 | efried | ...blindly, without understanding wtf we were doing :) | |
| 17:33:57 | efried | But that's before my time. | |
| 17:34:56 | jaypipes | efried: no, the idea (eventually) is to have a tree of resource providers be passed to the virt driver. the virt driver will be able to set inventory on those providers in the tree as well as decorate the providers with traits. | |
| 17:35:35 | jaypipes | efried: the get_inventory() patches are kind of a stepping stone towards that eventual nirvana... | |
| 17:36:22 | efried | jaypipes And a "resource provider" is e.g. the host, and a "resource class" is e.g. VCPU. | |
| 17:37:08 | jaypipes | efried: my latest thinking on this is that the resource tracker would load up a ProviderTree (from https://review.openstack.org/#/c/415920/), pass that to a virt driver update_inventory() method and then pass the tree to a virt driver set_traits() method. possibly we could do the entire update inventory and set traits in a single method... | |
| 17:37:23 | jaypipes | efried: yes (to answer your question above) | |
| 17:37:45 | efried | jaypipes Are we achieving this nirvana in pike? | |
| 17:38:00 | jaypipes | efried: depends on how much progress we make in merging stuff this week :) | |
| 17:38:54 | efried | jaypipes Okay; just trying to get a sense of how urgently I should be making my driver keep pace with this stuff. | |
| 17:39:16 | jaypipes | efried: not urgent. | |
| 17:39:41 | jaypipes | efried: the resource tracker falls back to use get_available_resource(), so don't need to worry about being left behind just yet | |
| 17:40:02 | efried | jaypipes From what I could tell, it only falls back if get_inventory is NotImplemented. | |
| 17:40:28 | jaypipes | efried: correct. | |
| 17:40:51 | efried | jaypipes Soooo... is it a better idea to avoid implementing get_inventory at all until more of the infra is baked? | |
| 17:41:05 | jaypipes | efried: yes :) | |
| 17:41:32 | jaypipes | efried: I was gently trying to suggest that without you wanting to hit me because you've already pushed a patch :) | |
| 17:41:46 | efried | jaypipes Gotcha. I'll just put a big ol' -W on that sucker, then. | |
| 17:41:52 | jaypipes | heh, k | |
| 17:42:21 | openstackgerrit | Merged openstack/nova master: Remove unused migrate_data kwarg from virt driver destroy() method https://review.openstack.org/452958 | |
| 17:42:23 | efried | jaypipes Nah, publishing the patch was really a pretty minor part of this effort; the main thing was getting an understanding of how all of this is supposed to work. Which I was gonna need to do at some point anyawy. | |
| 17:42:26 | efried | anyway* | |
| 17:42:48 | efried | jaypipes Understanding the time frame helps a bunch, so thanks for that. | |
| 17:42:52 | jaypipes | np :) | |
| 17:43:21 | jaypipes | edleafe, bauzas, cdent, mriedem: reviews appreciated on https://review.openstack.org/#/c/462769/. thanks much in advance! | |
| 17:43:51 | cdent | jaypipes: in the queue | |
| 17:46:10 | cdent | jaypipes: when nirvana happens will the virt driver be authoritative for things in the ProviderTree, or will stuff like PCI devices still sometimes come from places like nova.conf? I ask because I was somewhat surprised to read "passed to the virt driver", instead of "from" | |
| 17:53:52 | jaypipes | cdent: good question. I'm torn. | |
| 17:58:22 | melwitt | first quotas patch is approved \o/ hallelujah | |
| 18:03:30 | mriedem | melwitt: did i persuade jaypipes otherwise? | |
| 18:03:41 | jaypipes | mriedem: yes | |
| 18:04:01 | mriedem | melwitt: i think https://review.openstack.org/#/c/446239/12/nova/quota.py@172 is valid though | |
| 18:04:07 | mriedem | but could be a separate patch | |
| 18:05:18 | mriedem | smcginnis and i have been trying to book flights to china all day, it's not going well | |
| 18:05:31 | mriedem | what was $2100 became $7K within an hour | |
| 18:05:41 | smcginnis | more like minutes. | |
| 18:07:04 | melwitt | mriedem: ah, right. that was a remnant from when I was considering putting the backward compat quota_usage_get_all* calls in _get_usages() or something like that | |
| 18:08:02 | melwitt | quota_usage_get_all* puts 'project_id' and 'user_id' in the dict it returns | |
| 18:08:25 | mriedem | yeah i was looking for that but you must have removed it | |
| 18:08:33 | mriedem | anyway, i'd just cleanup that docstring in a follow up change | |
| 18:09:31 | melwitt | which makes me wonder if I should mirror that to keep the contents similar. I didn't think about it because nothing uses the 'project_id' and 'user_id' keys | |
| 18:12:22 | mriedem | melwitt: if the caller doesn't care i don't see why we would | |
| 18:12:36 | mriedem | melwitt: btw, https://review.openstack.org/#/c/468559/ fixes a regression in cells v2 since newton, would be nice to get that backported | |
| 18:12:48 | mriedem | if we're quick about it i could even hold up the newton/ocata releases i requested last week | |
| 18:13:03 | melwitt | k, looking | |
| 18:13:04 | mriedem | oh nvm those were approved today | |
| 18:13:29 | mriedem | https://review.openstack.org/#/c/468549/ was the regression test patch btw | |
| 18:14:54 | clarkb | mriedem: supposedly they track your browser and such for things like that | |
| 18:15:07 | clarkb | mriedem: so uh maybe try private browsing and use linux | |
| 18:15:22 | clarkb | (supposedly OSes you pay for imply they can charge you higher rates) | |
| 18:18:34 | melwitt | mriedem: nice job on the func test. how did you make the servers go to ERROR state? | |
| 18:19:51 | melwitt | oh, nvm. just saw the comment about no compute service. derp | |
| 18:20:09 | mriedem | clarkb: didn't think about that | |
| 18:24:19 | mriedem | too late now, already booked | |
| 18:24:24 | mriedem | will have to remember that for next time though | |
| 18:29:58 | cr0wrx | anyone here familiar with any way to pull back memory dumps from instances? I don't believe it's currently a feature in nova but wanted to double check (or possibly someone knows of another project that might be aiming to do this) | |
| 19:01:34 | jaypipes | mriedem: question for you... I've now recheck'd this patch (https://review.openstack.org/#/c/462770/) a few times. keep getting failures, but I'm pretty sure the failures are completely unrelated to my patch. would you mind taking a look and verifying that it's not my patch that is causing these failures? :) | |
| 19:01:50 | mriedem | sure | |
| 19:02:50 | mriedem | jaypipes: looks like it is just your patch http://logs.openstack.org/70/462770/7/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/05083f7/logs/devstacklog.txt.gz#_2017-05-30_18_14_47_542 | |
| 19:02:53 | mriedem | devstack setup fails | |
| 19:03:28 | jaypipes | mriedem: it *is* my patch? | |
| 19:03:44 | mriedem | yeah | |
| 19:03:56 | mriedem | https://review.openstack.org/#/c/462770/7/nova/objects/resource_provider.py@31 | |
| 19:04:36 | mriedem | well, | |
| 19:04:41 | jaypipes | :( edleafe, turns out the auto-module-import thing ain't working.. | |
| 19:04:42 | mriedem | it's something in os-traits importing things from django? | |
| 19:04:45 | mriedem | right | |
| 19:04:49 | mriedem | os-traits is fubar'ed | |
| 19:05:10 | edleafe | jaypipes: it's not? Since when? | |