19:00:23 <briancurtin> #startmeeting python-openstacksdk
19:00:25 <openstack> Meeting started Tue Mar 10 19:00:23 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:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:29 <openstack> The meeting name has been set to 'python_openstacksdk'
19:00:42 <briancurtin> If you're here for the SDK meeting, say hi
19:00:48 <edleafe> hi
19:01:01 <dtroyer> o/
19:01:23 <terrylhowe> \o
19:01:49 <briancurtin> i flipped the agenda around two get quicker things out of the way first https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK#Agenda_for_2015-03-10_1900_UTC
19:02:02 <sigmavirus24> hi
19:02:04 <redrobot> o/
19:02:11 <briancurtin> etoews:
19:02:29 <stevelle> o/
19:02:39 <etoews> o/
19:02:52 <briancurtin> #topic: https://review.openstack.org/#/c/162782/
19:03:09 <briancurtin> etoews: you can go first with these two reviews since the later things will take more time
19:03:48 <etoews> well...it got merged so not much to discuss i guess.
19:03:53 <briancurtin> oh wait that just got merged
19:03:54 <terrylhowe> I think we are g2g there.  I was just confused by the lame docs
19:03:55 <briancurtin> #topic https://review.openstack.org/#/c/162761/
19:04:46 <briancurtin> terry just +2'ed that. maybe i misunderstood what i was looking at, but it wasn't far off so i'll take a look after the meeting
19:04:56 <terrylhowe> It took me a lttle staring, but I think that is the best way
19:05:22 <terrylhowe> assuming we want to log redirects
19:05:36 <etoews> sorry. gimme a minute....
19:05:37 <sigmavirus24> I think I agree with Brian. Let me stare some more
19:05:41 <briancurtin> we probably should. i dont know how often they happen, but if it happens you probably want to
19:05:52 <edleafe> terrylhowe: I think you're correct
19:06:05 <sigmavirus24> oh wait
19:06:11 <sigmavirus24> the redirects call _send_request again
19:06:18 <sigmavirus24> so the redirect will be logged
19:06:28 <terrylhowe> yeh
19:07:12 <sigmavirus24> terrylhowe: etoews :thumbsup:
19:07:38 <briancurtin> etoews: anything to add?
19:08:34 <briancurtin> #topic PUT/POST differences/issues in our create support
19:09:10 <briancurtin> terrylhowe: i havent had a chance to read the issues you created, but i saw they're there. given what we had in julien's review, any initial thoughts on what we should do there?
19:09:12 <terrylhowe> I openned I think 5 tickets to document the places where PUT is used to create
19:09:55 <terrylhowe> I kind of felt we should remove PUT from create at handle those cases as special cases
19:10:33 <terrylhowe> it is more than 5 resources though, I think there were 3 or 4 identity resources
19:11:41 <terrylhowe> that and about 2 metadata resources in compute, server and image as I recall
19:11:55 <briancurtin> terrylhowe: the part that tipped me off was the ID arg in create. if we just removed that and allowed a resource to specify put or post, are we better off there?
19:12:21 <briancurtin> i thought the ID part should only come in during update/update_by_id
19:13:43 <edleafe> briancurtin: some APIs (swift, of course) require that you specify the ID. Those should definitely be PUTs
19:14:08 <briancurtin> ah, yeah - that's one but we override create to do a put with the id
19:14:32 <briancurtin> the general case - REST-wise and otherwise - probably shouldn't have an id, right?
19:15:14 <sigmavirus24> briancurtin: REST-wise, yes
19:15:23 <sigmavirus24> I'm not certain if OpenStack's APIs agree with that though =P
19:15:31 * sigmavirus24 hasn't done in-depth research yet
19:15:37 <stevelle> as a generalization I'd say that's right but details.
19:15:45 <etoews> apologies. i'm back. catching up...
19:16:22 <edleafe> briancurtin: the general case, both in OpenStack and REST APIs, is a POST where the ID is returned
19:16:56 <terrylhowe> briancurtin: were you thinking of letting resources specify a create_method = ‘PUT’ or something like that?
19:17:08 <edleafe> briancurtin: but yeah, consistency is not there
19:17:30 <edleafe> terrylhowe: that would be a sane way to do it
19:17:50 <briancurtin> terrylhowe: nah, that would be to invasive to have to pass down through the session. i think something closer to what julien has put_create or post_create, but remove the ID first and clean up create_by_id
19:17:52 <edleafe> If you know the resource requires an ID and needs PUT, specify that
19:17:55 <terrylhowe> I like that better than making the call based on the resource_id being there
19:18:25 <briancurtin> terrylhowe: i dont think the base create_by_id should even have the ID. if it's needed it's a specialty, so override
19:18:49 <briancurtin> rather, it shouldnt even be called create_by_id anymore, but rename as part of htat and shift its behavior elsewhere
19:18:52 <terrylhowe> I’m fine with handling all the others as special cases that need to override create too
19:19:02 <edleafe> there shouldn't be a *base* create_by_id IMO
19:19:03 <terrylhowe> that way create doesn’t get cluttered with if statements
19:19:36 <sigmavirus24> == edleafe, terrylhowe
19:19:42 <sigmavirus24> (ignore the tuple unpacking error)
19:19:42 <briancurtin> ^yep
19:20:38 <briancurtin> #action move create_by_id behavior to not accept an ID, make ID-needing create functions become overrides
19:20:39 <terrylhowe> create_by_id is very strange edleafe I agree
19:21:15 <briancurtin> #topic Discuss API Guidelines https://etherpad.openstack.org/p/proxy_api_guidelines
19:22:23 <briancurtin> now that we've built out a reasonable amount of stuff and have been toying with it, i want to get towards a consistent set of interfaces we can apply around all of the proxies that are nice to use. after writing a few things up in a few different ways, leveraging Resource.update_attrs has made for something pretty powerful
19:22:50 <briancurtin> overall, what i wrote up in that doc allows you to pass in an existing Resource instance and/or the attributes of a resource
19:23:29 <briancurtin> this code will make that work, and there's a little sample of what it looks like in action https://review.openstack.org/#/c/161550/ -- i'd rather debate the guideline doc itself, but just see this review as an application of it
19:24:17 <terrylhowe> optionally passing resource to create_resource make conn.create redundant
19:24:38 <etoews> i'm still a bit iffy on the behaiour of create_server(resource=server_obj, name="different name")
19:24:57 <briancurtin> terrylhowe: pretty much
19:25:27 <briancurtin> etoews: is it that particular case, literally of create_server, or also of create_network, create_container, create_anything?
19:25:31 <terrylhowe> the update is probably the oddest of our current proxy
19:25:57 <terrylhowe> part of me things we should just not have update_resource, people could just call conn.update
19:26:31 <etoews> create_anything
19:26:37 <briancurtin> terrylhowe: if we don't provide the full scope of operations at this level we shoouldnt provide any of them
19:26:57 <briancurtin> if you have to go to another place to do a similar operation then it's going to make people jump back and forth
19:27:31 <briancurtin> etoews: what specifically are hte issues? if you want to create 5 servers, call that 5 times with different names
19:27:42 <briancurtin> *5 of the same flavor/image of servers
19:28:41 <etoews> is there any difference in behaviour when server_obj already has an id and when it doesn't?
19:28:43 <briancurtin> terrylhowe: additionally, the update_resource behavior is one of the nicest parts of it behind create. update_server(my_server_instance, name="my new name") instead of setting the name attribute and then passing it into a method on connection
19:29:20 <briancurtin> etoews: we're calling create so an id won't be sent. it's using everything on that resource except the ID, plus your new name
19:29:34 <terrylhowe> users could use update_attr as well
19:29:35 <briancurtin> (or whatever other new attributes you would have specified)
19:29:40 <edleafe> etoews: is the confusion between object methods and class methods?
19:29:49 <etoews> edleafe: nope
19:29:58 <briancurtin> terrylhowe: technically they could, but they shouldnt have to mix resource/proxy layer support
19:30:25 <briancurtin> terrylhowe: they could freely use it, and will have to if they're working lower, but the proxy layer is there to take care of it
19:30:42 <etoews> briancurtin: so the id of any server_obj passed in gets ignored no matter what. correct?
19:31:04 <briancurtin> etoews: it would be ignored by the underlying create call
19:31:14 <briancurtin> it will not be an update operation
19:31:14 <etoews> right
19:31:46 <briancurtin> and it'll of course be fully documented and example'd out to show what that usage is against others
19:32:14 <etoews> got it. thx.
19:34:03 <terrylhowe> what I don’t like about it I guess is it gives two uses to about every call
19:35:39 <terrylhowe> there is a slight chance some resource will have an attribute named ‘resource’ and that will cause some complications
19:36:46 <briancurtin> terrylhowe: so that is one issue ive been trying to think about, and that's why that argument isn't named for the actual resource, e.g., create_server(server=None) -- i don't have a great justification for this other than that i think the risk of something using "resource" directly is pretty low, and i dont think it exists today
19:38:00 <briancurtin> terrylhowe: and on two ways to make every call - i still dont like that either. i see a little bit of value in the conn.action() methods, but not nearly as much as what is contained in the proxies. they're entirely serviced by the proxy methods now if these do take a full resource
19:40:01 <briancurtin> terrylhowe: i left those in the code and in the explanation of the guidelines to show the differences. i wouldnt 100% like if we had both, but i didnt want adding one to be a strict condition of removing the other
19:44:49 <briancurtin> as another example of what this looks like in action, i rebased that server_builder on this https://review.openstack.org/#/c/160623/6/examples/server_builder.py
19:47:27 <etoews> it's definitely nice not having to pass in an object all the time
19:48:11 <etoews> we even avoided doing that in jclouds land where possible
19:49:23 <terrylhowe> the update is the only thing passing resource in there
19:49:34 <edleafe> etoews: same for pyrax
19:49:35 <briancurtin> terrylhowe: yeah that's the only one that makes use of it
19:50:02 <briancurtin> terrylhowe: er, delete does as well
19:50:38 <terrylhowe> that is using the delete we have now
19:51:42 <briancurtin> terrylhowe: oh wait, yeah it is. i thought i had changed that to use the proxy method. i originally had it that way to show the different ways - how create uses args, update uses resource, and delete uses the conn.delete
19:52:12 <briancurtin> ideally delete would do delete_server(resource=servers[id])
19:58:39 <terrylhowe> maybe we should have have a meeting later to beat up the proxy briancurtin
19:58:50 <terrylhowe> blowing the whole thing up is overwhelming to me
19:59:06 <briancurtin> terrylhowe: i'm ready for that whenever
19:59:15 <terrylhowe> maybe just discuss one aspect
19:59:46 <terrylhowe> I got a lot going on, so little easy things are easier for me
20:00:23 <briancurtin> terrylhowe: in the end it's really just one aspect that applies to everyting else. the create_server example in that doc is actually the exact same API for the other actions, just calling a different method under the hood
20:00:35 <briancurtin> terrylhowe: whenever you have time let me know and let's talk about it. i'm wide open
20:00:56 <briancurtin> let's head back to -sdks
20:01:11 <briancurtin> thanks everyone!
20:01:14 <briancurtin> #endmeeting