| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-22 | |||
| 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 | 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:49 | efried | jroll: This would be a pretty pervasive change, for IMO negative benefit. | |
| 16:01:49 | edleafe | jroll: impossible!! | |
| 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 | dansmith | sahid: ack, after the call | |
| 16:05:18 | efried | and | |
| 16:05:18 | efried | I'm opposed to making all the existing APIs accept repeated keys in addition to accepting their current syntax. | |
| 16:05:18 | efried | BUT | |
| 16:05:18 | efried | I love repeatable queryparam keys in general. | |
| 16:05:18 | efried | To be completely clear on my position: | |
| 16:05:19 | efried | I'm pretty neutral on making the (new) member_of key repeatable, even though it deviates from the norm. | |
| 16:05:22 | mriedem | if you're talking about AND semantics in the API, glance already has some for filtering https://developer.openstack.org/api-ref/image/v2/index.html#show-images | |
| 16:05:43 | sahid | dansmith: cool thanks | |
| 16:06:09 | dansmith | johnthetubaguy: ^ | |
| 16:06:12 | edleafe | sean-k-mooney: of course we should be strict in how we create and store them. But there is no harm in accepting a non-hyphenated UUID string - it's unambiguous | |
| 16:06:16 | cfriesen | jaypipes: I fully agree that it's resource consumption if the emulator thread is running "isolated". I'm just not sure it makes sense to use the "VCPU" resource given the name which strongly implies "virtual CPU". | |
| 16:06:23 | jroll | efried: that's fair | |
| 16:06:49 | openstackgerrit | Stephen Finucane proposed openstack/nova-specs master: Update spec to reflect reality https://review.openstack.org/555000 | |
| 16:06:52 | jaypipes | cfriesen: so what sean-k-mooney just said " normally the emulator tread floats over teh vcpus of the guest" is wrong then? | |
| 16:06:58 | sean-k-mooney | edleafe: i disagree it does cause harm as we need to have normalistion code | |
| 16:07:07 | efried | mriedem: Unfortunately I don't see anything in there that helps us in this case. | |
| 16:07:55 | cfriesen | jaypipes: normally the emulator threads are allowed to run on all the host cpus that the vCPU threads run on | |
| 16:07:56 | sean-k-mooney | jaypipes: also the emulator threads is libvirt specific so we have to be carful not to leak too much of the implentation details via the api | |
| 16:08:02 | johnthetubaguy | sahid: thanks for the quick turn around on that, taking a look at it again now | |