| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-22 | |||
| 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 | |
| 15:58:56 | edleafe | cdent: no, I mean multiple query params | |
| 15:59:15 | efried | edleafe: Because we don't support repeating queryparams elsewhere in the API where it would also make sense. E.g. resources= | |
| 15:59:29 | efried | and the inconsistency would make sadness | |
| 16:00:11 | efried | edleafe: e.g. resources=VCPU:3&resources=MEMORY_MB:1024 | |
| 16:00:19 | efried | ^ does not work. | |
| 16:00:41 | edleafe | efried: there isn't a good reason why it shouldn't | |
| 16:01:08 | efried | edleafe: other than that the code isn't set up to make it work. | |
| 16:01:22 | efried | If we wanted to support that, we would have to make code changes. | |
| 16:01:30 | jroll | if only we knew someone that could change code :) | |
| 16:01:49 | edleafe | jroll: impossible!! | |
| 16:01:49 | efried | jroll: This would be a pretty pervasive change, for IMO negative benefit. | |
| 16:01:49 | sean-k-mooney | edleafe: that is correct python does not require them to have hyphens but https://tools.ietf.org/html/rfc4122 spcifies the reqiurements for the string representation on page 4 which reuires the use of - when serialising the uuid as a string to be standars complient | |
| 16:01:51 | dansmith | jroll: are you helping? :) | |
| 16:02:13 | efried | Now we've got two different ways to express the same thing - double the test matrix, double the bugs, etc. | |
| 16:02:14 | cfriesen | jaypipes: the emulator threads and I/O threads are separate from the vcpu threads, so it seems odd to make the user ask for a "VCPU" to run them on. | |
| 16:02:20 | jroll | dansmith: I'd be happy to make that work, it seems silly that it doesn't :) | |
| 16:02:42 | dansmith | jroll: no, I mean helping by taking shots from the stands.. and I'm just joking of course :) | |
| 16:02:49 | jroll | I can do that too :P | |
| 16:02:58 | sahid | mriedem: btw i updated the vf trusted spec to address your suggestion about metadata | |
| 16:02:59 | dansmith | heh | |
| 16:03:18 | mriedem | sahid: ok | |
| 16:03:19 | jaypipes | cfriesen: it's all just a processor, IMO. | |
| 16:03:27 | jaypipes | cfriesen: either dedicated or shared CPU resource. | |
| 16:03:29 | jroll | I'm just casting my vote for having the key twice in the url being the sane thing to do imho ¯\_(ツ)_/¯ | |
| 16:03:57 | jaypipes | cfriesen: if the emulator thread is dedicated to a physical host CPU, I really don't understand why that isn't considered a "resource consumption". | |
| 16:04:00 | dansmith | jroll: for member_of you mean? I agree, that's what I like the best for my use case | |
| 16:04:26 | jroll | dansmith: yep | |
| 16:04:31 | sean-k-mooney | cfriesen: well normally the emulator tread floats over teh vcpus of the guest so they dont have to ask for extra cpus if they want that behavior | |
| 16:05:06 | sahid | dansmith: i updated tx/rx queue spec I hope you can have a look so I could address any issues | |
| 16:05:18 | efried | To be completely clear on my position: | |
| 16:05:18 | efried | I love repeatable queryparam keys in general. | |