| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-22 | |||
| 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 | dansmith | efried: and is that a microversion change or a bug? | |
| 15:38:26 | efried | swhat I'm sayin | |
| 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 | dansmith | as is the case in member_of | |
| 15:39:51 | cdent | efried: i do not recall senator | |
| 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 | |
| 15:54:47 | dansmith | huh, interesting | |
| 15:55:22 | cdent | it looks nicer too :) | |
| 15:55:50 | efried | okay, so ':'? | |
| 15:55:54 | efried | oh, no. | |
| 15:55:58 | efried | cause we're using that for in: | |
| 15:56:01 | efried | sigh | |
| 15:56:30 | dansmith | let's go super wacky and use a grave accent | |
| 15:56:39 | dansmith | didn't see that coming didja! | |
| 15:56:41 | cdent | unicode snowman | |
| 15:57:04 | efried | dànsmith | |
| 15:57:07 | efried | from now on | |
| 15:57:15 | dansmith | heh | |
| 15:57:37 | cdent | since the values of member_of can't have a space, why not a + (which is space)? | |
| 15:57:38 | dansmith | [08:57:29] Message(432): dànsmith Erroneous Nickname | |
| 15:57:40 | dansmith | bummer | |
| 15:57:49 | bauzas | jaypipes: argh, I have a meeting starting in 2 mins | |
| 15:58:06 | efried | cdent: + comes through as a space? That could work. | |
| 15:58:17 | jaypipes | bauzas: I'm free the rest of the day. just ping me when you're free. | |
| 15:58:19 | bauzas | jaypipes: I just want to make sure we can discuss on the direction for all the NUMA things before the next specs day | |
| 15:58:21 | efried | it's a bit hacky-overloady | |
| 15:58:25 | bauzas | jaypipes: okay, cool | |
| 15:58:26 | dansmith | do not like | |
| 15:58:27 | edleafe | cdent: what is the reason why you want to avoid using &? | |
| 15:58:36 | cdent | so we dont' have to encode it | |
| 15:58:39 | openstackgerrit | sahid proposed openstack/nova-specs master: libvirt: add support for virtio-net rx/tx queue sizes https://review.openstack.org/539605 | |
| 15:58:47 | cdent | and it wasn't me that was someone else | |