| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-27 | |||
| 12:22:22 | openstackgerrit | John Garbutt proposed openstack/nova: Scheduler calling the Placement API https://review.openstack.org/417961 | |
| 12:24:00 | johnthetubaguy | heh | |
| 12:53:57 | dakmetov | greetings everyone! | |
| 13:03:40 | dakmetov | 2 mbooth: thank you for the great review! | |
| 13:04:19 | dakmetov | 2 mbooth: could you please clarify one thing: https://review.openstack.org/#/c/399679/5/nova/virt/libvirt/driver.py | |
| 13:04:46 | dakmetov | 2 mbooth: what do you mean under 'source info'? | |
| 13:05:38 | cdent | johnthetubaguy: something weird: http://logs.openstack.org/61/417961/35/check/gate-grenade-dsvm-neutron-multinode-ubuntu-xenial/7e52701/logs/new/screen-n-sch.txt.gz#_2017-01-27_12_55_20_946 | |
| 13:05:56 | cdent | min is showing as 16, but a compute is 15! | |
| 13:08:56 | wznoinsk | sfinucan, hi | |
| 13:09:24 | sfinucan | wznoinsk: hey | |
| 13:09:27 | sfinucan | what's up? | |
| 13:09:58 | bhagyashris | cdent: Hi, Is the create resource_provider available for the user or it's only for the internal api for service? | |
| 13:11:47 | cdent | bhagyashris: It's possible for anything with the admin role to create resource providers, but at the moment there's not a lot of reason to do so. Long term the idea is that resource providers for things like shared disk farms will exist | |
| 13:12:44 | bhagyashris | cdent: And Is it necessary that the resource_provider name should be the host name? | |
| 13:13:20 | wznoinsk | sfinucan, I saw your chat with vladikr yesterday, I'm guessing he has some hardware dependent tests, was that passthrough and alike or more of networking like sriov work? | |
| 13:14:22 | cdent | bhagyashris: the name of the resource provider is there for humans to remember and filter on as needed. The resource providers that are automatically created for compute nodes use the hostname. | |
| 13:17:48 | bhagyashris | cdent: Thank you for useful information. :) | |
| 13:18:06 | cdent | you're welcome | |
| 13:21:00 | dakmetov | guys, is there any way to get user name and tenant name using userid and tenantid inside nova? | |
| 13:21:18 | dakmetov | without external lookups to keystone, I mean | |
| 13:26:06 | johnthetubaguy | cdent: crud, I think I know the problem... | |
| 13:26:35 | cdent | johnthetubaguy: oh good, because I've been staring at that trying to figure it out to no avail. do tell? | |
| 13:27:09 | johnthetubaguy | adding a comment, one sec | |
| 13:27:15 | sfinucan | wznoinsk: So yeah, he's looking to test the exposing of VLAN tag through the metadata service | |
| 13:27:36 | sfinucan | We're thinking that will require physical hardware. Not sure if it's something the Intel PCI CI could validate or not | |
| 13:27:53 | johnthetubaguy | cdent: does my comment make sense? | |
| 13:28:00 | johnthetubaguy | going to fix up now, and push it | |
| 13:28:22 | cdent | oh hell | |
| 13:28:38 | cdent | i hate it when it is something like that | |
| 13:29:23 | cdent | I just assumed that was correct because all this service version stuff is new to me | |
| 13:29:30 | cdent | savagely educated | |
| 13:29:56 | johnthetubaguy | I read that three times and checked it | |
| 13:30:07 | openstackgerrit | John Garbutt proposed openstack/nova: Scheduler calling the Placement API https://review.openstack.org/417961 | |
| 13:30:22 | johnthetubaguy | I like that phrase | |
| 13:30:25 | johnthetubaguy | its a bit like used in anger | |
| 13:30:30 | cdent | "bugger" is the best comment ever | |
| 13:30:43 | johnthetubaguy | its the correct british way, I feel | |
| 13:30:49 | cdent | quite | |
| 13:30:56 | johnthetubaguy | one doesn't want to offend | |
| 13:31:08 | cdent | unless one really needs to | |
| 13:31:13 | cdent | we were nearly there | |
| 13:31:13 | johnthetubaguy | heh | |
| 13:31:23 | johnthetubaguy | so I left the debugging in, just in case | |
| 13:31:44 | cdent | good choice | |
| 13:35:07 | cdent | edleafe: you surfaced yet? | |
| 13:36:38 | markus_z | dansmith: If you find time to review: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/newton+topic:%22bug+1455252%22 | |
| 13:42:52 | markus_z | ^ or any other stable core, I'm not picky ;) | |
| 13:54:26 | figleaf | cdent: I'm here | |
| 13:55:07 | cdent | figleaf: just wanted to know if you're up to date on the above | |
| 13:55:20 | figleaf | cdent: still reading... | |
| 13:55:50 | figleaf | cdent: want to give me the summary? | |
| 13:56:22 | cdent | figleaf: the only thing that real matters is: https://review.openstack.org/#/c/417961/35/nova/scheduler/filter_scheduler.py | |
| 13:56:29 | cdent | (john's discovery) | |
| 13:56:44 | figleaf | just reading the 'bugger' comment :) | |
| 13:57:39 | figleaf | looks like johnthetubaguy has taken care of it | |
| 13:58:16 | cdent | yes | |
| 13:58:21 | figleaf | and I have a merge conflict on the last of the RP series https://review.openstack.org/#/c/414769/ | |
| 13:58:55 | cdent | the debugging stuff that's right around bauzas patch is still in there for the current gate run, but if it happys will be cleared out | |
| 13:59:22 | figleaf | cool | |
| 13:59:44 | cdent | we're not trying to get nested rps in ocata, or are we? | |
| 14:00:08 | figleaf | cdent: yes, but they won't be doing very much at all | |
| 14:01:05 | cdent | then I guess my rp update 9 email is wrong, could you extend it? | |
| 14:02:20 | jroll | cdent: figleaf: safe to assume we didn't get the extra_specs=CUSTOM_FOO_RESOURCE_CLASS=1 thing done, right? | |
| 14:02:24 | johnthetubaguy | the ironic custom stuff, I guess we don't query that either yet, but if its in this cycle we can query it next cycle? | |
| 14:02:42 | johnthetubaguy | is looking at: https://review.openstack.org/#/c/404472 | |
| 14:02:47 | jroll | johnthetubaguy: I think we have similar questions :) | |
| 14:02:56 | cdent | jroll: the handling of extra specs, no, but the recording of inventory is still trying to get in | |
| 14:03:06 | johnthetubaguy | jroll: heh, yup | |
| 14:03:20 | figleaf | cdent: dammit, you type too fast | |
| 14:03:48 | jroll | cdent: right, so operators cannot change their flavors until pike, so we can't cut over how we schedule until q :( | |
| 14:04:27 | jroll | with 'cut over' ~= 'drop cpu/ram/disk-based scheduling' | |
| 14:04:36 | figleaf | jroll: wait - why can't they update their flavors? The new stuff will be ignored, but still... | |
| 14:04:48 | cdent | jroll: I guess so? :( It's been really hard to track some of this | |
| 14:05:17 | jroll | figleaf: because a flavor with cpu/ram/disk won't work in the new world, where ironic resource providers don't have cpu/ram/disk | |
| 14:05:40 | jroll | it would require CUSTOM_FOO *and* 2 vcpu and 16384 rams, etc | |
| 14:06:09 | johnthetubaguy | so I am reading through, it looks like each nova-compute node can only look at one ironic resource_class, is that correct? | |
| 14:06:16 | jroll | the old flavors are incompatible with the new | |
| 14:06:44 | figleaf | jroll: ah, so they could update their flavors, but the flavors will have both the resource class name *and* the vm-ish stuff too | |
| 14:07:09 | figleaf | johnthetubaguy: that's the idea | |
| 14:07:40 | jroll | figleaf: yeah, something like that | |
| 14:08:03 | johnthetubaguy | jroll: are we OK with nova-compute to resource class 1:1 mapping? | |
| 14:08:05 | figleaf | jroll: the scheduler/placement will just ignore the former for now, and at some point, switch to ignoring the latter | |
| 14:08:53 | figleaf | johnthetubaguy: to be clear, there can be multiple nova-computes that are mapped to the same resource class | |
| 14:09:37 | jroll | figleaf: I'm skeptical, how would it know to ignore ram/cpu for that flavor (but not for a virt flavor)? | |
| 14:10:09 | jroll | johnthetubaguy: that seems... wrong. are we talking nova-compute service or compute_node entry? a compute service should handle more than one resource class fine | |
| 14:10:51 | jroll | there should be n:1 node:resource_class, and m:n service:resource_class | |
| 14:11:21 | johnthetubaguy | jroll: that was my assumption | |
| 14:12:06 | figleaf | jroll: there will probably be an "if _is_ironic():" check added to that code to look for the resource class | |
| 14:12:12 | jroll | johnthetubaguy: I also don't see that n:1 service:resource_class in the code | |
| 14:12:25 | johnthetubaguy | jroll: the resource class request's presence just always dominates any other request, that seems fine | |
| 14:13:57 | cdent | Is it normal for us to be as confused about stuff as we've been? | |
| 14:14:04 | johnthetubaguy | figleaf: I guess we can make it nested, once we have nested? | |
| 14:14:43 | johnthetubaguy | cdent: thats probably yes, I prefer the "can we do better at this" question, I hope thats a yes too | |
| 14:15:00 | cdent | just checking | |
| 14:15:04 | johnthetubaguy | jroll: I am looking here: https://review.openstack.org/#/c/404472/23/nova/compute/resource_tracker.py@525 | |
| 14:15:11 | johnthetubaguy | cdent: its good to check these things | |
| 14:15:18 | cdent | I'm trying to decide whether it is reasonable to be chill or panicky | |
| 14:15:57 | jroll | johnthetubaguy: yeah, so that's for a single ironic node, and that code will run once per ironic node | |
| 14:16:29 | openstackgerrit | Andrey Volkov proposed openstack/nova: WIP Update pci device fields from deleted object https://review.openstack.org/426243 | |
| 14:16:46 | figleaf | cdent: it's more the overlapping terminology that confuses me | |