19:01:03 <briancurtin> #startmeeting python-openstacksdk
19:01:03 <openstack> Meeting started Tue Jul  8 19:01:03 2014 UTC and is due to finish in 60 minutes.  The chair is briancurtin. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:06 <openstack> The meeting name has been set to 'python_openstacksdk'
19:01:40 <briancurtin> If you're here for the python-openstacksdk meeting, speak now of forever hold your peace
19:02:07 <terrylhowe> Terry Howe, HP
19:02:07 <briancurtin> Brian Curtin, Rackspace
19:03:50 <dtroyer> Dean Troyer, Nebula
19:04:46 <edleafe> Ed Leafe, Rackspace
19:05:08 <briancurtin> i'm out in the hallway at SciPy so i only had a couple of minutes to get ready here, but here's a small agenda: https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK#Agenda_for_2014-07-08_1900_UTC
19:05:48 <briancurtin> #topic https://review.openstack.org/#/c/104948/ -- Add some factories
19:06:08 <briancurtin> this looked fairly straightforward to me and terry made the one adjustment i asked for, so I +2'ed it
19:06:48 <terrylhowe> I was inspired to do this after doing the OSC integration demo
19:07:16 <briancurtin> getting logic out of examples and into the lib == good
19:08:24 <dtroyer> there is no way to pass in a transport in Session.create()?
19:09:03 <terrylhowe> people don’t need to use Session.create() if they don’t want to
19:09:34 <terrylhowe> oh, but you are probably thinking of the case of having one transport for connections to different clouds
19:10:25 <terrylhowe> I’d have to think about this, but I created these methods as a simple way to make these things, not as the only way
19:10:56 <dtroyer> also you seem to be using different keyword args in create() and __init__() for the smae thing, ie verify vs insecure
19:11:59 <terrylhowe> well verify could be insecure or cacerts
19:12:09 <dtroyer> also I think adding all of the auth stuff to session pollutes it, if you want a shortcut or auth maybe it should be stand-alone or in an auth module?
19:13:52 <terrylhowe> the auth stuff is in the auth module
19:14:13 <dtroyer> which was not previously imported into session
19:14:44 <terrylhowe> in the osc world, there would be a client class that do something like that, would you sooner have another class called client or connection?
19:15:17 <dtroyer> I always assumed that was the direction we were heading here based on the early design discussions, something above session for the 'high-level' api.
19:15:32 <dtroyer> it seems like we're not following those early decisions so much anymore
19:15:57 <briancurtin> should we take a step back and take a stab at that higher level now that we have a couple of potential resources to build on?
19:16:02 <terrylhowe> problem is, that client class, I don’t know what it would have
19:16:43 <dtroyer> I think that is a good idea, Brian.  we'll know much more about decisions here if we know where its all going.
19:17:30 <terrylhowe> there were some design ideas out there that I’m not sure how people planned to implement them
19:17:31 <dtroyer> My experience with OSC was that it took 3 tries at the cliff-based command stack to get something that was clean, or as clean as you can get with the existing libs
19:17:59 <dtroyer> I think making some actual example strawman that can be run would be helpful
19:18:07 <briancurtin> #topic moving towards the higher level
19:19:39 <briancurtin> before we get on with that higher level, are we confident that we're heading in the right direction with these glance, neutron, and swift resources?
19:20:22 <terrylhowe> neutron seems like it will map pretty easily
19:20:52 <dtroyer> I really haven't looked at them, my interest was in the lower-level lib/API which it appears is not part of the picture.
19:20:53 <terrylhowe> I’m more concerned with the others that use headers
19:21:32 <briancurtin> one think i realized i need to work around in the swift one is that when i added the repr for that Account class, that breaks on teh GET but works on the HEAD, so i need to make it smarter working with both
19:21:34 <terrylhowe> lower level api?
19:21:39 <briancurtin> which i thought i had figured out, but i think i lost it
19:22:24 <dtroyer> terrylhowe: like the object/lib/* stuff in OSC.  where the actual API URLs, etc are encoded.
19:22:50 <terrylhowe> that is in the resource class
19:23:44 <briancurtin> and terrylhowe - just saw your comments on the swift Account one - i lost name/count/bytes in my git disaster
19:23:53 <dtroyer> right.   I consider that a higher-level API as that is what app devs probably want to work with.  I'd prefer to not carry the extra weight
19:24:32 <terrylhowe> you want dictionaries?
19:25:19 <dtroyer> I don't want the verbs in the resources.  nor in managers.  I don't have a problem with the other resource stuff when it is warranted
19:25:56 <dtroyer> I also know I wasn't too active in that discussion back when, but I did think there was still going to me more under the hood
19:26:15 <dtroyer> now is not the time to re-open that
19:26:33 <terrylhowe> It doesn’t seem overly complex to me the resource class
19:26:55 <dtroyer> it's the semantics of it, as well as the weight they'll gain over time
19:27:53 <terrylhowe> if you don’t want resources, you just want a request level, you could use the @classmethods in resource
19:28:15 <terrylhowe> they just return dictionaries as I recall
19:28:35 <briancurtin> yeah they typically return like response bodies
19:28:41 <terrylhowe> https://github.com/stackforge/python-openstacksdk/blob/master/openstack/resource.py#L235
19:28:43 <dtroyer> that isn't necessarily always a bad thing
19:29:15 <dtroyer> but again, this is not an attempt to change the design, just express the percieved loss of something I thought we'd have
19:30:25 <terrylhowe> I think the functionality is there for that
19:30:54 <dtroyer> ok, good.  I haven't looked to closely yet, it's still not risen to the top of the queue
19:31:27 <briancurtin> and if there isn't what you're looking for, we should consider now how we can get it done before we get more locked i
19:31:29 <briancurtin> in
19:31:56 <dtroyer> I'll put together a strawman like I should have done in April...
19:33:03 <edleafe> It always helps to have a high-level view of how users will want to use the SDK
19:33:19 <edleafe> Otherwise it's easy to get lost in the details of working with the API
19:34:55 <briancurtin> now that we have more fleshed out, thinking about that high level/consumer look makes a lot of sense
19:35:54 <terrylhowe> https://review.openstack.org/#/c/105030/
19:36:05 <terrylhowe> is not a bad strawman to beat on
19:39:44 * briancurtin adds to todo list
19:49:46 <terrylhowe> anything else here?
19:50:33 <briancurtin> nothing here, just need to get the rest of that swift resource with your comments
19:52:36 <terrylhowe> I’m not sure if I should just fill out some network stuff next or work on something with the header issue
19:52:41 <briancurtin> #endmeeting