19:00:22 <briancurtin> #startmeeting python-openstacksdk
19:00:24 <openstack> Meeting started Tue Apr  1 19:00:22 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:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:28 <openstack> The meeting name has been set to 'python_openstacksdk'
19:00:59 <briancurtin> if anyone is here for the python-openstacksdk meeting, can they please state their name and affiliation?
19:01:09 <edleafe> Ed Leafe, Rackspace
19:01:18 <bknudson> Brant Knudson, IBM
19:01:22 <terrylhowe> Terry Howe, HP
19:01:26 <Alex_Gaynor> Alex Gaynor, I have many affiliations.
19:01:28 <briancurtin> Brian Curtin, Rackspace
19:01:52 <Alex_Gaynor> (I'm also sitting in the middle of another meeting, so apollogies when I'm inatentive)
19:02:35 <jamielennox> Jamie Lennox, Red Hat
19:04:01 <dtroyer> Dean TRoyer, Nebula, jumping in late...
19:04:12 <briancurtin> ...and that's the usual crew, so moving on
19:04:41 <briancurtin> #topic Progress - can we move forward toward a MVP?
19:05:17 <briancurtin> Since several of dtroyer's reviews are nearing merge, it feels like we have enough lower level plumbing to start building on top of
19:05:46 <briancurtin> shortly we'll get into edleafe's design, but does it feel like we're at a point where we can start building services and pick up the pace a bit?
19:06:01 <dtroyer> I hope so ;)
19:06:17 <briancurtin> for example, I'd like to revisit Alex_Gaynor's old "api_strawman" using some of this recent stuff
19:06:24 <edleafe> if we assume that we will have a reliable way to get endpoints, etc., we can certainly start doing some of the other stuff
19:07:14 <briancurtin> besides these current reviews, is there anything else we must absolutely figure out before moving on?
19:07:29 <edleafe> I think we can move on in parallel
19:07:34 <dtroyer> I am hoping to finish the api discovery next, auth could happen in parallel to that
19:07:38 <edleafe> no need to hold everything up
19:07:45 <briancurtin> ok cool, i like that
19:07:47 <dtroyer> but neither of those need to be hard blockers
19:08:24 <briancurtin> with that said, let's talk for a bit on the proposed design
19:08:34 <briancurtin> #topic https://wiki.openstack.org/wiki/PythonOpenStackSDK/ClassDesignDiscussion
19:09:32 <edleafe> The main goal of this design is separation of responsibilities to make development and testing easier, and avoid duplication across services
19:10:31 <briancurtin> edleafe: one of the biggest things i dislike about this is duplication which ends up being heralded as flexibility
19:10:38 <dtroyer> my initial reaction is to having a 'client' for each service…  we've discussed a single client (I think we used the word 'context' there) that handles multiple managers for the dispatching
19:10:51 <briancurtin> i'm not a huge fan of providing several ways to call one API
19:11:07 <Alex_Gaynor> I'd like to specifically object to "Rather than have fixed attributes, its attributes should be populated with the information returned from the API." -- I think this basically makes it impossible to document really well
19:11:22 <dtroyer> ++
19:11:30 <jamielennox> are those common methods actually on client or on the managers/
19:11:33 <Alex_Gaynor> (that's on resource)
19:11:48 <edleafe> briancurtin: For end users it is a huge benefit. At the SDK level, only one path is followed to the API
19:13:07 <briancurtin> edleafe: but at the SDK level i found we have the same lines of code copied & pasted everywhere to enable that
19:13:09 <edleafe> Alex_Gaynor: that's certainly possible, but a lot more of a maintenance burden
19:13:26 <Alex_Gaynor> In general, I'd like us to do hard work so our users' can have a great experience
19:13:26 <jamielennox> so this looks rather a lot like the current client's layouts. One of the things i was hoping to discuss here is if we could shift more burden onto the resource concept and away from the managers
19:13:51 <jamielennox> eg User.create(), User.update rather than client.users.update(id, **)
19:13:53 <terrylhowe> well, managers need to list, get, create
19:14:09 <briancurtin> several places end up delegating into a manager, so we have several places where we're just having a class with one method that sends itself elsewhere. some modules are fairly large but only fractions of the code actual do anything
19:15:35 <edleafe> briancurtin: actually, most of the duplication is in the base class, so there is only one copy of a call.
19:16:09 <terrylhowe> User.create() would be nice if users could populate a resource rather than pass in a dictionary
19:16:56 <bknudson> it would be interesting to see the code that we'd like for creating a user.
19:16:57 <edleafe> terrylhowe: that would be cool, but is that the most obvious way to create resources?
19:17:22 <jamielennox> edleafe: the manager design like the current clients have is very interdependant
19:17:40 <bknudson> is it like client.identity.user.create({'name': 'something', ... })  ?
19:17:47 <briancurtin> bknudson: perhaps we rejuvenate the idea of the "api_strawman" and take one or more approaches to fill out an example?
19:17:57 <edleafe> So if I'm storing a blob in swift, I would populate a storage object locally, and then call .save()? Something like that?
19:18:13 <jamielennox> edleafe: ++, that's what i was thinking
19:18:20 <jamielennox> passing dicts of attributes around is a pain
19:18:32 <edleafe> So more of an ORM-like approach
19:19:09 <Alex_Gaynor> Please no dicts :/
19:19:26 <edleafe> jamielennox: re: interdependence - clients should create managers with all the info they need. Managers shouldn't need a reference back to the client.
19:19:44 <edleafe> Alex_Gaynor: and no keyword params?
19:19:52 <Alex_Gaynor> keyword pramams are ok
19:19:58 <Alex_Gaynor> I don't want users passing dicts directly though
19:19:58 <edleafe> just attributes?
19:20:03 <Alex_Gaynor> it tends to make documentation really really hard
19:20:09 <Alex_Gaynor> and also makes good error messages hard
19:20:11 <jamielennox> edleafe: just resource objects
19:20:30 <dtroyer> I don't think the managers should need to contain any information…they're the logic for dispatching through the API
19:21:00 <jamielennox> dtroyer: right, we could even do client.list(User) and ditch the managers
19:21:04 <edleafe> Alex_Gaynor:  I envisioned methods with keyword parameters; terrylhowe is proposing building an object attribute-by-attribute, and then saving it.
19:21:07 <bknudson> what's an example of a manager?
19:21:21 <jamielennox> bknudson: the users part of client.users.list()
19:22:38 <bknudson> we're going to have a lot of manager
19:22:40 <bknudson> managers
19:22:43 <edleafe> bknudson: in the proposed design, the manager takes the user's request, determines the URI, headers, etc. that will be needed, and passes that to the http layer for the actual call
19:25:35 <edleafe> jamielennox: client.list(User) is just a different syntax
19:25:48 <briancurtin> edleafe: do you think you could come up with a minimal example on top of dtroyer's session wrapper, once it's in?
19:26:10 <edleafe> the question is where the logic goes for determining what the URI to call would go
19:26:14 <terrylhowe> I like the idea of the save() method on the resource to save it, but the manager will still need a create() method to create a new resource
19:26:22 <edleafe> that wouldn't be exposed to the dev/user
19:26:25 <jamielennox> edleafe: yes and no, it's a question of where you put all the information for how to build the urls
19:26:28 <terrylhowe> I'd think the manager edleafe the resource would have to reference it
19:26:57 <bknudson> there's only 1 manager for a resource, right?
19:27:01 <edleafe> resources would have reference to their manager, just like the client
19:27:07 <bknudson> User has a UserManager
19:27:08 <edleafe> bknudson: yes
19:27:13 <terrylhowe> yep
19:27:43 <edleafe> briancurtin: sure, but it would be fairly abstract without a service catalog
19:27:46 <edleafe> is that OK?
19:28:44 <briancurtin> edleafe: yeah, i think so. compare it to Alex_Gaynor's client.py example from the old api_strawman directory, just putting together simple swift operations
19:29:15 <edleafe> briancurtin: ok, I can try to have something committed in the next few days
19:30:05 <briancurtin> edleafe: cool, i think getting something into gerrit that we can see will help guide this better than an IRC talk (although maybe i'm wrong)
19:30:54 <edleafe> it would probably answer some of the obvious stuff, and raise much more interesting discussions.
19:31:22 <briancurtin> agreed. i think we could probably sit here and talk all day, but we'd be more productive to just get something on the board at this point and steer it from there
19:32:04 <edleafe> I'd like to also see a proposal for the ORM-like resource design
19:32:10 <briancurtin> #topic https://review.openstack.org/#/c/81882/ (Add requests.Session wrapper class)
19:32:30 <briancurtin> (oops, sorry to jump on top of that, edleafe, but that could also be cool)
19:32:44 <briancurtin> was that terrylhowe's thing?
19:33:23 <terrylhowe> I'm ready to move on
19:34:13 <briancurtin> anyway, with Alex_Gaynor here - is dtroyer's response on httpretty alright?
19:34:29 <Alex_Gaynor> (The answer might be that everyone just disagrees with me :-))
19:35:04 <briancurtin> i think most people agreed the last time we talked about it, but didn't have a great solution to work with at the moment (or something like that)
19:36:04 <dtroyer> I like the idea of httmock, but it needs to be proven yet, then added to the global requirements, and I didn't want to wait on that
19:36:20 <jamielennox> admittedly i'm biased here, but i see using httpretty and patching global state as easier that mocking the requests.request interface
19:36:42 <jamielennox> i don't see how global state matters when you are running test code that will only run one test at a time
19:37:14 <terrylhowe> httpretty makes me a little more confident things might actually work in this case
19:37:22 <briancurtin> at this point, i'd like to see if we can reach a consensus that httpretty is fine to build off of, and like jamielennox said, that global state mucking is confined to tests for the time being
19:37:43 <bknudson> httpretty seems to work so I'm fine with it.
19:37:51 <jamielennox> briancurtin: global state mocking is ALWAYS limited to tests - you would never do this in the library
19:38:27 <briancurtin> jamielennox: of course, i meant mucking, like doing dirty, dirty things with global state
19:38:29 <bknudson> at some point we're going to need a fake identity server
19:39:21 <briancurtin> Alex_Gaynor: thoughts?
19:39:25 <bknudson> at what level does that get inserted
19:40:00 <bknudson> I assume we're not going to have httpretty simulate keystone
19:41:35 <terrylhowe> A mock session would make sense for that
19:44:12 <briancurtin> i'm guessing Alex_Gaynor is busy in the other meeting - Alex_Gaynor, when you get back: speak now or forever hold your peace on httpretty
19:44:27 <briancurtin> #topic https://review.openstack.org/#/c/81988/ (Add redirection handling to openstack.session.Session)
19:45:22 <briancurtin> a couple of things left here, a quick s/assertTrue/assertEqual in a test. i think bknudson had mostly been addressed
19:45:39 <dtroyer> I see only one outstanding comment on that one, I have it addressed, am going to push it with the update to 81882
19:46:17 <briancurtin> i think that's probably good then
19:46:44 <briancurtin> (i was wrong about couple of things - just my remaining comment)
19:47:21 <briancurtin> #topic https://review.openstack.org/#/c/82646/ (Add API discovery support)
19:47:50 <dtroyer> This one is really still WIP…I'm moving more of the logic into the Version class...
19:47:51 <briancurtin> that one has a couple more things to address, but like was said earlier, can be done in parallel with the other work
19:47:56 <briancurtin> ah
19:48:09 <dtroyer> and renaming the classes to make more sense
19:48:16 <briancurtin> cool
19:49:11 <briancurtin> so at this point, i think we have more actionable items to move forward on
19:49:48 <briancurtin> #action edleafe: prepare minimal example of manager-client-resource
19:50:15 <briancurtin> #action revive Alex_Gaynor client
19:50:36 <briancurtin> #action possible ORM-style client
19:50:50 <briancurtin> anything else to build on at the moment?
19:51:05 <edleafe> correction: ORM-style resource
19:51:13 <briancurtin> oops, yeah
19:51:54 <briancurtin> 9 min left - anything else to chat about while we're here?
19:52:49 <dtroyer> FWIW, I plan on proposing an OpenStack program soon for client-side stuff that will initially include OpenStackClient.
19:53:25 <dtroyer> I understand the TC wants to hold off including additional projects that are early in implementation, such as this one, but eventually that is where they would also live
19:54:12 <briancurtin> dtroyer: what other types of projects would you foresee that including?
19:54:13 <dtroyer> I am looking for a name that sounds general enough to include both
19:54:41 <dtroyer> much of what is currently in motion for not-REST-server stuff, except Horizon
19:54:52 <dtroyer> that wants to join
19:56:15 <bknudson> I'm surprised that https://review.openstack.org/#/c/81882/ didn't merge.
19:56:39 <bknudson> it's approved and verified
19:56:44 <dtroyer> it couldn't with Alex's −2 still attached
19:56:45 <briancurtin> bknudson: i think alex gaynor's original -2 was holding it up. he just changed it to -1 with recent comments
19:57:04 <briancurtin> dtroyer: would that program be something like "developer experience"?
19:57:28 <dtroyer> it would include that, but the CLI is also 'user experience'
19:58:17 <briancurtin> dtroyer: cool, would like to know more as it develops
19:58:56 <dtroyer> both of those phrases carry additional expectations in the community and I want to be careful to not make people thing this program is all of those things
19:59:43 <briancurtin> true. naming isn't my specialty, but if i have anything, i'll let you know :)
19:59:56 <dtroyer> ok, thanks
20:00:07 <briancurtin> #endmeeting