19:00:24 <briancurtin> #startmeeting python-openstacksdk
19:00:25 <openstack> Meeting started Tue Apr 15 19:00:24 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:29 <openstack> The meeting name has been set to 'python_openstacksdk'
19:01:10 <briancurtin> If you're here for the python-openstacksdk meeting, can you state your name and affiliation?
19:01:38 <briancurtin> FYI i know alex isn't going to make it, i believe ed is on vacation the rest of the week
19:02:01 <bknudson> Brant Knudson -- IBm
19:02:06 <briancurtin> Brian Curtin, Rackspace
19:02:12 <wchrisj> Chris Johnson, HP
19:02:18 <dtroyer> Dean Troyer, Nebula
19:02:32 <jamielennox> Jamie Lennox, Red Hat
19:03:19 <briancurtin> I think that'll probably be it
19:03:47 <jamielennox> small one today
19:03:58 <briancurtin> Just a quick mention before getting going: so far the probably 7-8 people I've talked to about the general goals and direction of this project here at PyCon are pretty excited to see where it goes. may have a few people to jump in and get involved as well
19:04:51 <briancurtin> since Ed isn't here, perhaps we start with jamielennox
19:05:03 <briancurtin> #topic https://review.openstack.org/#/c/86227/ Add base resource class
19:05:40 <briancurtin> jamielennox: i only took a look shortly before the meeting since i was occupied, but i'm a fan of this FWIW
19:05:52 <jamielennox> right, so i realize that the base class there is a long way from perfect - but in general i prefer the concept of doing class based lookups rather than  managers
19:06:14 <jamielennox> the mixing it with managers actually worked better than i anticipated though
19:06:43 <jamielennox> dtroyer: you and i have discussed the managers concepts a few times, did you get a chance to look at that layout?
19:07:05 <dtroyer> sadly, no.
19:07:48 <jamielennox> i was starting another client recently and found again that the managers approach (and the base classes in OSLO) don't cover all situations
19:08:15 <bknudson> another client?
19:08:19 <bknudson> for kite?
19:08:34 <jamielennox> bknudson: yes
19:08:45 <bknudson> jamielennox: just start with the openstack-sdk
19:09:06 <briancurtin> jamielennox: what are some of these situations where it doesn't work?
19:09:21 <jamielennox> partially it's about implementation there
19:09:35 <jamielennox> but essentially there is not a base resource key
19:09:55 <jamielennox> or more correctly there is a base resource key - but the resource is just a string
19:10:02 <jamielennox> eg { 'key': 'abcdef' }
19:11:01 <jamielennox> anyway - either the manager or base class approach can be improved to make these things work - i think it's just a matter of choosing the general direction
19:11:48 <bknudson> jamielennox: class Manager says it's only there for compatibility with existing clients... but there's no existing clients at this point.
19:12:05 <jamielennox> also there was the situation there where a lot of operations (like get) aren't supported by kite
19:12:28 <bknudson> a resource without a GET operation... weird.
19:12:32 <jamielennox> bknudson: it was a way of keeping compatability if we need to go the client.users.list() approach
19:12:40 <jamielennox> bknudson: key's are private - you can't retrieve them
19:13:07 <bknudson> bknudson: is HEAD supported?
19:13:19 <dtroyer> I'd be all for not having any compatability layers in the SDK.  If we need them they should be explicitly marked and separate
19:13:35 <briancurtin> +1 to dtroyer
19:13:37 <jamielennox> bknudson: talking to yourself?  - no it's not
19:13:48 <jamielennox> dtroyer: i agree
19:14:36 <jamielennox> without it it just means you have to pass a session object around a lot
19:14:47 <jamielennox> there is probably some way we could abstract that at a higher level
19:16:15 <jamielennox> but i don't see that as a problem for a basic version specific class
19:16:52 <briancurtin> agreed
19:17:20 <jamielennox> i'm also not convinced on the _by_id suffix to distinguish classmethods but i figure that's a detail at this point
19:20:07 <briancurtin> yeah, i think that's fine
19:20:27 <bknudson> jamielennox: what's an example of a resource, like identity.User ?
19:20:41 <jamielennox> bknudson: yes
19:22:23 <bknudson> jamielennox: do you think some of the Resource API depends on how well OpenStack REST APIs conform to some convention?
19:22:42 <jamielennox> briancurtin: the issue with urljoin is that it obeys web semantics, so if you urljoin('prefix', '/path') it would take that as you clicking on a url for /path and ignore the prefix
19:23:21 <briancurtin> jamielennox: ah, ignore me then
19:23:24 <bknudson> for example, it's got "resource_key" and "resources_key" -- but maybe there's no plural form of the key element.
19:23:47 <jamielennox> bknudson: i do, but i see that as the 90% case (and the way that it is handled by almost all clients now)
19:23:56 <jamielennox> bknudson: you can also override classmethods
19:24:59 <dtroyer> re: the urljoin() stuff, would it make sense to consolidate the manual handling into our own version of urljoin() with the desired behaviour?
19:25:21 <jamielennox> dtroyer: yea, it would
19:25:40 <jamielennox> i don't think any of those locations are doing anything funny
19:26:20 <jamielennox> bknudson: also in the case of resource_eky and resources_key everywhere that they are used in resource.py should be lead with a if self.resource_key: block
19:26:37 <wchrisj> encapsulation FTW dtroyer
19:27:08 <briancurtin> yep, now that i know urljoin is wrong, +1 to doing that
19:30:16 <briancurtin> anything else on this one for now? unfortunately i'm behind and need to have more looks, so i don't have much input at the moment
19:30:27 <dtroyer> I think my biggest conceptual hurdle to this approach is the semantics of list().  All other actions you either have a resource or the information to create one.
19:30:35 <dtroyer> I don't think it is a blocker though
19:31:48 <wchrisj> Do we have a consensus on the Manager class?
19:31:56 <wchrisj> Is it staying or going?
19:32:34 <dtroyer> if it only there for compat I think it can go
19:32:56 <wchrisj> +1 dtroyer
19:33:04 <jamielennox> i can remove it for now
19:33:10 <jamielennox> i don't think we need it currenlty
19:33:44 <briancurtin> sounds good
19:33:49 <wchrisj> Dont have a strong feeling on it, but do think the simpler we can start, the better; it doesnt seem to add much value.
19:35:56 <jamielennox> dtroyer: would you like to just remove list() for now as well
19:36:08 <jamielennox> all we really need at this point is a consensus on the object vs manager approach
19:36:26 <dtroyer> not yet, I want to think about how it should look though...
19:36:45 <bknudson> it would be nice if there was example client code
19:37:10 <jamielennox> bknudson: right, i know the keystone stuff well enough to have a go at that
19:37:13 <wchrisj> The sooner that I can fire up the client and at minimum just do a basic auth, the better
19:37:31 <wchrisj> even if it's not the pluggable auth that is the end goal
19:38:09 <dtroyer> bknudson: I've thought that too.  I have some small scripts that I used for testing Session and discovery
19:38:31 <dtroyer> should we have some samples in the repo at some point?
19:38:39 <briancurtin> wchrisj: YES. i'm hoping to get some time later today or tomorrow to bring back an old proposal of alex gaynor's, and then hopefully soon enough we pick a route and run with it
19:38:59 <briancurtin> dtroyer: absolutely
19:39:14 <jamielennox> yea, it will depend on how we adhere to that old proposal of having an object per request we make
19:39:19 <wchrisj> briancurtin What did Alex's proposal specifically address?
19:39:22 <briancurtin> not sure how to define "some point", but i'd really like that to be sooner than later
19:39:33 <bknudson> I'm always a fan of having as much of the documentation in the docstrings as we can
19:39:47 <bknudson> even sample code
19:41:20 <briancurtin> wchrisj: i don't really have a great description of it, but i'll dig up the original file (it was one of the examples that we removed before kicking off the session wrapper)
19:41:47 <wchrisj> briancurtin - I remember the proposal; dont remember the specific content
19:42:37 <briancurtin> wchrisj: here's what it was: https://github.com/stackforge/python-openstacksdk/blob/956418f5d87156673a2daf3b67ed31b285e15690/api_strawman/client.py
19:43:58 <bknudson> I hope we don't have to build the auth data with json.dumps({"auth": {"passwordCredentials"...) by the time this is done
19:44:03 <wchrisj> briancurtin - Understood. My only issue is that code is pretty monolithic; would prefer OO approach...
19:44:56 <bknudson> oh, I thought this was sample client code.
19:45:22 <jamielennox> my ideal here is that even if we don't import the other clients that session and auth plugin (which are almost exactly the same as keystoneclient) could be extracted into a base library
19:45:24 <briancurtin> bknudson: i guess i'll sit down with alex and see what he intends with it
19:45:28 <wchrisj> bknudson - It is sample client code
19:45:30 <jamielennox> to be shared between -sdk and other clients
19:45:43 <briancurtin> i could have just misunderstood it
19:45:48 <wchrisj> ok
19:46:05 <jamielennox> new review upload without a manager and with a urljoin
19:46:18 <jamielennox> https://review.openstack.org/#/c/86227/
19:47:23 <dtroyer> if everything could only be that fast… ;)
19:47:42 <wchrisj> w00t
19:50:11 <jamielennox> dtroyer: you are right on list() not everything supports marker and limit and there are a number of problems there that i think are best tackled as we come across them
19:51:02 <jamielennox> so long as list() etc are explicity enabled (rather than now where every manager automatically gets a list, update etc that doesn't always work) i don't see this being a problem
19:52:35 <jamielennox> there were a lot of comments on the first review about duplicating the session calls into the resource.py file - did that need make sense?
19:53:16 <jamielennox> and for bonus points did anyone have an opinion on the Session Binding review i linked https://review.openstack.org/#/c/86237/ and if it would be useful here?
19:53:29 <dtroyer> I think the Accept header should be handled in Session, enabled with an arg, and those methods can all go away
19:54:30 <dtroyer> more than just the Resource object will want it
19:55:22 <jamielennox> dtroyer: in the general case (and assuming that plugins here will have similar functionality to ksc) there is more than just accept that is going to be different per client view though
19:55:43 <jamielennox> particularly i'm thinking service_type and service_version
19:55:57 <terrylhowe> It definitely doesn't belong in a resource class, but as long as the plan is to get rid of it in the future ...
19:55:57 <dtroyer> sure, and that's where the headers arg comes in, but this Accept is pretty common
19:56:13 <jamielennox> terrylhowe: ++
19:56:41 <jamielennox> dtroyer: i'm willing to put accept in as a special case
19:56:59 <jamielennox> dtroyer: but service_type etc aren't headers and they will otherwise need to be set on every call
19:57:14 <dtroyer> it matches the json handling that is already there.
19:57:53 <dtroyer> service_type, etc get their own Resource subclass?  or mixin or whatever?
19:58:52 <jamielennox> dtroyer: the point of the current session object is to be able to do a .get('/path/to', service_type='identity', version=(3,1)) and have the session/plugins manage the catalog for you
19:59:07 <jamielennox> s/the point/a point
19:59:47 <dtroyer> there's no reason that can't continue, that doesn't belong in the low-level Session/request interface
20:00:02 <dtroyer> maybe it isn't called 'Session' though…
20:00:11 <jamielennox> dtroyer: where does it  belong then?
20:00:23 <wchrisj> that's been my concern from the start
20:00:24 <jamielennox> it's very tied up there in keystoneclient because that's where auth lives
20:00:49 <dtroyer> at the level (yet to be named) that manages the auth and Session and what would be managers if we had them?
20:01:02 <wchrisj> I just think of most of this activity as transport related
20:01:11 <wchrisj> http layer
20:01:27 <wchrisj> session is the data that must be maintained for the user/consumer
20:01:33 <wchrisj> IMO
20:01:43 <wchrisj> unless I'm missing some context here
20:01:47 <bknudson> I think that would be the service catalog?
20:01:51 <bknudson> would include the
20:02:13 <bknudson> and the token
20:02:17 <briancurtin> now that we're over time and i have to head somewhere in a min, i'm outta here
20:02:19 <briancurtin> #endmeeting