19:00:46 <briancurtin> #startmeeting python-openstacksdk
19:00:47 <openstack> Meeting started Tue Jul  1 19:00:46 2014 UTC and is due to finish in 60 minutes.  The chair is briancurtin. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:51 <openstack> The meeting name has been set to 'python_openstacksdk'
19:01:02 <briancurtin> #link https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK#Agenda_for_2014-07-01_1900_UTC
19:01:19 <briancurtin> If you're here for the python-openstacksdk meeting, say hi
19:01:28 <briancurtin> Brian Curtin, Rackspace
19:01:43 <edleafe> Ed Leafe, Rackspace
19:03:26 <edleafe> <crickets>
19:03:40 <terrylhowe> Terry Howe, HP
19:03:45 <jamielennox> Jamie Lennox, Red Hat
19:03:50 <terrylhowe> if the meeting started, sorry I’m late
19:04:12 <briancurtin> terrylhowe: didn't miss anything, was just waiting for people to roll in
19:05:51 <briancurtin> there are a whole bunch of reviews out there which are dependencies of examples and resources, but they're all fairly small. of those deps, two are probably worth talking about, while the rest just need a quick eye
19:05:55 <briancurtin> #topic https://review.openstack.org/#/c/102607/ -- Change transport JSON handling
19:07:22 <briancurtin> it would be nice to have that is_redirect
19:08:14 <briancurtin> but this seems ok to me as far as i understand
19:08:36 <dtroyer> sorry I'm late…is that 102607 you're talking about?
19:08:43 <briancurtin> dtroyer: yep
19:09:19 <terrylhowe> I am a little confused on how that would work on a redirect
19:09:42 <dtroyer> there are two things going on there, is_redirect was one, the other was that it didn't decode JSON after a redirect, which AFAIK is possible
19:10:07 <dtroyer> or properly handle not-JSON when JSON was expected.  ok, 3 things
19:12:14 <dtroyer> terrylhowe: I don't think the response being a redirect has any relation on decoding the returned body JSON
19:12:54 <terrylhowe> well, if it is a redirect, we shouldn’t bother decoding the body
19:13:10 <dtroyer> then why follow the redirect?  that's the response you asked for
19:13:42 <terrylhowe> if the current response is a redirect to a new url, we shouldn’t decode the body
19:13:47 <dtroyer> the entire follow-redirect is handled in the _send_request call, so you'll either get what you wanted or an exception due to some redirect error condition
19:15:01 <terrylhowe> okay, I guess I didn’t completely understand the tests last time
19:16:58 <briancurtin> terrylhowe: good on this or any more questions?
19:17:20 <terrylhowe> good
19:17:43 <briancurtin> #topic https://review.openstack.org/#/c/103677/ -- Add support for HEAD requests of resources
19:18:43 <briancurtin> i moved it out of get into its own head call now, so hopefully that makes sense. 'head' had to come up somewhere, wasn't sure if it was better standing by itself or inside of get (which was kind of dumb thinking back on it)
19:19:32 <dtroyer> briancurtin: I like that better…don't forget to update the commit message (still has head=True)
19:19:43 <briancurtin> ah, will do
19:19:59 <terrylhowe> I like that and I guess my only question is are we going to have any way to not include header values in the body on a put?
19:20:45 <terrylhowe> maybe it should be handled as an attribute of Prop or maybe you guys feel it just doesn’t matter
19:22:29 <briancurtin> hm, not really sure
19:24:41 <terrylhowe> Maybe Prop could have a header boolean or something
19:24:46 <jamielennox> does it make sense for a HEAD call to construct an object?
19:25:12 <briancurtin> terrylhowe: that could work
19:25:15 <terrylhowe> for swift I think it does
19:25:20 <jamielennox> ok
19:25:25 <briancurtin> yeah i'm not really sure about other uses, but for swift yes
19:25:29 <jamielennox> swift is weird
19:25:50 <terrylhowe> yarp
19:25:51 <briancurtin> really the only other one i saw is in keystone for verification
19:26:01 <briancurtin> (other one meaning other HEAD usage)
19:26:26 <jamielennox> yep, keystone uses it as essentially a boolean
19:26:38 <jamielennox> return 200 if good, 404 or something else if bad
19:27:51 <briancurtin> terrylhowe: is Prop gaining a header bool something that should go in here, or separate?
19:27:56 <terrylhowe> if there is going to be a change to Prop for header values, that could be later
19:28:00 <terrylhowe> I think
19:28:08 <briancurtin> ok cool
19:29:59 <briancurtin> i think the rest of the accessory/dep changes are small enough to just say "take a look" instead of going 1-by-1 here
19:30:17 <briancurtin> then there's the three example scripts that build on each other
19:30:21 <briancurtin> #topic https://review.openstack.org/#/c/102590/ -- Example create command
19:30:54 <briancurtin> my only thought is maybe that common.py change should be broken out, but it's not the end of the world
19:31:18 <briancurtin> otherwise, and like the rest of them, it's not bad
19:36:20 <briancurtin> the others are basically the same -- https://review.openstack.org/#/c/102591/ -- Add example delete and https://review.openstack.org/#/c/102922/ -- Add example get
19:36:54 <briancurtin> could eventually refactor them into something more common, but working example scripts that stand by themselves are better than something fancy at the moment
19:40:52 <briancurtin> alrighty, nothing there then
19:40:56 <briancurtin> #topic resources
19:41:28 <briancurtin> anything on the network or image resources? fwiw, the swift account one looks basically the same, just putting it back together after changing things up a bit
19:41:43 <terrylhowe> https://review.openstack.org/#/c/99463/
19:41:57 <terrylhowe> if this basic pattern is good enough, I could crank out a lot of those
19:42:25 <terrylhowe> I know it they need to be filled out with more useful methods like “upload” for images, but that could come later
19:43:02 <briancurtin> terrylhowe: i dont really have anything against it, and im basically planning on doing the same thing with this swift one
19:44:08 <jamielennox> terrylhowe: yea - it looks a lot like how i was thinking
19:44:10 <briancurtin> terrylhowe: i think it's good enough to build on, so i'm going to give another thorough look right after this and i think we're good to push on there
19:44:18 <dtroyer> I think it might be good to take one function out to what you would consider to be the high-level API before making a lot of copies before the underlying bits are painful to change.  I know I learned a LOT doing that in OSC...
19:45:46 <terrylhowe> well, upload might be too complicated to use as an example
19:46:25 <terrylhowe> we might learn more actually using one of the examples
19:52:13 <terrylhowe> https://review.openstack.org/#/c/102593/
19:52:42 <terrylhowe> I really don’t have much to add to network at the moment
19:54:37 <briancurtin> terrylhowe: for package naming with a version in it, we have the image one with v1 and this with v2_0 - should it be v2 or should the v1 gain something?
19:55:33 <terrylhowe> tough call, it follows the api now
19:56:29 <terrylhowe> dtroyer: might have an opinion on versioning
19:56:35 <dtroyer> of course!  ;)
19:57:04 <dtroyer> For the purposes of module paths, I don't imagine duplicating trees for minor version changes
19:57:23 <dtroyer> so i'd be happy with /v1, /v2, etc and hand;e minor stuff in-line as required
19:57:41 <terrylhowe> sounds good to me
19:57:46 <briancurtin> i like it
19:58:42 <briancurtin> anything else to squeeze in the last 2 min?
19:59:36 <terrylhowe> some soccer game in a minute or so
20:00:15 <briancurtin> #endmeeting