| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-06 | |||
| 15:36:40 | efried | you know, on this side of the keyboard. | |
| 15:37:01 | bauzas | is that really a thing ? | |
| 15:37:06 | bauzas | I mean, does it hurt ? | |
| 15:37:41 | cdent | dansmith: you made a sad face in a review about the thing this fixes, does it look good enough to you: https://github.com/cdent/gabbi/pull/215 | |
| 15:37:47 | bauzas | I tend to be more concerned by people not using a pattern like (foo,\n) | |
| 15:38:18 | bauzas | because gerrit would modify the line instead of adding a new one when you're adding a new key | |
| 15:38:19 | gibi | sfinucan, mriedem: hi! I fixed the comments in https://review.openstack.org/#/c/476538/ | |
| 15:39:32 | mriedem | i'm currently in cinder v3 attach mode now, going into tunnel vision | |
| 15:39:40 | mgagne | mriedem: I read your comments. I understand the technical challenge but it starts to fall outside my scope of expertise. I would need someone else to work on this specific task. | |
| 15:40:03 | mriedem | mgagne: ok, i can help work on the instance actions stuff later | |
| 15:40:06 | mgagne | mriedem: re in-use volume extend | |
| 15:40:15 | mgagne | sure, thanks! | |
| 15:41:34 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Pass requested_destination in filter_properties https://review.openstack.org/481116 | |
| 15:43:03 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Factor out duplicated notification sample data (3) https://review.openstack.org/452820 | |
| 15:43:04 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Factor out duplicated notification sample data https://review.openstack.org/452818 | |
| 15:43:04 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Factor out duplicated notification sample data (2) https://review.openstack.org/452819 | |
| 15:43:05 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Refactor instance.power-off notification samples https://review.openstack.org/475860 | |
| 15:48:40 | vdrok | dansmith: one more question about the multicell setup. we don't have to change the hash ring logic we have at https://github.com/openstack/nova/blob/master/nova/virt/ironic/driver.py#L539-L553 ? ServiceList will contain only computes from this cell's database? | |
| 15:57:04 | alaski | mriedem: I never tackled instance action finish times because there was enough complexity around it that I didn't feel that I could make it reliable. There are too many places where errors can occur and it will be easy to miss one, or have a new one added at some point and miss the instance action finish call. | |
| 15:57:29 | mriedem | vdrok: the GET /os-services API will iterate the cells | |
| 15:57:41 | mriedem | so you should get all services from all cells via the REST API | |
| 15:57:54 | alaski | it was optimistic to add that field in, and has just been a source of confusion since then | |
| 15:57:59 | mriedem | alaski: ok - we also decided to not go down that route | |
| 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 | |