*** macjack has quit IRC | 00:00 | |
*** witlessb has quit IRC | 00:14 | |
*** georgem2 has joined #openstack-sahara | 01:21 | |
openstackgerrit | Ken Chen proposed openstack/sahara: Add ZooKeeper support to CDH plugin https://review.openstack.org/132559 | 01:28 |
---|---|---|
openstackgerrit | lu huichun proposed openstack/sahara: Add HBase support to CDH plugin https://review.openstack.org/133599 | 01:52 |
*** tellesnobrega has joined #openstack-sahara | 02:32 | |
*** tellesnobrega has quit IRC | 02:41 | |
*** georgem2 has quit IRC | 02:53 | |
*** witlessb has joined #openstack-sahara | 02:56 | |
*** witlessb has quit IRC | 03:01 | |
*** Longgeek has joined #openstack-sahara | 03:28 | |
*** Longgeek has quit IRC | 03:33 | |
*** Longgeek has joined #openstack-sahara | 04:44 | |
*** Longgeek has quit IRC | 04:48 | |
*** chandankumar has joined #openstack-sahara | 05:20 | |
*** Longgeek has joined #openstack-sahara | 05:37 | |
*** hogepodge has quit IRC | 06:01 | |
*** Longgeek has quit IRC | 06:17 | |
*** Longgeek has joined #openstack-sahara | 06:18 | |
*** Longgeek_ has joined #openstack-sahara | 06:18 | |
*** miqui has quit IRC | 06:22 | |
*** Longgeek has quit IRC | 06:22 | |
*** hogepodge has joined #openstack-sahara | 06:24 | |
*** nikunj2512 has joined #openstack-sahara | 06:27 | |
nikunj2512 | Hi | 06:27 |
nikunj2512 | i am getting error while getting data from sahara service | 06:28 |
nikunj2512 | Error: Failed to find some config files: policy.json | 06:28 |
openstackgerrit | lu huichun proposed openstack/sahara: Add HBase support to CDH plugin https://review.openstack.org/133599 | 06:51 |
*** Longgeek_ has quit IRC | 06:56 | |
*** Longgeek has joined #openstack-sahara | 06:57 | |
*** miqui_ has quit IRC | 07:22 | |
*** Longgeek has quit IRC | 07:27 | |
*** Longgeek has joined #openstack-sahara | 07:28 | |
*** Longgeek_ has joined #openstack-sahara | 07:41 | |
*** Longgeek has quit IRC | 07:45 | |
*** witlessb has joined #openstack-sahara | 08:54 | |
*** IvanBerezovskiy has joined #openstack-sahara | 09:06 | |
*** skolekonov has joined #openstack-sahara | 09:19 | |
openstackgerrit | Vitaly Gridnev proposed openstack/sahara: Add provision step in creating cluster with direct engine https://review.openstack.org/134490 | 09:35 |
*** chandankumar has quit IRC | 10:56 | |
*** chandankumar has joined #openstack-sahara | 11:08 | |
*** openstackgerrit has quit IRC | 11:48 | |
*** openstackgerrit has joined #openstack-sahara | 11:49 | |
openstackgerrit | Denis Egorenko proposed stackforge/sahara-ci-config: Fix wrong update image for CDH plugin https://review.openstack.org/134912 | 11:54 |
*** nikunj2512 has quit IRC | 12:04 | |
*** witlessb has quit IRC | 12:19 | |
*** witlessb has joined #openstack-sahara | 12:20 | |
*** nikunj2512 has joined #openstack-sahara | 12:39 | |
openstackgerrit | Vitaly Gridnev proposed openstack/sahara: Add provision step in creating cluster with direct engine https://review.openstack.org/134490 | 12:40 |
*** georgem2 has joined #openstack-sahara | 12:58 | |
openstackgerrit | Sergey Reshetnyak proposed openstack/sahara: Add list of open ports for Spark plugin https://review.openstack.org/134927 | 13:09 |
*** Networkn3rd has joined #openstack-sahara | 13:33 | |
*** k4n0_ has quit IRC | 13:39 | |
*** georgem2 has quit IRC | 13:45 | |
*** _crobertsrh is now known as crobertsrh | 13:48 | |
openstackgerrit | Sergey Reshetnyak proposed openstack/sahara: Add list of open ports for Spark plugin https://review.openstack.org/134927 | 13:52 |
openstackgerrit | Vitaly Gridnev proposed openstack/sahara-specs: Added specification for event log and logs improvements https://review.openstack.org/119052 | 13:55 |
*** _mattf` is now known as mattf | 13:58 | |
*** mattf has quit IRC | 13:58 | |
*** mattf has joined #openstack-sahara | 13:58 | |
*** tellesnobrega has joined #openstack-sahara | 14:05 | |
*** miqui has joined #openstack-sahara | 14:10 | |
*** georgem2 has joined #openstack-sahara | 14:15 | |
*** tellesnobrega has quit IRC | 14:15 | |
openstackgerrit | Merged stackforge/sahara-ci-config: Fix wrong update image for CDH plugin https://review.openstack.org/134912 | 14:28 |
*** tellesnobrega has joined #openstack-sahara | 14:28 | |
openstackgerrit | Merged openstack/sahara: Add list of open ports for HDP plugin https://review.openstack.org/134182 | 14:31 |
*** tellesnobrega has quit IRC | 14:32 | |
*** tmckay has joined #openstack-sahara | 14:32 | |
*** egafford has joined #openstack-sahara | 14:40 | |
*** georgem2 has quit IRC | 14:43 | |
*** tmckay has quit IRC | 14:45 | |
*** chandankumar has quit IRC | 14:47 | |
openstackgerrit | Sergey Reshetnyak proposed openstack/sahara: Add list of open ports for Spark plugin https://review.openstack.org/134927 | 14:48 |
*** Longgeek_ has quit IRC | 14:59 | |
*** tmckay has joined #openstack-sahara | 15:07 | |
openstackgerrit | Andrey Pavlov proposed openstack/sahara: Fixed bug with Hive jobs fail https://review.openstack.org/133952 | 15:48 |
*** georgem2 has joined #openstack-sahara | 15:51 | |
tmckay | crobertsrh, ping | 15:57 |
crobertsrh | yes? | 15:57 |
tmckay | did you say on Friday you had a spec for filtering, or did I imagine that? My (possibly lame) search didn't turn up anything | 15:58 |
crobertsrh | https://review.openstack.org/#/c/134319/ | 15:59 |
tmckay | really?? Why didn't my search find that ... thanks | 15:59 |
crobertsrh | heh | 15:59 |
tmckay | oh, duh. There is more than one page of results | 16:00 |
tmckay | egafford, congrats, your spec apparently was merged :) | 16:03 |
tmckay | cooking with gas now | 16:04 |
egafford | tmckay: Indeed; first OSS merge! Starting small, but that's good, really. | 16:05 |
egafford | tmckay: I'm very fond of the workflow. It's head and shoulders above any review process I've seen in private software. | 16:05 |
crobertsrh | Yeah, I <3 the gerrit review process | 16:06 |
tmckay | egafford, I completely agree. Sahara is some of the cleanest code I've worked on in years | 16:06 |
*** nikunj2512 has left #openstack-sahara | 16:06 | |
tmckay | Long live Gerrit and OpenStack! Huzzah! | 16:06 |
* tmckay waves (red) hat wildly | 16:06 | |
egafford | crobertsh, tmckay: Oh my goodness yes. I've pointed some of my old team at the codebase, basically saying "you know all that stuff I was ranting about all year re: legibility? Look at this. Particularly the API in which every method is a 1-2 liner with 3 decorators on it." | 16:07 |
egafford | crobertsh, tmckay: Beautiful stuff. | 16:08 |
tmckay | croberts, so do you have detail on the "query-style parameters" in search_opts for filtering? What do they look like? | 16:12 |
tmckay | I'm wondering if we need to do anything with them, or if we can just pass them through to the alembic layer stuff | 16:12 |
tmckay | "== foo", "> foo", "<= foo", things like that? | 16:13 |
tmckay | crobertsrh even ^^ | 16:13 |
crobertsrh | I was thinking of url-style query parameters: <uri>?<name>=<val> | 16:14 |
tmckay | ah | 16:14 |
crobertsrh | I'm open to suggestions though. | 16:14 |
tmckay | is = enough? | 16:14 |
tmckay | is that what other OS projects are doing? | 16:14 |
crobertsrh | I took a peek at what nova has for its filters | 16:14 |
tmckay | I should take a look too | 16:15 |
crobertsrh | I think SergeyLukjanov was mostly thinking about the ability to filter by name/plugin | 16:15 |
crobertsrh | We don't really have a lot of numbers to filter by | 16:15 |
tmckay | hmm, true. | 16:16 |
crobertsrh | It looks like other pages really only support single field queries (UI-wise). Although, it would be possible to specify multiple name/values via the client lib or REST | 16:17 |
tmckay | on line 71 of your spec, did you mean to include a list of methods? Or does the second sentence cover it? | 16:18 |
SergeyLukjanov | crobertsrh, ack about name/plugin/version | 16:19 |
SergeyLukjanov | crobertsrh, and I think it's done on client side for all projects | 16:19 |
SergeyLukjanov | crobertsrh, I mean filtering done in client side in the list operation of the python-NNNclient | 16:19 |
tmckay | SergeyLukjanov, really, not a filter on the database get? | 16:20 |
tmckay | That would be the most efficient, in sahara-api | 16:21 |
tmckay | Although it's more work. But then it's an optional part of the REST API, and the client can just pass the filter parameters through | 16:22 |
elmiko | crobertsrh: something else to consider, if you want more eyeballs on the api changes use the APIImpact flag in your commit message and we can get word to the API working group to weigh in | 16:23 |
tmckay | elmiko, thanks for the heads up | 16:24 |
*** skolekonov has quit IRC | 16:24 | |
elmiko | np, i know those folks are looking for opportunities to help | 16:24 |
crobertsrh | I do have the apiimpact flag in there | 16:28 |
elmiko | crobertsrh: cool, i thought you did but couldn't remember | 16:29 |
*** georgem2 has quit IRC | 16:29 | |
elmiko | if they don't chime in before wednesday i'll make sure to bring it up at their meeting | 16:30 |
elmiko | or, you can always email the openstack-dev ml with [api] in the subject to ping them | 16:30 |
elmiko | i know there is a little debate currently as to how active they want to get in searching for new reviews to jump on | 16:30 |
crobertsrh | It does seem that filtering in the client only is a bit wasteful. | 16:32 |
elmiko | yea, that's a lot of data coming back that might go unused | 16:33 |
tmckay | crobertsrh, looking at the nova client. It passes search_opts to cs.xxx.list in several places | 16:33 |
tmckay | The question is, what kind of object is cs? | 16:33 |
tmckay | Is it an interface to the REST API? If so, we have a precedent | 16:34 |
tmckay | It's silly imho to filter outside of a database when that is what a database is for | 16:34 |
*** chandankumar has joined #openstack-sahara | 16:34 | |
crobertsrh | +1 on silly | 16:34 |
tmckay | besides, if it's behind the client, it's transparent to things consuming the client anyway | 16:34 |
elmiko | tmckay: agreed, seems like the params should get passed on to the rest server | 16:34 |
tmckay | so it shouldn't matter | 16:34 |
crobertsrh | extra bonus, any consumers of the api itself can also use filtering | 16:35 |
tmckay | I just have to track down what this "cs" is. Probably the debugger is the easiest way :) | 16:35 |
tmckay | crobertsrh, ++. There would have to be a very compelling reason not to do it in sahara-api, I think | 16:35 |
elmiko | crobertsrh: i thought that's the way it _supposed_ to be | 16:35 |
crobertsrh | Nova client passes it to the REST API.... return self._list("/servers%s%s" % (detail, query_string), "servers") | 16:35 |
* tmckay goes to debug nova client | 16:36 | |
crobertsrh | That is from novaclient/v1_1/servers.py line 603 | 16:36 |
tmckay | ah, there you go | 16:37 |
tmckay | I was looking in v3, I think. I'll check anyway, more info is better | 16:37 |
crobertsrh | ah, I suppose they could have changed things over time | 16:38 |
SergeyLukjanov | tmckay, crobertsrh, I'm waiting for plain, so, unable to chat atm | 16:41 |
SergeyLukjanov | tmckay, crobertsrh, and I'm on a vacation this week :) | 16:41 |
tmckay | SergeyLukjanov, np, good travels :) | 16:41 |
crobertsrh | No worries. Have fun | 16:41 |
tmckay | SergeyLukjanov, don't worry, we'll make something great :) And you can +2 or -2 | 16:41 |
SergeyLukjanov | tmckay, crobertsrh, but re filtering - IMO it should be done first on the client side in the way to be able to implement it on server side and replace client side filtering with the new server side one | 16:42 |
SergeyLukjanov | tmckay, crobertsrh, to avoid additional efforts needed to refactor server side to support filtering and concentrate on the more important stuff | 16:42 |
SergeyLukjanov | my 2 cents | 16:42 |
SergeyLukjanov | heh, moving to Geneva from Paris | 16:43 |
tmckay | hmm, I could see that. It would free up UI guys sooner | 16:43 |
tmckay | crobertsrh, if we do client support first, the UI stuff can be verified and tests written, and then you are free to chase something else | 16:44 |
tmckay | certain amount of throw away, but there is a logic to it. UI work seems heavy for kilo | 16:45 |
crobertsrh | True, but will we ever circle back to "do it right"? | 16:45 |
tmckay | I will, for sure. Immediately. | 16:45 |
tmckay | If we know it's temporary, then it can just be a simple application of the dictionary against the list coming back. | 16:45 |
tmckay | It can even be sloppy | 16:46 |
elmiko | yea, tough issue... | 16:46 |
crobertsrh | I don't think we ever want to release a temporary/sloppy client, do we? | 16:46 |
tmckay | not usually a fan of temporary measures, but in this case ... | 16:47 |
* tmckay shrugs | 16:47 | |
crobertsrh | Maybe we can figure the effort involved in each and make a decision based on that | 16:47 |
elmiko | i guess, i'd like to know more about the extent of changes needed to add server-side filtering | 16:47 |
tmckay | ack | 16:47 |
crobertsrh | Right. That is where I'm most uncertain | 16:47 |
tmckay | alright, let's keep evaluating. I bet I can mock something up this week on the server side, see how much effort it is | 16:48 |
tmckay | crobertsrh, on the other hand, if you write code against a modified (unreleased) client and we just verify that you pass the right stuff in, then you can go your merry way | 16:49 |
tmckay | the client can just dump it on the floor | 16:49 |
crobertsrh | That's what I figured I'd wind-up doing for starters. | 16:50 |
tmckay | we just need to know the interface works for you to be done and move on | 16:50 |
tmckay | that part at least isn't throw away | 16:50 |
tmckay | k, late binding. Let's go that way, we don't have to make a decision yet | 16:50 |
*** chandankumar has quit IRC | 17:03 | |
openstackgerrit | Andrey Pavlov proposed openstack/python-saharaclient: Added unit tests for python bindings https://review.openstack.org/134167 | 17:05 |
openstackgerrit | Andrey Pavlov proposed openstack/sahara: Fixed bug with Hive jobs fail https://review.openstack.org/133952 | 17:10 |
openstackgerrit | Sergey Reshetnyak proposed openstack/sahara: Add list of open ports for Spark plugin https://review.openstack.org/134927 | 17:13 |
*** shakamunyi has joined #openstack-sahara | 17:32 | |
*** shakamunyi has quit IRC | 17:32 | |
*** chandankumar has joined #openstack-sahara | 17:38 | |
openstackgerrit | Sergey Kolekonov proposed stackforge/sahara-ci-config: Fix node label for ui tests https://review.openstack.org/135033 | 17:44 |
*** stannie has quit IRC | 17:48 | |
*** chandankumar has quit IRC | 18:25 | |
tmckay | crobertsrh, so, playing with the /images API which supports query strings, and hacking the client, this works" | 20:21 |
tmckay | '/images?tags=1.2.1&tags=vanilla' | 20:21 |
crobertsrh | Awesome | 20:22 |
tmckay | so we could support a multidict in the client, or a simple dict | 20:22 |
tmckay | crobertsrh, in the case of tags it's actually written to support a multidict. | 20:23 |
tmckay | but, if we're just supporting name=x and plugin=x then a simple dict will work | 20:23 |
tmckay | or, we could take a list of tuples if a multidict isn't an option | 20:23 |
crobertsrh | Well, then the question is: do we also want to handle pagination, etc "while we're in there" | 20:23 |
crobertsrh | I suppose pagination n/v can also just be in the simple dict | 20:24 |
elmiko | i'd say start simple and build up | 20:24 |
crobertsrh | just special n/v pairs | 20:24 |
elmiko | do filtering now, add pagination in another spec. imo | 20:24 |
tmckay | yeah, I'm a newbie to pagination in REST. special n/v makes sense to me, but maybe it's not done that way :) | 20:24 |
tmckay | elmiko, there is some wisdom in that | 20:25 |
tmckay | crobertsrh, do we want to support a multidict scenario, as for tags? Things where a field might be a list? For name/plugin it's certainly not | 20:25 |
crobertsrh | I can't really think of a use case for it. | 20:26 |
tmckay | or, we could have the convention that we just interpret a list value for a key as key=n&key=m&key=l | 20:26 |
elmiko | how do other projects do it? | 20:26 |
tmckay | elmiko, don't know. the tags thing is the only instance in Sahara, and even then a multiple value field is an outlier | 20:27 |
tmckay | I suppose we can look elsewhere | 20:27 |
crobertsrh | Based on the nova client lib, I don't see lists implemented there. The REST side might tell otherwise though | 20:28 |
elmiko | yea, i'm trying to think what other projcets use a list like that | 20:28 |
tmckay | for a simple dict, I just need to add a loop that tacks on ?key=value&key2=value2& .... | 20:28 |
tmckay | usable for any URL | 20:28 |
tmckay | I don't even think it will break Sahara to pass it in, they'll just be ignored | 20:29 |
tmckay | brb | 20:29 |
elmiko | i would think in the case of tags you'd want "...?key=v1,v2,v3&anotherkey=..." but that's just a guess | 20:29 |
tmckay | the decorator for images_list is just this | 20:29 |
tmckay | @rest.get('/images') | 20:29 |
tmckay | @acl.enforce("images:get_all") | 20:29 |
tmckay | nothing special there | 20:30 |
tmckay | elmiko, based on hacking the client and running Sahara in the deugger you repeat "tags" as a key (tags=1&tags=2) | 20:30 |
tmckay | this does the right thing | 20:30 |
elmiko | ok | 20:30 |
tmckay | not intuitive to me, but that's how the parser works | 20:31 |
elmiko | i'm thinking more about how the api call should look, less about the backend. i'm curious from a high level how it should look. | 20:31 |
tmckay | and you pull it out with args.getlist('tags'), args.get('tags') will just give you one :) | 20:31 |
crobertsrh | I think that's a fairly common interpretation of same name/different vals in a URL | 20:32 |
tmckay | that is how it looks in the api call | 20:32 |
tmckay | That's what flask allows, unless we parse the string ourselves and split on comma | 20:32 |
elmiko | crobertsrh: not using multiple values per key? | 20:32 |
tmckay | crobertsrh, that's the way cumin did it. Enough said :-D | 20:32 |
elmiko | tmckay: i'm just trying to decouple the rest api call from the wsgi framework we happen to be using | 20:32 |
crobertsrh | name=myfirstval&name=mysecondval --> name = [myfirstval, mysecondval] | 20:33 |
crobertsrh | I hear that cumin was amazing | 20:33 |
elmiko | crobertsrh: yea, if that's good form then cool | 20:33 |
tmckay | elmiko, ack, I hear you. I think it's standard, though. We should verify | 20:33 |
elmiko | tmckay: agreed | 20:33 |
tmckay | ok, really brb | 20:33 |
crobertsrh | It does ring a bell of something that is "standard" | 20:33 |
elmiko | cool | 20:34 |
elmiko | yea i don't really know what the "standard" is, i just want to avoid shaping the call based on our framework. seems like a leaky abstraction in that case. | 20:35 |
tmckay | http://www.w3schools.com/asp/coll_querystring.asp | 20:43 |
tmckay | Example 1 | 20:43 |
tmckay | n=John&n=Susan | 20:44 |
elmiko | to be fair though, that's for an asp.net application | 20:45 |
tmckay | based on a quick search, the form seems to be pretty much accepted. What varies is how the framework returns the values. | 20:48 |
tmckay | so flask has get and get_list, another framework might just return a list from get. But it sounds like the form is expected | 20:49 |
*** openstackgerrit has quit IRC | 20:49 | |
*** openstackgerrit has joined #openstack-sahara | 20:49 | |
elmiko | tmckay: cool, i don't have any issue with the formatting, other than using the more common method(regardless of our framework) | 20:50 |
tmckay | crobertsrh, so which "list()" ops do you want to implement this for? all of them? | 20:51 |
crobertsrh | I think we should probably do all just to stay consistent | 20:51 |
elmiko | +1 | 20:51 |
crobertsrh | Unlikely that plugins really needs it, but.... | 20:51 |
tmckay | okay. Anything that can be listed from the client. Got it. I'll start banging on a client patch. | 20:52 |
tmckay | Unless you've done it already | 20:52 |
crobertsrh | No, I have not yet patched the client. | 20:52 |
tmckay | k. Do you want to, or should I? | 20:52 |
tmckay | I guess it's all the same, it gets you off the task either way | 20:53 |
crobertsrh | I can take care of the client part | 20:53 |
tmckay | k | 20:53 |
crobertsrh | So, each client list() method gets a new param. What should we call it? | 20:53 |
tmckay | search_opts seems to be standard in OS | 20:53 |
crobertsrh | I think the spec used "search_opts" | 20:53 |
tmckay | yep | 20:53 |
crobertsrh | And then one new method in api.base that will take the searchopts dict and convert to ?<name>=value&..... | 20:55 |
crobertsrh | each of the list() client methods can just call that and form the full query string /<object_type>?<query string> | 20:56 |
crobertsrh | ...which will just fall on deaf ears for now until the backend is updated | 20:56 |
tmckay | absolutely | 20:57 |
tmckay | just where I was going to go. We must be right :) | 20:57 |
crobertsrh | Heh :) | 20:58 |
tmckay | on an unrelated note, I heard "Dumb and Dumber To" was a big hit this weekend | 20:58 |
crobertsrh | Ok, I can get that up "real soon" | 20:58 |
crobertsrh | I hope that's an unrelated note :) | 20:58 |
tmckay | of course it is | 20:58 |
crobertsrh | My wife and her sister are pretty geeked to see it | 20:58 |
crobertsrh | They can [obnoxiously] recite the original line for line | 20:59 |
tmckay | I might have to, just cause | 20:59 |
tmckay | oh my | 20:59 |
tmckay | I'm not worthy | 20:59 |
crobertsrh | I wish I wasn't so worthy of hearing them :) | 20:59 |
elmiko | crobertsrh: lol, gonna have to mention that to B., she keeps asking "who would want to see that?" | 21:00 |
crobertsrh | The original (among other things) helped build Jeff Daniels a pretty nifty compound on a lake near here. | 21:00 |
elmiko | nice | 21:00 |
elmiko | i knew the original was like a cult-classic | 21:00 |
crobertsrh | I enjoyed it....but I think I was closer to 17 at that point :) | 21:01 |
elmiko | lol | 21:01 |
crobertsrh | I fully expect that I will eventually see the new one. | 21:02 |
crobertsrh | If only to scoff at it as an unworthy sequel, like Caddyshack 2 to Caddyshack | 21:02 |
elmiko | oh man... | 21:02 |
openstackgerrit | Chad Roberts proposed openstack/python-saharaclient: Adding support for query filtering to list() calls https://review.openstack.org/135086 | 21:22 |
tmckay | woohoo, review time | 21:23 |
crobertsrh | oops, tiny mistake | 21:23 |
openstackgerrit | Chad Roberts proposed openstack/python-saharaclient: Adding support for query filtering to list() calls https://review.openstack.org/135086 | 21:26 |
tmckay | nice, even urlencode uses the & form | 21:29 |
*** miqui has quit IRC | 21:29 | |
crobertsrh | Yeah, a lovely fit | 21:34 |
elmiko | looks like that wasn't too bad at all | 21:37 |
tmckay | crobertsrh, elegant, simple | 21:38 |
tmckay | now I just have to get out the sausage maker for the backend ;-) | 21:39 |
crobertsrh | It took about 10 min....but that was with my daughter breaking down the baby gate on the stairs once to come up and visit. | 21:39 |
elmiko | lol | 21:39 |
tmckay | and it works. I just hacked the client shell to pass a search_opts dictionary | 21:41 |
tmckay | sahara did the right thing (for images anyway) | 21:41 |
tmckay | extra arguments are ignored | 21:42 |
elmiko | nice | 21:42 |
jodah | just noticed the conversation earlier about how to use query params for key/value pairs | 21:42 |
tmckay | "GET /v1.1/5e8128971f1342a08571a5c5a0e3f9bd/clusters?goat=cheese HTTP/1.1" 200 148 0.072010 | 21:43 |
jodah | ?tags=k1:v1,k2:v2,k3:v3&someOtherQueryParam=SomeOtherValue | 21:43 |
tmckay | goat cheese is ignored on cluster list, nice | 21:43 |
jodah | as opposed to k1=v2,k2=v2,k3=v3, so as not to be confused with other possible query params | 21:43 |
elmiko | jodah: what about in terms of ?tags=k1:v1&tags=k2:v2.... | 21:45 |
tmckay | jodah, in this case, tags is the key, but may have multiple values | 21:45 |
jodah | that works too | 21:45 |
tmckay | so there is only 1 key, "tags" | 21:45 |
jodah | ah ok | 21:45 |
tmckay | it was our only example of consuming query args in Sahara, seems to be mostly unused previously | 21:46 |
tmckay | but flask and urlencode mesh nicely | 21:46 |
elmiko | i feel like this is probably enshrined in an RFC somewhere... | 21:47 |
elmiko | since everything seems to follow the same pattern | 21:47 |
tmckay | heh, and get_images of course doesn't go to the Sahara db, it goes to the nova client | 21:47 |
tmckay | so I'm breaking new ground here :) | 21:48 |
tmckay | elmiko, some of the notes mentioned on RFC. But it was silent on the multiple value thing, apparently | 21:48 |
crobertsrh | I bet it will all come down to < 30 lines of code change | 21:49 |
crobertsrh | and we'll ask ourselves, why didn't we already do this? | 21:49 |
tmckay | heh, if I do it right | 21:49 |
elmiko | crobertsrh: +2 | 21:50 |
tmckay | passing all the stuff down to the db layer will be easy, just a bunch of optional search_opts | 21:50 |
tmckay | but then ... but then ... | 21:51 |
* tmckay runs away waving arms | 21:51 | |
tmckay | we need to have this all done and pefect before SergeyLukjanov gets back ;-) So he can keep his two cents and be richer. | 21:52 |
crobertsrh | db.magicstuff() | 21:52 |
*** tellesnobrega has joined #openstack-sahara | 21:52 | |
elmiko | lol | 21:52 |
tmckay | hmmm, ever since I did a fresh pull on Sahara the hdp plugin won't load | 21:53 |
tmckay | did you guys see that? | 21:53 |
elmiko | i've had issue like that, usually i need to remove the build directory and the local sahara.egg.*, then reinstall | 21:54 |
crobertsrh | I haven't come across that one yet | 21:57 |
crobertsrh | I had a similar problem when the old vanilla version was removed | 21:57 |
*** crobertsrh is now known as _crobertsrh | 22:00 | |
*** tmckay has quit IRC | 22:13 | |
*** macjack has joined #openstack-sahara | 22:26 | |
*** tellesnobrega has quit IRC | 22:37 | |
*** rharwood has joined #openstack-sahara | 23:01 | |
*** witlessb has quit IRC | 23:13 | |
*** egafford has quit IRC | 23:32 | |
*** macjack has quit IRC | 23:52 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!