19:00:25 <briancurtin> #startmeeting python-openstacksdk
19:00:26 <openstack> Meeting started Tue Aug  5 19:00:25 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:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:30 <openstack> The meeting name has been set to 'python_openstacksdk'
19:00:47 <terrylhowe> Terry Howe, HP
19:00:55 <briancurtin> if you're here for the python-openstacksdk meeting, say hi
19:00:58 <stevelle> Steve Lewis, Rackspace
19:00:59 <briancurtin> Brian Curtin, Rackspace
19:01:05 <dtroyer> Dean Troyer, Nebula
19:01:42 <briancurtin> https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK#Agenda_for_2014-08-05_1900_UTC - somewhat of an agenda
19:02:07 <briancurtin> #topic Current Neutron reviews from Terry
19:02:45 <briancurtin> so Terry has a million reviews out there for the openstack.network resources. i've gone through most of them and they seem fine, the only real thing i have is that some of the properties should be using the type paramter
19:03:28 <briancurtin> Terry and I talked briefly earlier and i'm wondering if anyone else is ok with mostly approving these reviews as-is and perfecting the type situation later (with bugs submitted for the ones that need to be changed)
19:05:05 <terrylhowe> most of them are just attributes, neutron has a pretty simple api.  I think security group is the only tricky one because it as a security group rule.
19:05:49 <jamielennox> example of where type is needed?
19:06:17 <terrylhowe> it would be good to get extra eyes on that one https://review.openstack.org/#/c/111047/
19:06:32 <dtroyer> I'm neutral on committing them as-is.  This is one of the reasons I usually prefer to push a couple of things all the way through to establish these details, then iterate on the rest of the objects.
19:06:57 <terrylhowe> I did the network through slow, then all the rest
19:07:14 <briancurtin> jamielennox: an example i think is /quotas, where the values coming in should all be ints. i think we should enforce that since it's documented that they're ints and they do come back as ints
19:08:20 <briancurtin> they're going to be ints right now regardless, they're just left unchecked. i dont feel super strongly about it, but we do have that type parameter in there
19:08:41 <jamielennox> i'm fine with letting that slip through for now, if it's being returned correctly anyway
19:09:36 <jamielennox> briancurtin: at some point later we will need to decide what level of spec enforcement we do, the current clients say that whatever the server returns is fine and whether we enforce the spec more strictly
19:10:32 <dtroyer> jamielennox: jon postel had it right:  be liberal in what you accept and strict in what you send
19:11:09 <dtroyer> maybe type checking on values coming from the server are (eventually) warnings?
19:11:31 <briancurtin> i like both of those messages
19:11:52 <terrylhowe> +1
19:12:14 <jamielennox> dtroyer: from memory we try to actually cast to the types, but we can always allow it to fail and warn
19:12:24 <briancurtin> so back to the original thing quickly - i'm going to continue +2'ing terry's reviews unless they're including incorrectly named properties or something, and then we can figure out the strictness later
19:12:32 <jamielennox> briancurtin: ++
19:12:49 <dtroyer> +1
19:14:24 <briancurtin> #topic swift account/container
19:14:52 <terrylhowe> I haven’t fully reviewed it, but I put in some comments before the meeting
19:15:19 <terrylhowe> I still think we could just not have an account resource
19:15:32 <briancurtin> yeah i'm going to see what it looks like to drop it
19:16:05 <briancurtin> it felt right with the previous (but odd) implementation. now *this* seems odd
19:16:28 <briancurtin> i kind of left it beacuse it's account-wide metadata, but it could just be on the container class
19:16:54 <dtroyer> FWIW when doing these bits in OSC I stole the methods (process) but not the naming
19:17:41 <terrylhowe> it would be nice to have a way to capture the headers and the body for a get
19:17:49 <terrylhowe> I’m not sure how to do taht
19:18:43 <briancurtin> terrylhowe: i had something hacked up when i first added HEAD to the Resource class through a param to the get calls
19:18:47 <jamielennox> the existing one returns the decoded body and the received message as a tuple, maybe we have to do that as well
19:19:15 <jamielennox> s/existing one/current clients
19:19:42 <jamielennox> had thought we didn't need that, but at very least i can see status code being needed
19:19:56 <terrylhowe> I don’t know if anyone other than swift will need that
19:19:57 <briancurtin> jamielennox: so you always get head+body then?
19:20:08 <terrylhowe> that being header and body
19:20:24 <jamielennox> you get back the requests.Response and the decoded JSON as a dict
19:21:01 <briancurtin> terrylhowe: yep, i believe it's just swift that would need this
19:23:46 <jamielennox> we could customize the dict object that is returned from a request such that it has a status_code or headers parameter - but at that point is it better than just returning the requests.Response?
19:24:19 <briancurtin> probably not
19:24:33 <dtroyer> Making the return look as much like the rest of the APIs is a win
19:25:03 <dtroyer> Swift is a special snowflake in a lot of ways but the fresh SDK is an opportunity to hide that
19:26:06 <terrylhowe> yeh, there is a lot of potential to make things easier for the user
19:31:43 <briancurtin> does that come back to an extra parameter on the Resource.get* calls to add in header data, then handling that inside the various Swift resources?
19:31:48 <briancurtin> or am i a level off?
19:32:50 <terrylhowe> Yeh, either a parameter or a different method
19:34:03 <briancurtin> i'll see if i can do it with a parameter. adding another method is going to end up making us duplicate things
19:34:25 <terrylhowe> yep
19:35:25 <briancurtin> i haven't done anything to split out those lower level things, so i'll try to take care of that around the same time
19:35:55 <briancurtin> #topic automating Resource class creation
19:36:13 <briancurtin> terrylhowe: i think you mentioned a script that had created some or all of those neutron classes, right?
19:36:40 <terrylhowe> I don’t know if anyone would want to use my bash script, it is probably hard to follow
19:37:05 <terrylhowe> https://github.com/TerryHowe/pogo/tree/master/sdkgen
19:37:32 <terrylhowe> is where I have been dumping that stuff though.  it is pretty much just some throw away code
19:37:59 <terrylhowe> it has been handy for what I’ve been doing though
19:38:59 <briancurtin> at least useful to write up the skeletons
19:39:08 <terrylhowe> It is just put the sdkgen directory in the sdk project and run:
19:39:11 <terrylhowe> ./sdkgen/t.sh sdkgen/database/v1.0/instance
19:39:14 <terrylhowe> for example
19:39:30 <terrylhowe> it creates a branch and creates a resource and test file
19:41:17 <briancurtin> cool. i'll try it out for whatever i get into next
19:41:47 <terrylhowe> feel free to ask me questions if you try it
19:41:59 <briancurtin> will do
19:42:51 <briancurtin> anything else to cover while we're here?
19:43:01 <terrylhowe> nothing here
19:44:07 <jamielennox> i'm good
19:44:23 <dtroyer> nope
19:44:31 <briancurtin> cool. thanks everyone!
19:45:04 <briancurtin> #endmeeting