19:00:29 <briancurtin> #startmeeting python-openstacksdk
19:00:30 <openstack> Meeting started Tue Apr 28 19:00:29 2015 UTC and is due to finish in 60 minutes.  The chair is briancurtin. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:34 <openstack> The meeting name has been set to 'python_openstacksdk'
19:00:58 <briancurtin> if you're here for the SDK meeting say hi -- i know at least everett is out today
19:01:45 <dhellmann> o/
19:02:28 <terrylhowe> o/
19:04:22 <briancurtin> the only thing i really have to talk about is two reviews that comprise the common list and get functionality, and in doing them, they should remove find...but i want to make sure i really understand what find is supposed to be since we manufactured the concept on our own, or perhaps took it from somewhere else. it doesnt really solve much that a good get
19:04:22 <briancurtin> and list do, as far as i know
19:04:56 <briancurtin> https://review.openstack.org/#/c/178302/ is the list one and https://review.openstack.org/#/c/164351/ is the get
19:05:23 <terrylhowe> well, I would expect get to do just an HTTP GET given an id or resource with an id
19:05:50 <terrylhowe> find is like a search by name
19:05:52 <briancurtin> together they allow you to list resources either whole or limited by query parameters, and get will either get by an ID or try by a name, because getting things by name has shown to be pretty common. someone just asked about it in -sdks the other day
19:06:29 <briancurtin> terrylhowe: but why have two methods when we could have one?
19:07:04 <terrylhowe> because I think people expect get to do a GET not some search
19:07:04 <briancurtin> find was (is?) doing the lookup by id and then by name. get will do the lookup by id at the very least
19:08:31 <briancurtin> terrylhowe: my thinking is that i should be able to say "get me this server" and call a method and get a server. if I have to call get to get something by ID and find to get something by name, i have to branch my code or write it differently based on what i think im getting or how im going to use it
19:08:37 <terrylhowe> just like delete does a DELETE
19:09:06 <briancurtin> im unconcerned with the HTTP verbs as this is the higher level view
19:09:42 <briancurtin> at this point it's purely usability on top of that stuff. we don't *have* to stick to get only doing a single GET when we can provide better
19:10:33 <briancurtin> certainly delete just doing a DELETE makes sense, but we added some minor smarts on top of it to work better programmatically than letting the 404 always kill it
19:10:41 <terrylhowe> ‘better’ is subjective
19:11:24 <briancurtin> i guess i dont know what to say then. if there are other approaches to this i'd love to see them
19:13:54 <briancurtin> find has always seemed very difficult to do properly in a general case, and the list method working within the confines of its query parameters to provide limited responses, and get working with it to limit to a single resource by name as an alternative to ID is what i end up doing manually every day i've been wokring with this stuff
19:15:49 <terrylhowe> find needs work that is for sure
19:16:30 <terrylhowe> I think find is a better name than get_by_id_or_name though
19:17:07 <briancurtin> why not just call it get_x and just get whatever x is?
19:17:19 <terrylhowe> we could pull the fields=‘id’ out of there and  it would be a get
19:17:30 <terrylhowe> where x would be ‘by_name’ or something?
19:17:37 <briancurtin> get_server
19:17:57 <briancurtin> get_server("asdf123-asdfsd-2222") or get_server("my_server")
19:18:12 <briancurtin> currently it has that by_name param per another discussion, but i think we can even remove that, or do that another way
19:18:12 <terrylhowe> find_server(“asdf”)
19:18:36 <briancurtin> but why "find"?
19:18:53 <terrylhowe> that is from osc.  I think it is a pretty good verb
19:18:55 <briancurtin> i think in the end we need two things. one to get one resource, one to get many. we cannot have three.
19:19:01 <terrylhowe> it is searching for a resource
19:19:33 <briancurtin> so if i just rename get_resource to find_resource what is it missing?
19:19:46 <briancurtin> er, in the current review, s/get_server/find_server
19:20:16 <briancurtin> it gets by an ID or it will get by a name. ignore the by_name param for now
19:21:49 <briancurtin> keep in mind that something has to return exactly one resource, and something else should return multiples (i think we agree list is this one and its fine)
19:22:41 <briancurtin> it really feels to me that these recent changes to make list more powerful with the query params, and get handling either id or name, takes on what i knew to be teh eventual goal of find
19:26:09 <terrylhowe> oh well, I’ll have to look at stuff
19:27:02 <briancurtin> i apologize if im coming off a little heated, i guess the timing is getting to me a bit. been thinking about the summit talk and a bunch of other summit stuff as well today while getting that change in
19:27:36 <terrylhowe> I just don’t understand how we satisfy the folks that just want a GET and those who want to search without two methods
19:27:59 <terrylhowe> Adding extra parameters to a method to me doesn’t help over having two
19:28:09 <terrylhowe> I hear you on it is getting close to the summit
19:28:29 <terrylhowe> stuff needs to get pulled together and I keep getting pulled onto other projects
19:30:21 <briancurtin> so i guess what type of request constitutes a search? my usual thing is finding servers with a prefix in the name, or by flavor, and those are things you can now do with conn.compute.servers(image="the image")...but i often want to do conn.compute.create_server with teh "m1.small" image and i'd like to just plug that in and get exactly it back
19:32:09 <terrylhowe> search to me is list with some matcher
19:34:22 <briancurtin> the only thing i don't totally like about having a bunch of methods is that we're special casing something that has an ID versus something that doesn't, and i dont think an application developer should have to worry about that, so covering that difference up is something i'd really like to explore
19:35:14 <briancurtin> and i think by get_ handing off that matcher part to list and working just as the way to get one resource that has what you're looking for, i think it does that
19:35:23 <terrylhowe> well, you kind of had two cases there in that last thing server by prefix was one and flavor by name was the other
19:35:31 <terrylhowe> flavor by name you expect one result
19:36:11 <terrylhowe> server by name prefix sounds like something I’d expect to search for and get multi results
19:36:22 <terrylhowe> just like all the servers booted off a particular image
19:37:00 <briancurtin> and thats what conn.compute.servers(name="blah") or servers(image="particular image")
19:37:37 <briancurtin> /servers?name=blah is actually a regex, which maybe helps in this discussion - it's often not a regex on other resources
19:37:40 <terrylhowe> for those, you expect multi results
19:38:06 <briancurtin> but if i did get_server("blah") i would want one, or get_image("particular_image")
19:38:11 <briancurtin> yes
19:39:01 <terrylhowe> same with find_server(“blah”)
19:39:04 <briancurtin> in teh case of get_server("blah") it would actually raise because it's a regex and there are multiple. i'd have to properly give the name of one single server or terminate the line if i really meant "blah"
19:39:40 <briancurtin> terrylhowe: find_server("blah") is the same as which one? servers or get_server
19:39:58 <terrylhowe> get_server_by_name_or_id(“blah”)
19:40:08 <briancurtin> i dont understand that
19:40:23 <terrylhowe> find should return 1 thing
19:40:35 <briancurtin> so get and find are the same thing/
19:41:10 <terrylhowe> no, one gets by id and the other by id or name
19:41:19 <terrylhowe> that is what is out there now at least
19:41:32 <briancurtin> im not really concerned with what's out there now, though
19:41:52 <briancurtin> having two functions that work the same with an id but only one of them accepts a name doesnt seem good
19:42:31 <briancurtin> i guess i need to look back at find and see what get is not covering for it
19:42:49 <terrylhowe> from a performance perspective it does
19:42:57 <briancurtin> the base get just has to go away unless it turns into 100% client side filtering because no two resources accept any of the same parameters
19:43:00 <briancurtin> base find*
19:43:04 <terrylhowe> if you know you have an id and don’t want to start some search by name
19:43:48 <terrylhowe> good reason to have a get that does GET only
19:43:55 <briancurtin> terrylhowe: this is what i had commented in the get change, to perhaps try by get first (like current find does) and if it doesnt get you anything, try with self.servers(name="the thing")
19:44:28 <briancurtin> and that current get could try to only ever do a get, or do a potential follow up by name if necessary, but it can surely only do a get
19:44:37 <briancurtin> er, by current i mean in the review
19:45:23 <briancurtin> i think i will try to write up some sample code using what's in review right now to exercise some of what's there and compare it to what we have now and what we're talking about
19:45:43 <briancurtin> its maybe not the easiest to see in just raw implementation
19:46:27 <terrylhowe> well, I need to look at the latest.  It hasn’t been out since long before this meeting started
19:46:54 <terrylhowe> don’t bother with sample code
19:46:57 <briancurtin> yeah, i had tried a few things but it mostly clicked last night
19:48:32 <terrylhowe> 40 some minutes on this, anything else?
19:50:15 <briancurtin> haha, not really. get/list/find has been the current roadblock, but im going to jump ahead while the reviews are out and get back to the create one since i had a bunch of followup to adjust from that (plus it will feed into how update is done)
19:51:17 <briancurtin> anything on your end?
19:52:16 <terrylhowe> another topic that should be just as popular https://review.openstack.org/#/c/155362/ kind of important for plugin development
19:52:42 <terrylhowe> so old, I don’t remember what it even does
19:52:48 <terrylhowe> but it was working
19:53:25 <briancurtin> yeah that's on my list as well, i'll take a look in the next day or so at it
19:55:14 <terrylhowe> once we get cleared up on these proxy changes, I’m willing to do some of the boring transformation work
19:55:20 <terrylhowe> it doesn’t have to be all you on that stuff
19:56:36 <briancurtin> cool. at least for delete it was a fairly quick set of changes, but list is a bit more involved
19:58:04 <terrylhowe> are we all in disagreement on proxy.create?
19:58:50 <terrylhowe> for some reason, I think you were going to change it to take just **attrs and filter out the id
19:59:17 <terrylhowe> to support clone
19:59:32 <briancurtin> yeah im going to look back at it, and perhaps start on the update one and see how they will look side-by-side
19:59:58 <terrylhowe> k
20:00:01 <briancurtin> i think we filter out the id somewhere within Resource.create anyway, but i'll check it
20:00:26 <briancurtin> anyways that's time. i'll check out the dynamic one and get moving on this create stuff as well
20:00:30 <briancurtin> thanks for the chat
20:00:32 <terrylhowe> yeh, that might be better
20:00:43 <briancurtin> #endmeeting