19:00:24 #startmeeting python-openstacksdk 19:00:25 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:29 The meeting name has been set to 'python_openstacksdk' 19:01:10 If you're here for the python-openstacksdk meeting, can you state your name and affiliation? 19:01:38 FYI i know alex isn't going to make it, i believe ed is on vacation the rest of the week 19:02:01 Brant Knudson -- IBm 19:02:06 Brian Curtin, Rackspace 19:02:12 Chris Johnson, HP 19:02:18 Dean Troyer, Nebula 19:02:32 Jamie Lennox, Red Hat 19:03:19 I think that'll probably be it 19:03:47 small one today 19:03:58 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 since Ed isn't here, perhaps we start with jamielennox 19:05:03 #topic https://review.openstack.org/#/c/86227/ Add base resource class 19:05:40 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 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 the mixing it with managers actually worked better than i anticipated though 19:06:43 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 sadly, no. 19:07:48 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 another client? 19:08:19 for kite? 19:08:34 bknudson: yes 19:08:45 jamielennox: just start with the openstack-sdk 19:09:06 jamielennox: what are some of these situations where it doesn't work? 19:09:21 partially it's about implementation there 19:09:35 but essentially there is not a base resource key 19:09:55 or more correctly there is a base resource key - but the resource is just a string 19:10:02 eg { 'key': 'abcdef' } 19:11:01 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 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 also there was the situation there where a lot of operations (like get) aren't supported by kite 19:12:28 a resource without a GET operation... weird. 19:12:32 bknudson: it was a way of keeping compatability if we need to go the client.users.list() approach 19:12:40 bknudson: key's are private - you can't retrieve them 19:13:07 bknudson: is HEAD supported? 19:13:19 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 +1 to dtroyer 19:13:37 bknudson: talking to yourself? - no it's not 19:13:48 dtroyer: i agree 19:14:36 without it it just means you have to pass a session object around a lot 19:14:47 there is probably some way we could abstract that at a higher level 19:16:15 but i don't see that as a problem for a basic version specific class 19:16:52 agreed 19:17:20 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 yeah, i think that's fine 19:20:27 jamielennox: what's an example of a resource, like identity.User ? 19:20:41 bknudson: yes 19:22:23 jamielennox: do you think some of the Resource API depends on how well OpenStack REST APIs conform to some convention? 19:22:42 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 jamielennox: ah, ignore me then 19:23:24 for example, it's got "resource_key" and "resources_key" -- but maybe there's no plural form of the key element. 19:23:47 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 bknudson: you can also override classmethods 19:24:59 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 dtroyer: yea, it would 19:25:40 i don't think any of those locations are doing anything funny 19:26:20 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 encapsulation FTW dtroyer 19:27:08 yep, now that i know urljoin is wrong, +1 to doing that 19:30:16 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 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 I don't think it is a blocker though 19:31:48 Do we have a consensus on the Manager class? 19:31:56 Is it staying or going? 19:32:34 if it only there for compat I think it can go 19:32:56 +1 dtroyer 19:33:04 i can remove it for now 19:33:10 i don't think we need it currenlty 19:33:44 sounds good 19:33:49 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 dtroyer: would you like to just remove list() for now as well 19:36:08 all we really need at this point is a consensus on the object vs manager approach 19:36:26 not yet, I want to think about how it should look though... 19:36:45 it would be nice if there was example client code 19:37:10 bknudson: right, i know the keystone stuff well enough to have a go at that 19:37:13 The sooner that I can fire up the client and at minimum just do a basic auth, the better 19:37:31 even if it's not the pluggable auth that is the end goal 19:38:09 bknudson: I've thought that too. I have some small scripts that I used for testing Session and discovery 19:38:31 should we have some samples in the repo at some point? 19:38:39 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 dtroyer: absolutely 19:39:14 yea, it will depend on how we adhere to that old proposal of having an object per request we make 19:39:19 briancurtin What did Alex's proposal specifically address? 19:39:22 not sure how to define "some point", but i'd really like that to be sooner than later 19:39:33 I'm always a fan of having as much of the documentation in the docstrings as we can 19:39:47 even sample code 19:41:20 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 briancurtin - I remember the proposal; dont remember the specific content 19:42:37 wchrisj: here's what it was: https://github.com/stackforge/python-openstacksdk/blob/956418f5d87156673a2daf3b67ed31b285e15690/api_strawman/client.py 19:43:58 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 briancurtin - Understood. My only issue is that code is pretty monolithic; would prefer OO approach... 19:44:56 oh, I thought this was sample client code. 19:45:22 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 bknudson: i guess i'll sit down with alex and see what he intends with it 19:45:28 bknudson - It is sample client code 19:45:30 to be shared between -sdk and other clients 19:45:43 i could have just misunderstood it 19:45:48 ok 19:46:05 new review upload without a manager and with a urljoin 19:46:18 https://review.openstack.org/#/c/86227/ 19:47:23 if everything could only be that fast… ;) 19:47:42 w00t 19:50:11 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 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 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 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 I think the Accept header should be handled in Session, enabled with an arg, and those methods can all go away 19:54:30 more than just the Resource object will want it 19:55:22 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 particularly i'm thinking service_type and service_version 19:55:57 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 sure, and that's where the headers arg comes in, but this Accept is pretty common 19:56:13 terrylhowe: ++ 19:56:41 dtroyer: i'm willing to put accept in as a special case 19:56:59 dtroyer: but service_type etc aren't headers and they will otherwise need to be set on every call 19:57:14 it matches the json handling that is already there. 19:57:53 service_type, etc get their own Resource subclass? or mixin or whatever? 19:58:52 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 s/the point/a point 19:59:47 there's no reason that can't continue, that doesn't belong in the low-level Session/request interface 20:00:02 maybe it isn't called 'Session' though… 20:00:11 dtroyer: where does it belong then? 20:00:23 that's been my concern from the start 20:00:24 it's very tied up there in keystoneclient because that's where auth lives 20:00:49 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 I just think of most of this activity as transport related 20:01:11 http layer 20:01:27 session is the data that must be maintained for the user/consumer 20:01:33 IMO 20:01:43 unless I'm missing some context here 20:01:47 I think that would be the service catalog? 20:01:51 would include the 20:02:13 and the token 20:02:17 now that we're over time and i have to head somewhere in a min, i'm outta here 20:02:19 #endmeeting