19:00:46 <edleafe> #startmeeting python-openstacksdk
19:00:47 <openstack> Meeting started Tue Apr  8 19:00:46 2014 UTC and is due to finish in 60 minutes.  The chair is edleafe. 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:50 <openstack> The meeting name has been set to 'python_openstacksdk'
19:00:59 <edleafe> #link https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK#Agenda_for_2014-04-08_1900_UTC
19:01:18 <edleafe> #topic Roll Call
19:01:25 <dtroyer> Hey all, Dean Troyer, Nebula
19:01:27 <edleafe> To start, will everyone here for the Python OpenStack SDK meeting please state their name and business affiliation?
19:01:34 <terrylhowe> Terry Howe, HP
19:01:38 <wchrisj> Chris Johnson, HP
19:01:40 <edleafe> Ed Leafe, Rackspace
19:02:17 <edleafe> I know that Brian Curtin and Alex Gaynor are both in transit to PyCon, and won't be joining us
19:02:30 <wchrisj> wow - light crowd indeed
19:02:57 <edleafe> yeah, and probably next week, too
19:02:58 <jamielennox> Jamie Lennox, Red Hat
19:03:04 * dolphm is always lurking
19:03:11 <wchrisj> always!
19:03:19 * edleafe is always keeping an eye out for dolphm
19:03:25 <wchrisj> lol
19:03:50 * dolphm always. *shifty eyes*
19:04:02 <edleafe> #topic Discussion of base class code
19:04:06 <edleafe> #link https://review.openstack.org/#/c/85720/
19:04:21 <edleafe> I pushed this code to start the discussion of the proposed class design
19:04:33 <edleafe> thanks to terrylhowe for some initial feedback
19:04:41 <edleafe> has anyone else had a chance to review it?
19:04:55 <dtroyer> I have had a quick look, not in detail
19:04:58 <terrylhowe> looks good in general I thought, I’m excited to have something to work with
19:05:30 <dtroyer> it seems to be very similar to the existing lib's architecture?
19:05:36 <jamielennox> so i thought (was hoping) we were looking at a more ORM approach?
19:05:45 <edleafe> I deliberately left out the details of session/context/identity - that can be determined later
19:06:11 <edleafe> jamielennox: that was someone else's proposal, I believe
19:06:26 <jamielennox> having worked with the current libs i'm not a big fan of the manager layer
19:06:49 <edleafe> but I don't see how that couldn't be added to this design if it was desired
19:06:59 <dtroyer> IIRC having HTTP methods in both the manager resource classes contributes to some of the difficulties we've seen
19:07:09 <dtroyer> manager *and* resource...
19:07:45 <jamielennox> dtroyer: ++, we've had problems with the resource calling back to the manager with itself as an argument
19:08:19 <edleafe> In this code, resource has no http methods
19:08:37 <edleafe> jamielennox: wasn't the issue that the references were not being cleaned up?
19:08:42 <dtroyer> BaseResource.get() and BaseResource.delete() look like that to me
19:09:04 <jamielennox> edleafe: that was an issue of keystoneclient, not the same issue though
19:09:15 <edleafe> jamielennox: ah, ok
19:09:29 <edleafe> dtroyer: they delegate everything to the manager
19:09:41 <edleafe> manager is the only class that talks to http
19:09:51 <dtroyer> right, but that requires the linkage that has been part of the problem
19:10:47 <edleafe> so what would be a better way?
19:10:48 <dtroyer> or have I misunderstood the problem?
19:11:05 <edleafe> I'm not sure I understand the problem
19:11:08 <dtroyer> I'm in favor of either managers or resources, I'm not convinced we need both
19:11:15 <edleafe> I thought it was circular references to the client
19:11:58 <edleafe> dtroyer: not sure I can picture that. What would managers return?
19:12:16 <edleafe> or does every resource have the full manager code within it?
19:12:31 <dtroyer> dicts.  that's the other extreme to the direction jamielennox was asking about
19:13:19 <dtroyer> I'm happy with using Resource classes, but they should only know about themselves.  I think including linkage for them to be able to reload themselved, or whatever, is too much
19:13:30 <edleafe> I've used SDKs that return primitives. I always end up writing a wrapper around them to create objects I can work with in code
19:13:57 <dtroyer> so that goes into a higher layer API…we've talked about that before
19:14:03 <jamielennox> edleafe: sure but you should write the primatives first and the wrappers when you understand the problem
19:14:10 <dtroyer> or are you proposing that and we build the primities below this?
19:14:17 <jamielennox> s/understand/more experience with
19:15:37 <edleafe> dtroyer: so you would always have to pass in the full resource to the client/session
19:16:25 <edleafe> e.g., if you have a swift object, you need to pass its container and the object (or an object with a container reference) to the client to delete/update the object?
19:17:27 <dtroyer> if you have a swift object resource, presumably you needed a container to get it in the first place or will need one to create the object.  even if you hide that by putting the verb in the resource, it doesn't change the fact that the API requires a container
19:17:27 <terrylhowe> well, swift is an odd case
19:18:24 <notmyname> ?
19:18:34 <edleafe> terrylhowe: true, but there are other nested resources (databases on trove instances, e.g.)
19:18:44 <dtroyer> whether the object class knows it's container is a design detail, but they are both resources and we know there will be other resources that need to know about other resources so that isn't going to be unusual
19:19:58 <dtroyer> for the primitive (I like that word to describe the 'lower layer') too much magic anywhere is not a good thing...
19:20:07 <edleafe> Can anyone describe the problem with resources having a reference to their manager? Is it simply a circular reference thing, or is there some other bad juju going on?
19:21:04 <dtroyer> I think that is complicated by the relationship between managers and the various client objects.  that may not be a problem here, which is why I asked, I don;t think I know enough about it to say
19:21:05 <bknudson> the problem is the circular reference and keeping a connection open to the servers
19:21:51 <dtroyer> bknudson: so if the manager didn't own/posess/control/whatever the session that should be avoidable here?
19:22:03 <bknudson> dtroyer: right, that would be fine
19:22:26 <dtroyer> ok, cool.  I think I have the issue straight in my head then
19:22:40 <edleafe> thanks bknudson
19:23:00 <bknudson> no problem, we ran into this with horizon / keystone recently
19:23:06 <edleafe> so the reason for separating out the http class is so that it could live wherever it fit best
19:23:19 <edleafe> and also so it could be stubbed out in testing
19:23:26 <bknudson> worked around it by disabling connection pooling
19:24:16 <jamielennox> isn't the http module essentially the session object?
19:24:31 <wchrisj> that's my understanding jamielennox
19:24:32 <edleafe> jamielennox: yeah, pretty much
19:24:42 <edleafe> bare bones
19:24:50 <edleafe> just enough to get it to work
19:24:50 <jamielennox> was that merged?
19:24:54 <wchrisj> I asked that very question 2 weeks ago
19:25:14 <terrylhowe> yes, but it doesn’t have the auth token yet
19:25:33 <wchrisj> why terrylhowe
19:25:34 <wchrisj> ?
19:25:53 <terrylhowe> well, I don’t want to get off topic
19:26:05 <wchrisj> ok
19:26:17 <edleafe> #topic session class status
19:26:21 <edleafe> now you're on topic
19:26:23 <edleafe> ;-)
19:27:04 <terrylhowe> I didn’t know if dtroyer was planning on adding the auth token to the session
19:27:21 <bknudson> is there doc on the session class?
19:27:24 <dtroyer> I am but I was working on api discovery first
19:27:46 <jamielennox> the session was mostly taken from keystoneclient, and i assume dtroyer was holding off on the auth plugins - though he might have different ideas on how session/auth relate
19:27:54 <dtroyer> bknudson: only those bits I  had in an early patchset so far
19:28:33 <dtroyer> I was waiting on the auth to settle down a bit.  then jamielennox and I are going to have a contest in Atlanta to see who wins… ;)
19:29:02 <bknudson> since you're not awake at the same time just hand off
19:29:48 <edleafe> Do we have a description on how the API discovery will work?
19:29:50 <jamielennox> dtroyer: grecko roman?
19:30:20 <edleafe> simply derived from the service catalog, or is there more to it?
19:31:22 <terrylhowe> well, he is getting the versions from the endpoint
19:31:38 <dtroyer> edleafe: not a comprehensive one yet.  I plan to revive https://review.openstack.org/#/c/82646/ with more of the knowledge moved into the version class…hopefully soon
19:32:07 <edleafe> dtroyer: Can you do a blueprint for this?
19:32:33 <dtroyer> jamielennox: kart racing…  Atl is in the heart of NASCAR country after all...
19:32:50 <wchrisj> IIRC the discovery object/class will factory up a Keystone/Identity service class, right dtroyer ?
19:32:50 <bknudson> could just merge https://review.openstack.org/#/c/82646/ and clean it up with separate commits
19:33:00 <bknudson> since we don't have to worry about backwards compat
19:33:32 <dtroyer> edleafe: sure.  one of the things I started was collecting as much as I could of past discussions to get a feel for where we are headed as a project…need to get it into a clean form yet
19:34:16 <dtroyer> wchrisj: generalize to any API and yes, or at least tell the caller which one to use if it doesn't create it directly
19:34:30 <edleafe> dtroyer: ok, that's great. In the past I've found blueprint discussions are more productive than code reviews for new implementations
19:35:05 <edleafe> #task dtroyer: blueprint for API discovery
19:35:25 <edleafe> OK, let's move on
19:35:27 <edleafe> #topic Other design proposals
19:35:55 <edleafe> Is anyone besides Brian Curtin working on an alternative design for the overall SDK structure?
19:36:19 <terrylhowe> not that I know of
19:36:48 <jamielennox> i'll have a crack at an ORM based resource - just to flesh it out for discussion
19:37:00 <jamielennox> will be up before next meeting
19:37:05 <terrylhowe> I would like to see that
19:37:12 <edleafe> jamielennox: cool
19:37:12 <wchrisj> I would like to see that too
19:38:44 <edleafe> OK, so it looks like we will have two basic designs to select from
19:38:47 <edleafe> #topic Timeframe/method for selecting design
19:39:09 <edleafe> Any suggestions on how to make this decision?
19:39:18 <edleafe> We need to have a good discussion of the base design before moving ahead, but at some point we'll need to select one and move ahead.
19:39:50 <jamielennox> with a lot of these questions i've been assuming resolution will be at the summit
19:40:09 <jamielennox> get all competing ideas up for code review, then debate the nuts and bolts in person
19:40:41 <bknudson> is an orm interface at a higher level than the other interface?
19:40:51 <wchrisj> jamielennox What sort of plans are there around meeting at the Summit?
19:40:53 <bknudson> i.e., would orm require a lower level interface?
19:41:02 <jamielennox> bknudson: competing - but no i want it to stay lower
19:41:04 <edleafe> bknudson: I don't think it has to be
19:41:25 <edleafe> I was going to try to add one to my design, but time and all that...
19:41:26 <jamielennox> bknudson: always keep these things low level until there are actual uses i think
19:41:26 <bknudson> for example, sqlalchemy-ORM is implemented on sqlalchemy-sql
19:42:07 <terrylhowe> I would expect the session stuff to be the lower level
19:42:17 <bknudson> so session stuff either way?
19:42:36 <jamielennox> bknudson: yea, i think so
19:42:40 <edleafe> So is the consensus that we will be debating these designs, and not implementing anything concrete until over a month from now?
19:43:02 <terrylhowe> that is a long time
19:43:08 <jamielennox> when put like that..
19:44:14 <edleafe> how many people will be at PyCon this week in Montreal?
19:44:40 <edleafe> (thinking we could have a pre-summit)
19:45:23 <jamielennox> i wish :)
19:46:13 <edleafe> I'll take the silence as confirming that PyCon will not be the place to decide this.  ;-)
19:47:02 <edleafe> So let's wait until Brian's code is posted, and we can re-visit this next week
19:47:28 <jamielennox> edleafe: is brian's general design in a blueprint or something?
19:47:43 <edleafe> jamielennox: no, it was supposed to be code
19:48:13 <edleafe> last week we agreed to have close-to-working code for everyone to evaluate
19:48:34 <edleafe> Brian is one of the PyCon organizers, and has been a little busy with that, though
19:48:49 <jamielennox> that's fair
19:49:34 <edleafe> #topic Anything else on your minds?
19:49:48 <edleafe> We have about 10 minutes left
19:50:05 <edleafe> Any other issues we should discuss?
19:52:21 <edleafe> Then I guess we all get to go back to work a little early  ;-)
19:52:23 <edleafe> #endmeeting