| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-22 | |||
| 18:39:16 | gmann | for example exposing system admin id to end user etc | |
| 18:45:19 | openstackgerrit | melanie witt proposed openstack/nova-specs master: Move Stein implemented specs https://review.openstack.org/645749 | |
| 18:45:55 | melwitt | hm, wanted to get this other spec update done before moving specs but it's in merge conflict https://review.openstack.org/#/c/639033/1 | |
| 18:47:19 | mriedem | someone want to send this queens change through https://review.openstack.org/#/c/643219/ | |
| 18:47:23 | melwitt | er... I guess it's not. just somehow it makes the move specs patch in merge conflict | |
| 18:47:24 | mriedem | i'll start the release request | |
| 18:47:32 | mriedem | melwitt: i'll get that spec update | |
| 18:47:59 | melwitt | mriedem: thanks. I'll get the queens patch | |
| 19:01:14 | openstackgerrit | Merged openstack/nova-specs master: Update alloc-candidates-in-tree https://review.openstack.org/639033 | |
| 19:05:29 | openstackgerrit | Merged openstack/nova stable/pike: Fix bug case by none token context https://review.openstack.org/603044 | |
| 19:09:36 | temka | Uh, do we timestamp our logs in local time? | |
| 19:10:06 | fried_rice | dansmith: I thought to give more people time to look at it and comment. | |
| 19:11:02 | dansmith | fried_rice: roger | |
| 19:11:03 | fried_rice | dansmith: Also, the thing mriedem is working on with the multiattach capability has raised an interesting question that we're still working through. Namely, where do you put the required trait (which request group)? | |
| 19:11:21 | fried_rice | Not that that necessarily should hold up your spec, but it's giving me pause. | |
| 19:11:43 | mriedem | fried_rice: did you see my change on that patch? | |
| 19:11:46 | dansmith | yeah, would rather save that for implementation | |
| 19:11:47 | mriedem | i'm not using a request group anymore | |
| 19:12:00 | mriedem | i'm hitching a ride on the RequestSpec.flavor | |
| 19:12:20 | mriedem | cash, grass or ..., no traits ride for free | |
| 19:12:21 | fried_rice | mriedem: been afk for the past couple hours, if that's when you changed it. But eventually you're adding it to a request group, albeit maybe indirectly. | |
| 19:12:25 | dansmith | mriedem: I was trying to decide if I like or hate that | |
| 19:12:32 | mriedem | fried_rice: right indirectly | |
| 19:12:44 | openstackgerrit | melanie witt proposed openstack/nova-specs master: Move Stein implemented specs https://review.openstack.org/645749 | |
| 19:12:53 | dansmith | on the one hand it saves the "how do we request it" for the deeper layers, which might be good, | |
| 19:13:14 | fried_rice | on the other hand, it isn't part of the flavor | |
| 19:13:22 | dansmith | but also modifying the flavor, while it's the reason we added it and store it separately, strikes me as "this doesn't FEEL right" | |
| 19:13:37 | fried_rice | that's my gut too, but I haven't really thought about it | |
| 19:14:11 | mriedem | i did it for expediency b/c i couldn't figure out the semantics of the internal request group stuf | |
| 19:14:12 | mriedem | *stuff | |
| 19:14:34 | dansmith | yeah and the fact that you have to also worries me | |
| 19:14:41 | mriedem | it kept trying to add an empty numbered resources dict, and there are no resources in my request group | |
| 19:14:57 | mriedem | it's likely a bug in the resource request / group stuff internally | |
| 19:15:09 | fried_rice | where should it add it? | |
| 19:15:21 | mriedem | it was also just one of those, "oh hey i have like 2 hours left today to do something, how about i hack this together and see how it goes" thing | |
| 19:16:09 | dansmith | doesn't the base unnumbered group correspond to the whole request? | |
| 19:16:12 | mriedem | fried_rice: this is what i was getting | |
| 19:16:13 | mriedem | GET /placement/allocation_candidates?limit=1000&required1=COMPUTE_VOLUME_MULTI_ATTACH&resources=MEMORY_MB%3A512%2CVCPU%3A1&resources1= | |
| 19:16:21 | dansmith | something that is a trait on te host that is fundamental seems like it should be easy to add | |
| 19:16:22 | mriedem | and i'd get a 400 on that empty resources1 | |
| 19:16:43 | mriedem | the unnumbered resources there are from the flavor | |
| 19:16:48 | fried_rice | mhm, because the API refuses to allow you to specify requiredN without a corresponding resourcesN | |
| 19:16:53 | mriedem | the required1/resources1 were from the group i added | |
| 19:17:00 | mriedem | ok, | |
| 19:17:09 | fried_rice | so when whoever wrote that, they didn't see a need to not send the resourcesN through every time. | |
| 19:17:11 | mriedem | so the problem is the RequestGroup for the flavor gets built long after my code | |
| 19:17:40 | mriedem | i didn't want the requiredN, but i couldn't figure out how to not make it add the number | |
| 19:17:55 | dansmith | mriedem: right but they should be in the unnumbered one regardless of where they came from in this case | |
| 19:17:56 | fried_rice | right, but the problem is, where *do* you want to put the trait? | |
| 19:18:09 | mriedem | fried_rice: alongside the flavor | |
| 19:18:11 | mriedem | flavor group | |
| 19:18:23 | fried_rice | Okay, but if we say that, then we're *requiring* the VCPU/MEMORY_MB to come from the unnumbered group | |
| 19:18:30 | fried_rice | which is not (yet) a requirement otherwise. | |
| 19:18:39 | mriedem | *head explodes* | |
| 19:18:44 | dansmith | mriedem: if I cut the cat off your car can I sit in your garage with you? | |
| 19:18:50 | fried_rice | and it's going to explode (like mriedem's head) when we do numa. | |
| 19:19:03 | mriedem | dansmith: there is plenty of room, laura is at work | |
| 19:19:10 | mriedem | i'll get the lawn chairs down | |
| 19:19:18 | mriedem | no need, i've got one | |
| 19:19:29 | dansmith | even better, won't have to check a bag | |
| 19:19:59 | dansmith | indeed, but catalytic is so hard to type when you only have hours left on this planet | |
| 19:22:42 | fried_rice | So go with me on this: Can't I theoretically today put resources1:VCPU=1, resources1:MEMORY_MB:2048 into my flavor extra specs? And it'll ignore the base flavor values for vcpus and ram? | |
| 19:23:56 | fried_rice | down the road, I'll get a request with no unnumbered group | |
| 19:24:17 | fried_rice | so I'll have required=MULTIATTACH but no resources=* | |
| 19:24:32 | fried_rice | which I think will result in the same failure | |
| 19:26:12 | mriedem | clearly we have outsmarted ourselves | |
| 19:26:15 | mriedem | mission accomplished | |
| 19:27:26 | fried_rice | yeah, because this | |
| 19:27:26 | fried_rice | https://github.com/cdent/placecat/blob/d3241a6fb0d8701072986c169615787f7484a3b7/gabbits/trait-pairs.yaml#L109 | |
| 19:27:26 | fried_rice | doesn't work, we've got an issue to work through. | |
| 19:27:45 | fried_rice | I have to go do phone things now :( | |
| 19:32:55 | mriedem | whole bunch of stable/pike changes we could move through https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/pike+label:Code-Review=1 | |
| 19:33:15 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Refix disk size during live migration with disk over-commit https://review.openstack.org/631372 | |
| 19:36:17 | elbragstad | i assume by previous the previous discussion, capabilities in nova stalled out? | |
| 19:47:40 | EmilienM | hi | |
| 19:47:53 | EmilienM | we need https://review.openstack.org/#/c/626952/ in Stein, please | |
| 19:48:19 | mriedem | elbragstad: yup | |
| 19:48:21 | EmilienM | if https://review.openstack.org/#/c/626952/ doesn't land, we'll have to carry that patch downstream | |
| 19:48:28 | EmilienM | we can't deploy Nova with SSL atm | |
| 19:48:37 | EmilienM | not sure why it's being postponed to Train, really | |
| 19:48:41 | gmann | melwitt: ack your comment on policy improvement spec. I am doing QA release things today. I will ping you on monday to discuss that and probably next plan. | |
| 19:48:49 | EmilienM | melwitt ^ | |
| 19:49:25 | elbragstad | mriedem is the main reason just because there aren't enough people to work on it or was it something else? i tried looking for a spec in review to find the answer but didn't see any | |
| 19:50:17 | melwitt | EmilienM: I don't think it's being postponed, should go into rc2. were you ok with that mriedem? | |
| 19:50:48 | mriedem | melwitt: idk about rc2. mdbooth said as long as it's merged on master (Train) he's happy to backport internally rather than upstream. | |
| 19:50:50 | EmilienM | +1 for rc2, thanks | |
| 19:50:50 | dansmith | last I asked, fried_rice said it was waiting until after rc something | |
| 19:50:56 | dansmith | right, that ^ | |
| 19:50:57 | melwitt | oh | |
| 19:51:01 | dansmith | but I really don't know | |
| 19:51:04 | EmilienM | I would rather avoid downstream only backports | |
| 19:51:13 | EmilienM | but I don't really care as I don't maintain this rpm downstream | |
| 19:51:19 | mriedem | and i'd rather avoid putting some crazy eventlet thing in rc2 that we don't see in the gate | |
| 19:51:27 | EmilienM | it's just ugly that the rest of users will have the same issue as we have | |
| 19:51:51 | melwitt | from what mdbooth said it is a regression though, for those running an unlucky combo of package versions right | |
| 19:51:54 | mriedem | we gate on bionic which is py36 and don't see this upstream in CI, so i can't explain the difference | |
| 19:52:04 | mriedem | yeah maybe | |
| 19:52:08 | mriedem | i've not followed the ML thread | |
| 19:52:11 | dansmith | mdbooth also said it was fine for train | |
| 19:53:01 | fried_rice | dansmith: At this point I'm waiting for you to re+2 | |