| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-06 | |||
| 15:09:25 | jaypipes | mriedem: well, yeah, but that depends on all the others :) | |
| 15:09:36 | mriedem | right | |
| 15:09:39 | mriedem | i see a few os-vif changes, | |
| 15:09:44 | mriedem | not sure which are related, they are all marked as bug fixes | |
| 15:16:41 | openstackgerrit | Andrey Volkov proposed openstack/nova master: [placement] Add api-ref for RP traits https://review.openstack.org/474550 | |
| 15:16:42 | openstackgerrit | Andrey Volkov proposed openstack/nova master: [placement] Add api-ref for usages https://review.openstack.org/480563 | |
| 15:16:42 | openstackgerrit | Andrey Volkov proposed openstack/nova master: [placement] Add api-ref for allocations https://review.openstack.org/470933 | |
| 15:16:42 | openstackgerrit | Andrey Volkov proposed openstack/nova master: [placement] Add api-ref for traits https://review.openstack.org/474186 | |
| 15:16:43 | openstackgerrit | Andrey Volkov proposed openstack/nova master: [placement] Make placement_api_docs.py failing https://review.openstack.org/480924 | |
| 15:16:44 | openstackgerrit | Andrey Volkov proposed openstack/nova master: [placement] Add api-ref for allocation_candidates https://review.openstack.org/481112 | |
| 15:16:44 | openstackgerrit | Andrey Volkov proposed openstack/nova master: [placement] Add api-ref for RP allocations https://review.openstack.org/450550 | |
| 15:16:44 | openstackgerrit | Andrey Volkov proposed openstack/nova master: [placement] Add api-ref for RP usages https://review.openstack.org/450105 | |
| 15:22:38 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: scheduler uses allocation candidates https://review.openstack.org/476631 | |
| 15:22:39 | openstackgerrit | Jay Pipes proposed openstack/nova master: WIP - placement: claim resources in scheduler https://review.openstack.org/476632 | |
| 15:24:28 | jaypipes | dansmith, mriedem, efried, bauzas: addressed all of your comments on https://review.openstack.org/476631 | |
| 15:24:42 | efried | just pulling it up, thanks. | |
| 15:25:05 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Pass the req_dest fielf of ReqSpec in the filter props https://review.openstack.org/481116 | |
| 15:25:44 | jaypipes | efried: I changed the code style to put every word and paren on its own line, just for you and dansmith. | |
| 15:25:52 | efried | Love it. | |
| 15:25:56 | jaypipes | heh | |
| 15:27:12 | dansmith | ) | |
| 15:27:12 | dansmith | jaypipes: (I hope you are kidding | |
| 15:27:27 | jaypipes | dansmith: no, | |
| 15:27:28 | jaypipes | not, | |
| 15:27:29 | jaypipes | kidding, | |
| 15:27:31 | jaypipes | ) | |
| 15:27:37 | jaypipes | dansmith: j | |
| 15:27:38 | jaypipes | k | |
| 15:28:06 | jaypipes | boom. | |
| 15:28:10 | jaypipes | mission accomplished. | |
| 15:29:17 | mriedem | some day someone will have to explain the kerfuffle from last week about ( | |
| 15:29:18 | mriedem | ) | |
| 15:29:18 | mriedem | this | |
| 15:30:49 | jaypipes | mriedem: basically, it makes dansmith and efried want to do this to my head: http://bit.ly/2tl79kj | |
| 15:31:11 | jaypipes | and edleafe :) | |
| 15:32:01 | openstack | Launchpad bug 1702454 in OpenStack Compute (nova) "Transforming the RequestSpec object into legacy dicts doesn't support the requested_destination field" [High,In progress] - Assigned to Sylvain Bauza (sylvain-bauza) | |
| 15:32:01 | bauzas | mriedem: dansmith: not sure you remembered our convo yesterday about https://bugs.launchpad.net/nova/+bug/1702454 but I just provided a fix https://review.openstack.org/481116 | |
| 15:32:13 | bauzas | mriedem: dansmith: targeted for backport to ocata and newton as well | |
| 15:32:48 | mriedem | jaypipes: well, just keep an eye out for when one of them do something similar with a dict or list and then you can drop the gd mfing hammer | |
| 15:33:24 | mriedem | bauzas: what is a "fielf"? | |
| 15:33:24 | jaypipes | mriedem: I'm a pacifist. | |
| 15:33:37 | efried | mriedem TL;DR: jaypipes has been indoctrinating himself in golang, where this kind of wasted vspace is acceptable, even encouraged. Which would be one thing if it matched the style of the code anywhere else in nova, but it doesn't. For dicts, yes. For lists, less so, but sometimes. For method calls, never. | |
| 15:33:38 | bauzas | mriedem: a covfefe | |
| 15:33:39 | jaypipes | mriedem: it's a field that dresses up at Christmas. | |
| 15:34:11 | edleafe | I suspect that jaypipes gets paid by LOC | |
| 15:34:22 | bauzas | then write Java | |
| 15:34:39 | mriedem | bauzas: comments inline | |
| 15:35:15 | bauzas | mriedem: <3 | |
| 15:35:17 | mriedem | efried: ok, but meh | |
| 15:35:32 | jaypipes | edleafe: erm, definitely not :) https://twitter.com/jaypipes/status/854680490485456896 | |
| 15:35:39 | mriedem | i know jay isn't using pycharm, but pycharm does that by default when dropping a line to add params to a method call | |
| 15:35:45 | jaypipes | vimftw | |
| 15:35:57 | mriedem | and some projects i've worked in in openstack actually enforce that format, like manila | |
| 15:36:03 | mriedem | i believe i was -1ed for not doing something like that | |
| 15:36:05 | mriedem | anywho | |
| 15:36:16 | efried | mriedem I use pycharm and don't even notice that I delete those extraneous newlines :) | |
| 15:36:27 | efried | Just happens automatically. | |
| 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 (2) https://review.openstack.org/452819 | |
| 15:43:04 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Factor out duplicated notification sample data https://review.openstack.org/452818 | |
| 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 | dansmith | vdrok: that might be a good reason to not run the gate job in multicell mode forever | |
| 16:29:47 | vdrok | gotcha | |