| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-22 | |||
| 15:23:53 | eric-young | efried, yeah. silly mistake but it did expose something else. | |
| 15:24:44 | kashyap | efried: Yeah, I don't mind such bare pings. But prefer "dressed up" pings | |
| 15:24:49 | mriedem | you've been riedmeann'ed | |
| 15:24:55 | mriedem | gd i can't even spell my own name | |
| 15:24:56 | mriedem | ffs | |
| 15:25:17 | kashyap | mriedem: You slipped in "mean" there; I think they call it: "Freudian" | |
| 15:28:21 | sean-k-mooney | edleafe: just on the uuids its not a uuid anymore if you acept a string with our hypentens. if we decalre the filed as an int at the api then we could accpet 3c3770f6-e1a6-4c3c-ac1d-ba2aa2f231c4 as a hex int 3c3770f6e1a64c3cac1dba2aa2f231c4 | |
| 15:28:28 | mriedem | fyi all things are going to be blocked right now https://review.openstack.org/555314 | |
| 15:28:33 | mriedem | until ^ merges | |
| 15:29:32 | dansmith | efried: so, on this aggregate thing | |
| 15:30:17 | dansmith | efried: what if we had member_of=in:foo,bar&member_of=in:baz -- which would turn into (foo OR bar) AND baz | |
| 15:30:41 | dansmith | efried: that would let me have infinite filters that AND together several "any one of these would be fine for this requirement" | |
| 15:30:51 | jaypipes | cfriesen: I'm dead set against "implicit" or "hidden" resources. | |
| 15:31:41 | dansmith | efried: logically "tenant_aggregates AND az_aggregates AND gpu_aggregates AND shared_storage_aggregates" for some fictitious request with all those restrictions | |
| 15:31:52 | eric-young | mriedem, yes, that patch requires an unreleased version of os-brick. Is there a way to instigate a release or just wait? | |
| 15:32:39 | efried | dansmith: Sure, that seems simple-but-powerful. But we still need to address the question of whether to allow a queryparam key to be repeated. We haven't so far. | |
| 15:33:00 | bauzas | jianghuaw_: mriedem: FWIW, I filed a bug with a new 'vgpu' tag | |
| 15:33:05 | efried | cdent, edleafe: In your capacity as API SIGgers, what do you think? | |
| 15:33:06 | dansmith | efried: yeah, but it's a common thing for query strings, which is why we have it as a list right? | |
| 15:33:07 | bauzas | jianghuaw_: mriedem: https://bugs.launchpad.net/nova/+bug/1758086 | |
| 15:33:08 | openstack | Launchpad bug 1758086 in OpenStack Compute (nova) "nvidia driver limits to one single GPU per guest" [Low,Triaged] - Assigned to Sylvain Bauza (sylvain-bauza) | |
| 15:33:17 | bauzas | so we could track all VGPU related bugs | |
| 15:33:24 | efried | dansmith: I agree it's a common thing for query strings in general. But we've explicitly avoided doing it in placement so far. | |
| 15:33:34 | cdent | query parameter repetition is expected and normal, which is why under the covers the library return a list of values | |
| 15:33:37 | efried | Meaning you can break the API with that. | |
| 15:33:45 | dansmith | cdent: yeah, that | |
| 15:34:10 | dansmith | this: https://pastebin.com/pbgv9vux | |
| 15:34:33 | efried | Yeah yeah, I know it's supported by HTTP and the tooling. | |
| 15:34:40 | cdent | I'm more worried by what kind of impact this would have on already very challenging for mortals to understand query code | |
| 15:35:08 | cdent | s/query/database query/ | |
| 15:35:39 | efried | dansmith: correct me if I'm wrong, but we can't avoid crossing that bridge *somehow*. | |
| 15:35:58 | dansmith | efried: well, we can by just not doing things :) | |
| 15:36:11 | dansmith | but yeah, if we want it to be more than trivially useful... | |
| 15:36:13 | efried | I mean, we don't _have_ to implement it in a monster JOIN; we can do individual queries and do the set math in python. | |
| 15:36:58 | efried | So cdent/edleafe y'all don't have a problem introducing a repeatable queryparam key, where we've avoided them in the past? | |
| 15:37:35 | efried | e.g. resources=VCPU:3,MEMORY_MB:1024 instead of resources=VCPU:3&resources=MEMORY_MB:1024 -- if you do the latter, it does *not* work. | |
| 15:38:13 | edleafe | sean-k-mooney: the hyphens in a UUID are for humans. And Python doesn't require them: http://paste.openstack.org/show/708977/ | |
| 15:38:20 | cdent | well that's kind of the issue: if we're going to allow it in place A, it would be better to allow it all places | |
| 15:38:25 | edleafe | efried: reading back... | |
| 15:38:26 | efried | swhat I'm sayin | |
| 15:38:26 | dansmith | efried: and is that a microversion change or a bug? | |
| 15:38:43 | dansmith | the CGI guy in me says it is a bug | |
| 15:38:53 | efried | dansmith: Oh, definitely would be a microversion change, and no it's not a bug. | |
| 15:38:58 | dansmith | because I always forget and then have to fix my things :) | |
| 15:39:00 | dansmith | okay | |
| 15:39:04 | efried | dansmith: It's explicitly the way we designed the API. | |
| 15:39:20 | mriedem | eric-young: you could propose an os-brick release to the openstack/releases repo, | |
| 15:39:21 | dansmith | so I guess you need to decide what it means to split them like that | |
| 15:39:25 | efried | I brought it up like a year ago and someone (possibly cdent) assured me that it was the way things were intended. | |
| 15:39:26 | mriedem | eric-young: or i can, it's pretty easy, | |
| 15:39:30 | mriedem | then just need PTL sign off | |
| 15:39:46 | dansmith | whether you just merge them as if they were one argument, or make some other assumption about why the caller is doing that | |
| 15:39:51 | cdent | efried: i do not recall senator | |
| 15:39:51 | dansmith | as is the case in member_of | |
| 15:39:55 | efried | just so. | |
| 15:40:01 | dansmith | s/is/would be/ | |
| 15:40:21 | cdent | efried: currently how do repeated params get represented in req.GET | |
| 15:40:22 | efried | Or we can go with using punctuation join | |
| 15:40:30 | cdent | I think WebOb may be just "taking care of it" | |
| 15:40:41 | edleafe | efried: ok, repeating a query param is not a bad thing. It's pretty much the only way to AND things | |
| 15:40:43 | efried | cdent: nope, I remember checking that when I ran across this originally. | |
| 15:40:45 | cdent | in which case the doubling may be challenging | |
| 15:40:49 | eric-young | I'll take a look. no harm in me knowing how to do it :) | |
| 15:41:05 | bauzas | jaypipes: are you still available for an hangout ? | |
| 15:41:37 | efried | edleafe: Yeah, the issue is whether we deviate from the rest of the *placement* API specifically, which uses punctuation for lists, and does *not* support repeating keys. | |
| 15:41:53 | cdent | efried: you certain? https://docs.pylonsproject.org/projects/webob/en/stable/api/multidict.html?highlight=multidict | |
| 15:42:10 | efried | It's not about webob. It's about how we process in the handlers. | |
| 15:42:19 | efried | hold on, I'll find code. | |
| 15:43:19 | cdent | you should get the double list back on req.GET, but using items() (as done in RequestGroup parsing) may be throwing things off, dunno | |
| 15:44:39 | dansmith | cdent: efried edleafe: sorry I didn't think about this enough during spec review, but I hadn't gotten to the second use case in my head | |
| 15:45:04 | cdent | such is the way of the world, ain't no thing | |
| 15:45:19 | efried | cdent: Well, I can't immediately suss what the handler is doing, cause it clearly thinks it's getting a single string value back from req.GET. | |
| 15:46:23 | efried | it's possible that GET is special and returns a single value if there's only one, but a list if there's more than one. Which seems goofy, but sounds vaguely familiar. And you have to use something else, like GETALL, if you want it to be a list every time. | |
| 15:47:44 | efried | cdent: Oh, no, it looks like GET returns the first one, period. | |
| 15:48:05 | efried | ...where of course "first" could be anything, because dict hashing. | |
| 15:49:16 | cdent | so we know it's a fixable problem, but there's a fair bit of semantis wrangling associated with it | |
| 15:49:49 | cdent | dan wants a specific meaning out of two different member_of keys, which is different than the presumed concatenation of two resources keys | |
| 15:50:02 | cdent | it's that semantic difference of duplication that is a probelm | |
| 15:50:19 | cdent | (if it actually exists, I'm struggling to get my brain right on this because context switching) | |
| 15:51:41 | efried | cdent: "fixable problem" what are we talking about? IMO the fact that we don't accept multiple instances of qparam keys at the moment isn't a problem - it's just the way we designed it. | |
| 15:51:50 | dansmith | cdent: yeah, agree that member_of and resources should not behave in opposite ways | |
| 15:51:59 | efried | If we're talking about the actual issue dansmith is trying to solve, then yeah, fixable. | |
| 15:52:12 | efried | dansmith: So my suggestion was to use punctuation rather than duplicating qparam keys. | |
| 15:52:23 | efried | member_of=in:A,B;in:C | |
| 15:52:27 | dansmith | yeah, I like that less, fwiw | |
| 15:52:39 | dansmith | but it's fine if so | |
| 15:52:43 | efried | Oh, me too, but it doesn't make member_of and resources behave differently. | |
| 15:52:49 | dansmith | yeah | |
| 15:53:11 | efried | We can pick some other punctuation maybe. | |
| 15:53:26 | efried | But & and + both have special meaning already :( | |
| 15:53:34 | efried | (since 'AND' is what we're trying to express) | |
| 15:53:37 | dansmith | the symbol used doesn't really matter | |
| 15:53:38 | cdent | efried: "fixable problem" was the immediate thing of "being able to accept duplicates on keys in general". I agree that addressign dan's problem in the least disruptive way is probably syntax in the param | |
| 15:53:45 | dansmith | (to me) | |
| 15:53:49 | cdent | ; can't work | |
| 15:53:59 | cdent | it is equivalent to & (and actually more correct) | |
| 15:54:04 | jaypipes | bauzas: yes sir | |
| 15:54:10 | dansmith | cdent: in a url? really? | |
| 15:54:19 | cdent | but yeah, as long as we are consistent, doesn't matter | |
| 15:54:36 | cdent | dansmith: yeah cgi processing was modernized in the late 90s to use ; for split of params, but it never really took, but library are supposed to support it | |