| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-22 | |||
| 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 | doesn't work, we've got an issue to work through. | |
| 19:27:26 | fried_rice | https://github.com/cdent/placecat/blob/d3241a6fb0d8701072986c169615787f7484a3b7/gabbits/trait-pairs.yaml#L109 | |
| 19:27:26 | fried_rice | yeah, because this | |
| 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 | dansmith | last I asked, fried_rice said it was waiting until after rc something | |
| 19:50:50 | EmilienM | +1 for rc2, thanks | |
| 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 | |
| 19:53:19 | fried_rice | since you had done it before | |
| 19:53:22 | melwitt | ok... I was just thinking if it's a regression it would be nice to fix it for stein ppl but if most think it should be train-only, then I'll go with the consensus | |
| 19:53:23 | dansmith | fried_rice: I haven't reviewed it in its current form and you said you'd ping me if you needed something | |
| 19:53:30 | fried_rice | okay. ping. | |
| 19:53:40 | dansmith | fried_rice: I'm not super comfortable with it at this point (I reviewed it initially a while ago) | |
| 19:53:57 | dansmith | so I say let melwitt do it if she thinks it's a good idea | |
| 19:54:00 | melwitt | cool gmann, thanks | |
| 19:54:24 | mriedem | i have to spend my requisite 2 hours per month to look at fixing https://launchpad.net/bugs/1790204 before writing up my monthly internal report... | |
| 19:54:25 | openstack | Launchpad bug 1790204 in OpenStack Compute (nova) "Allocations are "doubled up" on same host resize even though there is only 1 server on the host" [High,Triaged] | |
| 19:54:35 | dansmith | ten revisons ago and a week prior | |
| 19:55:30 | mriedem | honestly my +2 on that is mostly, (1) it's not in rc1, (2) it's eventlet and i'm not ever comfortable with eventlet stuff, (3) lots of people have been working on it and say it fixes the problem in a reproduction system so (4) i'm going to trust mdbooth on it | |
| 19:56:12 | fried_rice | yes, and I'm willing to do the same, but I wanted to give dansmith the opportunity to look at it again because he seemed to understand it (10 patch sets and a week ago). | |
| 19:56:15 | melwitt | yeah, I was going to say, that's the best my +2 could be too, for the same reasons | |
| 19:56:44 | melwitt | eventlet monkey patch ordering is not really my forte | |
| 19:56:48 | dansmith | fried_rice: don't wait on me | |
| 19:56:55 | fried_rice | okay. | |
| 19:57:32 | fried_rice | EmilienM: +A | |
| 19:58:12 | EmilienM | fried_rice: thank you | |
| 20:00:44 | mriedem | i'm still not really comfortable with pushing this into an rc2 | |
| 20:01:18 | mriedem | i'd be much cooler with landing it in train, and then if non-OSP people come along after stein GA saying they have the same issue (maybe zigo - he tends to tickle weird stuff like this), then we say ok let's backport and do a quick 19.0.1 on stable | |
| 20:02:09 | mriedem | or thode or coreycb | |
| 20:02:19 | mriedem | you know, other distro gremlins :) | |
| 20:02:33 | mriedem | i say that with the utmost affection | |