| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-22 | |||
| 15:17:57 | edmondsw | I remember reading that when it was new | |
| 15:18:22 | edmondsw | esberglu ^ | |
| 15:18:28 | kashyap | dansmith: At this point it warrants to be put in the channel topic ;-) | |
| 15:18:32 | dansmith | heh | |
| 15:18:42 | kashyap | "Evacuate", please see: $short-url | |
| 15:19:08 | kashyap | dansmith: Then you can start chiding people: "Don't you read channel topic?!" | |
| 15:19:29 | dansmith | kashyap: make a bot, that will waste more time | |
| 15:20:04 | kashyap | True; it reminds me of the bot on #fedora-devel, where if someone just says: | |
| 15:20:15 | kashyap | Person: Ping | |
| 15:20:17 | kashyap | Bot: https://fedoraproject.org/wiki/No_naked_pings | |
| 15:22:14 | efried | wow | |
| 15:22:19 | efried | TIL | |
| 15:22:29 | dansmith | efried: not everyone agrees with those assertions (like myself) | |
| 15:22:33 | efried | ...that some people are just too damn touchy | |
| 15:22:36 | dansmith | hehe | |
| 15:22:38 | dansmith | yeah that | |
| 15:22:52 | eric-young | efried: thanks for the quick edit on https://review.openstack.org/554679 | |
| 15:22:56 | mriedem | can we now say that nova people aren't as bad as fedora people? | |
| 15:23:07 | efried | eric-young: Yahyoubetcha | |
| 15:23:10 | eric-young | efried: I am seeing another issue right now, and am testing to see if it's just me | |
| 15:23:11 | mriedem | when it comes to the every 6 month nova hate-a-thon? | |
| 15:23:26 | efried | eric-young: Mm, I didn't test or anything, just fixed obvious problem. | |
| 15:23:51 | mriedem | eric-young: that requires a minimum os-brick right? | |
| 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 | |