| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-22 | |||
| 18:32:59 | mriedem | they could just try to unlock it | |
| 18:33:01 | mriedem | get the 403 | |
| 18:33:03 | mriedem | like always | |
| 18:33:12 | dansmith | sure | |
| 18:33:15 | mriedem | if locked_by=other | |
| 18:33:16 | elbragstad | ^ that's what people do now with other APIs (not necessarily in nova) | |
| 18:33:28 | mriedem | then there is a reasonable guess they might not be able to unlock it | |
| 18:33:32 | mriedem | which the reason should tell them why it's locked | |
| 18:33:35 | dansmith | I dunno, I'm just having trouble following all the logic spaghetti, but I don't really need to care | |
| 18:34:02 | elbragstad | does the reason include something like "this was locked by an admin, pay your bill pls" | |
| 18:34:11 | gmann | yeah lock_reason can tell, "this is locked by admin/system and ask them to unlock after xyz condition/time" | |
| 18:34:23 | gmann | elbragstad: yeah, i think it can be | |
| 18:34:32 | dansmith | elbragstad: I know they do, and I'm sure it doesn't set off any alarms to hit 403s, but it feels like trying sudo vi /etc/passwd on a system to see if you can, and if not, it's reported :) | |
| 18:35:29 | gmann | IMO with lock_reason info in response can explain the locked_by things. till now we did not have lock_reason so may be locked_by was important to know | |
| 18:35:38 | elbragstad | yeah - true... the same argument has been made to have a capabilities-like api in keystone, but we're obviously not there yet, either | |
| 18:35:49 | dansmith | lock_reason is for humans, locked_by is for computers, IMHO | |
| 18:35:54 | dansmith | so not really a substitute | |
| 18:36:20 | mriedem | i think i'm going to go lock myself in the garage with the car running | |
| 18:36:38 | dansmith | elbragstad: last time I went jiggling door handles in my neighborhood to see who has theirs locked, I was asked to not do that | |
| 18:36:48 | elbragstad | make sure you set locked_by=owner | |
| 18:36:56 | dansmith | mriedem: unfortunately if you have a catalytic converter that's going to take a really long time | |
| 18:37:16 | gmann | dansmith: ok so computer purpose still can be fulfilled by locked_by=other|owner. | |
| 18:37:22 | dansmith | gmann: yes | |
| 18:37:34 | elbragstad | dansmith yeah - not the best u-x, i agree | |
| 18:38:15 | gmann | i am thinking exposing exact UUID of locked person (admin etc) can be security leak ? | |
| 18:38:50 | gmann | so just say you can unlock it or not via locked_by=owner|other seems appropriate for me now | |
| 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? | |