| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-06 | |||
| 15:58:12 | mriedem | maybe i'll add some comments in the code explaining it's never used currently, | |
| 15:58:19 | alaski | cool | |
| 15:58:22 | mriedem | and if we did, we'd have to do a data migration to actually "finish" old actions | |
| 15:58:51 | vdrok | mriedem: hrm, that means we can remap a running instance from compute in one cell to a compute in another one. I guess we'll need to change that | |
| 15:59:18 | mriedem | remap? | |
| 15:59:44 | vdrok | yeah, we decide which compute manages which instance by hash ring, IIRC | |
| 16:00:06 | vdrok | s/instance/hypervisor in our case | |
| 16:27:12 | dansmith | vdrok: correct | |
| 16:28:05 | vdrok | dansmith: correct about ServiceList containing only this cell computes or about "we have to change it"? :) | |
| 16:28:16 | dansmith | vdrok: sorry, I was reading the scrollback in order and answering in order | |
| 16:28:19 | mriedem | vdrok: who changes the mapping? ironic? or the driver? | |
| 16:28:28 | dansmith | vdrok: so, if you put computes in two cells and point them at a single ironic, | |
| 16:28:31 | dansmith | then you'd have problems | |
| 16:28:33 | mriedem | if it's the driver, the driver is in a cell and only has visibility to other compute services in that same cell | |
| 16:28:54 | vdrok | mriedem: the driver | |
| 16:28:55 | dansmith | vdrok: but you can't really handle that in your hash ring code, so I would say that the only reason you'd have multiple cells in ironic would be if you had two ironics | |
| 16:29:16 | dansmith | vdrok: or if ironic grows a cells-like partitioning scheme at some point in the future | |
| 16:29:40 | vdrok | dansmith: mhm, so it seems like multicell is not for us at all in gate :) | |
| 16:29:47 | vdrok | gotcha | |
| 16:29:47 | dansmith | vdrok: that might be a good reason to not run the gate job in multicell mode forever | |
| 16:29:49 | dansmith | yeah | |
| 16:35:20 | mriedem | what is a PV guest in xen? | |
| 16:35:40 | mriedem | paravirtualization? | |
| 16:35:49 | mriedem | == nested virt? | |
| 16:35:51 | mriedem | like qemu? | |
| 16:40:09 | cdent | mriedem: did you already find this: https://wiki.xen.org/wiki/Paravirtualization_(PV) | |
| 16:40:30 | mriedem | yeah | |
| 16:40:35 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add release note for xenapi virt device tagging support https://review.openstack.org/481148 | |
| 16:40:36 | mriedem | i was just being lazy | |
| 16:40:58 | cdent | how virtuous of you | |
| 16:42:18 | dansmith | mriedem: pv is not like nested virt or qemu | |
| 16:42:24 | dansmith | not sure if you gathered all that | |
| 16:42:39 | mriedem | dansmith: yeah got that from the wiki | |
| 16:42:40 | dansmith | it's closer to a container, but with a full separate guest kernel | |
| 16:42:42 | dansmith | okay | |
| 16:57:01 | gaurangt | hi, is there a bug in nova (ocata) where when failed instances are removed, the quota values are not updated? I am observing this behavior in my setup. Used quota values are updated properly only when an active instance is deleted. | |
| 17:05:59 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Improve allocation_cadidates coverage https://review.openstack.org/481153 | |
| 17:06:15 | cdent | jaypipes: ^ discovered that while trying to reacquaint myself with the allocation candidates code | |
| 17:06:28 | cdent | should be an easy merge | |
| 17:09:25 | mriedem | yeah i think alex asked for that test | |
| 17:09:34 | jaypipes | cdent: +2 from me. | |
| 17:09:35 | cdent | ah well, there it is | |
| 17:09:40 | cdent | cool, thanks | |
| 17:23:02 | dansmith | jaypipes: even with that typo? | |
| 17:23:43 | jaypipes | dansmith: hmm? | |
| 17:24:00 | dansmith | jaypipes: allocation_cadidates | |
| 17:24:03 | jaypipes | dansmith: cadidated? :) | |
| 17:24:09 | jaypipes | heh, yeah, just noticed that | |
| 17:24:23 | cdent | oh noes | |
| 17:24:26 | jaypipes | although I just typoed the typo. | |
| 17:24:26 | cdent | orz | |
| 17:24:53 | jaypipes | dansmith: it would have been fine if it had a parens on a single line. | |
| 17:25:48 | dansmith | jaypipes: so what you're saying is, you have low standards in general, right? | |
| 17:26:09 | jaypipes | dansmith: you're awfully ornery today. | |
| 17:33:51 | openstackgerrit | Matt Riedemann proposed openstack/nova master: xenapi: avoid unnecessary BDM query when building device metadata https://review.openstack.org/481162 | |
| 17:34:43 | openstackgerrit | Matt Riedemann proposed openstack/nova master: [placement] Improve allocation_candidates coverage https://review.openstack.org/481153 | |
| 17:34:50 | mriedem | there you go | |
| 17:49:09 | dansmith | mriedem: thanks now I can sleep tonight | |
| 17:51:23 | mriedem | just fyi, i lost all kinds of sleep last night over that task_state thing we talked about | |
| 17:51:54 | dansmith | heh | |
| 18:15:03 | cdent | jaypipes: are you around, I'm having some confusion over the format of the allocations requests in the candidates response | |
| 18:15:17 | cdent | this is what an allocation update looks like: https://review.openstack.org/#/c/470933/10/placement-api-ref/source/update-allocations-request.json | |
| 18:15:33 | cdent | it's a list of multiple providers | |
| 18:16:20 | jaypipes | cdent: right. | |
| 18:16:34 | jaypipes | cdent: and allocation candidates is a list of that HTTP request structure. | |
| 18:16:36 | cdent | but the output from allocation_candidates (by the docstring at least) is not | |
| 18:16:46 | jaypipes | (without the project_id and user_id of course, since it's not yet known) | |
| 18:16:57 | jaypipes | cdent: link? | |
| 18:17:26 | cdent | oh wait, I think maybe I'm just misreading the docstring on _transform_allocation_requests | |
| 18:17:43 | cdent | not sure | |
| 18:17:53 | cdent | I see a list of dicts | |
| 18:18:01 | cdent | but I'm expecting to see a list of lists of dicts | |
| 18:18:48 | cdent | https://github.com/openstack/nova/blob/master/nova/api/openstack/placement/handlers/allocation_candidate.py#L55 | |
| 18:18:51 | jaypipes | cdent: well, the allocation requests response part is a list of dicts, with the dicts having a single key "allocations" that itself is a list of dicts :) | |
| 18:19:09 | jaypipes | cdent: thus, matching the required request payload for PUT /allocations/{uuid} | |
| 18:19:48 | cdent | ah, so the word 'allocations' is repeated many times | |
| 18:19:51 | cdent | that's what threw me off | |
| 18:20:16 | jaypipes | cdent: yeah, I know :( | |
| 18:20:25 | jaypipes | cdent: it's just that's the payload of the request... | |
| 18:20:53 | jaypipes | cdent: the code originally didn't have that repeated allocations key thing but then I realized that wasn't actually what the HTTP payload needed :) | |
| 18:20:54 | cdent | except without the project and user it has to be cooked anyway | |
| 18:20:59 | jaypipes | ya | |
| 18:21:30 | cdent | this is probably not the best code for getting me back into a reviewing frame of mind. it is rather dense | |
| 18:21:53 | jaypipes | cdent: indeed. | |
| 18:22:02 | jaypipes | cdent: WELCOME BACK from PTO! :P | |
| 18:23:02 | cdent | I liked it out there in the world. I might have to go back. | |
| 18:28:22 | cdent | jaypipes: i left some comment on the scheduler side of using candidates (both patches). Overall it seems mostly sane (if a bit dense). instance_uuids is only ever greater than one if someone has requested N of the exact same thing, yes? So affinity doesn't come into play? | |
| 18:29:11 | jaypipes | cdent: correct. | |
| 18:29:28 | cdent | ✔ | |
| 18:47:45 | cdent | jaypipes, edleafe: has there been discussion or decision on whether the query parameter interfaces to /resource_providers and /allocation_candidates should/will have parity? | |
| 18:48:15 | cdent | related, edleafe, is this (filtering rps on traits) still a thing: https://review.openstack.org/#/c/474602/ | |
| 18:50:03 | edleafe | cdent: Heh, your guess is as good as mine. I'm not sure if the plan is still to add that for Pike | |
| 18:50:43 | edleafe | cdent: And if it is, it will have to be copied to the allocation code. | |
| 18:51:13 | cdent | I guess the more immediately salient question for edleafe is: are you still managing that patch? | |
| 18:51:21 | edleafe | cdent: yes | |
| 18:51:25 | cdent | cool, thanks | |
| 18:51:39 | cdent | i'm regrouping my links to things | |
| 18:52:09 | edleafe | cdent: I'm also not clear on whether the /resource_providers filtering is going to continue to be a supported thing | |
| 18:52:11 | mriedem | filtering by traits is definitely high risk at this point | |
| 18:52:24 | mriedem | i don't see why we'd add more to GET /resource_providers, | |