19:00:12 <briancurtin> #startmeeting python-openstacksdk
19:00:13 <openstack> Meeting started Tue Apr 22 19:00:12 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:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:16 <openstack> The meeting name has been set to 'python_openstacksdk'
19:00:41 <briancurtin> If you're here for the python-openstacksdk meeting, please state your name and affiliation
19:00:56 <Alex_Gaynor> Alex Gaynor, (Rackspace, among others)
19:01:03 <edleafe> Ed Leafe, Rackspace
19:01:05 <wchrisj> Chris Johnson, HP
19:01:12 <briancurtin> Brian Curtin, Rackspace
19:01:25 <jamielennox> Jamie Lennox, Red Hat
19:02:35 <briancurtin> While others may be showing up, here's an agenda: https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK#Agenda_for_2014-04-22_1900_UTC
19:02:35 <terrylhowe> Terry Howe HP
19:03:38 <briancurtin> I guess we'll get started, if people roll in, they roll in
19:03:53 <briancurtin> #topic 3 weeks out from summit, would like to see if we can tighten up and push forward
19:04:37 <briancurtin> What do we think is necessary at this point to reach a consensus on either Jamie's or Ed's class proposals?
19:04:52 <briancurtin> Are we close, do we need more time, more proposals, etc?
19:06:29 <jamielennox> i'm biased here so not waying in but i haven't heard any more proposals
19:06:37 <edleafe> The problem for me is that there is scattered feedback - nothing to summarize what someone feels are the fundamental agreement or disagreement with an approach
19:07:09 <edleafe> Someone might object to a method name, or a particular facet of the design, but still agree with the overall direction
19:07:22 <briancurtin> jamielennox: nope, haven't seen any others, not sure if any planned. just asking
19:07:48 <jamielennox> edleafe: right - either way is going to need tweaking
19:08:31 <jamielennox> my object to managers is that the interaction between the resource object and the manager is always going to be a bit difficult
19:08:39 <jamielennox> this we've found with the current managers
19:09:05 <jamielennox> the obvious problem with classes is that we need something higher level to manage the session (or get a user to do it)
19:09:08 <edleafe> jamielennox: that was with keystoneclient, right?
19:09:25 <jamielennox> edleafe: keystoneclient has all sorts of other problems as well
19:09:39 <jamielennox> but a standard pattern is this .getid() thing
19:09:55 <jamielennox> where you do an update and you don't know if an object or an id has been passed to the manager
19:10:51 <edleafe> That's a desirable design for an SDK user, IMO.
19:10:52 <jamielennox> and for nested resources where you end up with multiple required id's being passed, how do you pass an object to that
19:11:09 <jamielennox> these have just always felt clunky to me
19:11:25 <edleafe> what is a 'nested resource'?
19:11:38 <jamielennox> /users/X/roles/Y
19:11:39 <terrylhowe> security group rules I suppose
19:12:08 <edleafe> ah
19:12:19 <edleafe> not particularly problematic
19:12:29 <briancurtin> before we get into the specifics of the proposals, can we first work out the mechanism by which we'll make a decision? i want to make sure we know how we can make this decision before we get into debating
19:12:32 <jamielennox> agreed
19:12:44 <jamielennox> it can be made to work if we don't inherit the existing stuff
19:12:55 <edleafe> pass in two params: user and role. Either can be object/id. The URL is constructed with the resolved IDs.
19:13:35 <jamielennox> edleafe: right, but then you call role.update() and it routes to the manager - so role has to keep track of user as well
19:13:36 <edleafe> briancurtin: import random?
19:13:39 <edleafe> ;-)
19:13:55 <jamielennox> edleafe: again it's not unsolvable just ugly in the existing client work
19:14:26 <edleafe> jamielennox: I can see that, but in practice I haven't found it any more complex than it needs to be
19:14:38 <edleafe> and it buys a lot of convenience for the user
19:14:53 <jamielennox> briancurtin: i don't know - at the moment we have one vote each way and a moderator - everyone else is quiet
19:14:55 <edleafe> I try to look at it from their POV and not mine as an SDK developer
19:15:32 <briancurtin> jamielennox: should we actually use gerrit for the voting by some certain date? a bunch of people aren't here
19:15:54 <jamielennox> edleafe: i'm not sure if either is better that way
19:16:31 <jamielennox> edleafe: though i consider the objects to be fairly low level - ie there will be a v1, v2, v3 object and there will most likely be another layer on top managing the versions
19:16:53 <edleafe> jamielennox: Understood. My view is colored by my experience with what users have liked and not liked.
19:17:18 <jamielennox> edleafe: we can do objects at low level and some sort of managers at a higher? the first draft i put up had a manager concept
19:18:24 <edleafe> you could integrate managers into resources. I've done that but the design gets heavy quickly
19:18:25 <jamielennox> having trouble looking that far ahead - but i agree for the user facing stuff we don't want them to deal with there own sessions
19:19:18 <edleafe> session meaning… ? The authed session? Or the underlying requests-based transport?
19:19:28 <jamielennox> briancurtin: i don't have a better idea
19:19:29 <Alex_Gaynor> I just want to note that I really don't feel strongly at all about this issue.
19:20:07 <jamielennox> edleafe: I want to keep talking about this - but maybe post meeting
19:20:40 <briancurtin> jamielennox: would it work to clear the votes on gerrit and just have a tally of them on maybe thursday?
19:20:57 <edleafe> jamielennox: Sure. I gotta run shortly after the meeting, but should be online later
19:21:21 <jamielennox> edleafe: it's 5:20am here - i'll be around for a while :)
19:21:29 <edleafe> haha
19:22:10 <jamielennox> briancurtin: that or just a wiki page with two columns
19:22:28 <jamielennox> briancurtin: i guess it's just a matter of who else cares
19:22:57 <briancurtin> jamielennox: wiki seems better, can keep history. i'll set it up. i don't actually know who cares, but whoever they are i'd like to hear from. i imagine dean cares but isn't ehre
19:23:00 <briancurtin> *here
19:23:22 <jamielennox> yea, i expect so - he's probably done the most with the existing clients
19:23:43 <wchrisj> wiki is good
19:24:05 <briancurtin> once we have that, as far as moving on even further, can we then implement the minimal bits of Keystone to get a service implemented on top?
19:24:31 <terrylhowe> what time Thursday?
19:24:49 <terrylhowe> The end of Thursday UTC?
19:24:54 <jamielennox> briancurtin: so do you mean auth or keystone resources?
19:24:55 <briancurtin> terrylhowe: that's what i was thinking
19:25:07 <briancurtin> jamielennox: actually i think i mean auth
19:25:11 <terrylhowe> cool
19:25:31 <jamielennox> briancurtin: so auth is going to be tied up with session because it is carried around
19:25:42 <edleafe> jamielennox: yes
19:26:02 <briancurtin> ah, true
19:26:06 <edleafe> there are use cases for multiple authed sessions existing at once
19:26:23 <jamielennox> i know how i'd do it but i'm waiting to see what dtroyer is up to - we discussed this a bit post meeting last week
19:27:02 <jamielennox> i think we can say though that there is a plugin to session and mock up something simple which can be fixed later
19:28:27 <terrylhowe> Did you take a look at https://review.openstack.org/#/c/88485/ jamielennox
19:28:44 <jamielennox> ah - no i hadn't seen that
19:29:09 <briancurtin> terrylhowe: forgot to finish that review, but for your comment - yes, that's what i was thinking
19:29:40 <Alex_Gaynor> it looks like it probably needs to be rejiggered to work with the transport stuff, but looks ok to me
19:30:09 <jamielennox> terrylhowe: i seem some minor comments, but it looks good to me
19:30:25 <briancurtin> jamielennox: so given a chat with dtroyer, do you think we're reasonably close to having something where we could implement, e.g., creating a server?
19:31:01 <jamielennox> briancurtin: i think if we pick either basic design and have auth then it's mostly a matter of starting on low level apis
19:31:14 <jamielennox> low level = version specific
19:31:42 <briancurtin> ah, yeah that's good enough - don't need the higher level version abstraction piece at the moment
19:32:10 * briancurtin needs to get terminology straight
19:32:28 * jamielennox needs to stop just throwing out terms without thinking about them
19:35:39 <briancurtin> so at this point we have EOD UTC thursday for the wiki vote, and a chat with dtroyer to spell out some auth ideas, and then we're on the way to version-specific API building. i think that's a decent enough summary to take away
19:36:46 <briancurtin> since i kind of interrupted to get the high level things out of there, jamielennox and edleafe did you want to continue the manager-ish discussion or is that for later?
19:37:15 <edleafe> Does anyone else have opinions on either approach?
19:38:11 <briancurtin> my experience as an implementer is close to zero, but i like the feel of jamie's approach from my reads. i don't have a super strong swing that way, though
19:39:57 <briancurtin> part of what gets me on edleafe's is the feeling of duplication. i get how it works, but i poke around and leave feeling that being able to do the same thing several different ways isn't a positive quality. however, to an end user of a higher level "compute" or "storage" abstraction, maybe that's covered up by that level
19:40:52 <edleafe> briancurtin: I get what you're saying, but look at these use cases:
19:40:53 <briancurtin> perhaps that is clouded (no pun intended) by having gone through it in pyrax, which does the manager/client/resource
19:41:18 <Alex_Gaynor> You super intended that pun.
19:41:38 <edleafe> you have a storage_object reference, and you want to delete that in swift. calling obj.delete() is simple enough.
19:42:11 <Alex_Gaynor> So my feeling on the meta issue of "multiple names" for the same thing is that it can be ok, but all the names have to be /identitical/ behaviors, you can't have multiple ways to do the same thing and whether they are the same things varies by stuff.
19:42:12 <edleafe> but if you know the container and object names, you could call client.delete(cont, objname) too
19:42:32 <edleafe> it is frustrating to force the user to get an object reference just to delete it
19:43:10 <edleafe> briancurtin: yeah, I've gotten a *ton* of feedback over the years
19:43:19 <jamielennox> edleafe: that is handled by classmethods on mine StorageObject.delete_by_id(session, cont, objname)
19:43:43 <jamielennox> i don't know if there is a usability argument either way
19:44:06 <jamielennox> but i do like the seperation between this is a string id and this is an object
19:44:11 <edleafe> jamielennox: Yeah, I think we're both used to one way
19:44:56 <jamielennox> heh, the problem is that i'm used to the managers - i recognize it's currently a terrible implementation but it makes me want something else
19:45:08 <wchrisj> I prefer the classmethod approach - less things to keep track of locgically
19:47:27 <briancurtin> i think i mostly prefer that as well, but i'll take another good look with edleafe's comments in mind
19:48:50 <edleafe> And FWIW I'm not opposed to the classmethod approach.
19:49:09 <edleafe> I need to work with it more to see the pros/cons
19:49:19 <edleafe> it just feels upside-down right now
19:51:34 <jamielennox> edleafe: i think when looking at it consider it mostly for the api specific work, they are going to be resources that are manipulated by a higher level before being exposed to a user
19:52:25 <edleafe> jamielennox: not sure I follow what you have in mind
19:52:48 <jamielennox> i don't mind the design being like this all the way up but for this in particular
19:53:01 <jamielennox> edleafe: so for most services we are going to need multiple API implementations
19:53:14 <jamielennox> keystone v2 and v3 nova, v1 v3 etc
19:54:29 <edleafe> How does that affect the resource?
19:54:38 <jamielennox> so i expect we will have (for example) a user layer which wraps around a v2 or v3 user
19:56:21 <jamielennox> i like the design better this way in general, but if nothing else i think it will be easier to work with for the version specific layer - even if we wrap a client object around it later
19:58:38 <briancurtin> 2 min left, any last words before heading back to -sdks?
19:58:54 <edleafe> none here
19:59:09 <jamielennox> i'm good
19:59:55 <briancurtin> i will go ahead and put together that wiki page, email it, and mention it in the channel tomorrow to the few people i know weren't here. we'll figure it out EOD thursday, then see if we can move onward with the auth stuff and build on
20:00:13 <Alex_Gaynor> Awesome.
20:00:20 <briancurtin> #endmeeting