19:00:58 #startmeeting python-openstacksdk 19:00:59 Meeting started Tue Jun 17 19:00:58 2014 UTC and is due to finish in 60 minutes. The chair is briancurtin. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:00 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:02 The meeting name has been set to 'python_openstacksdk' 19:02:08 anyone here for the SDK meeting? 19:02:15 Brian Curtin, Rackspace 19:02:21 Terry Howe, HP 19:02:56 Alex Gaynor, Rackspace 19:03:04 Dean Troyer, Nebula 19:03:42 Jamie Lennox, Red Hat 19:03:57 let's get started 19:04:09 #topic the "openstack.*" namespace 19:04:36 there was a little talk about this last week, and terrylhowe mentioned to me some thoughts dtroyer_zz had, and i agree... 19:05:06 i dont know that we can squat on the openstack.* namespace without potentially hurting ourselves with server-side adoption 19:05:10 Ed Leafe, Rackspace (late as usual!) 19:05:11 (and potentially other things) 19:05:48 oh i guess i should send the agenda, sorry: https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK#Agenda_for_2014-06-17_1900_UTC 19:07:02 dtroyer_zz brought up the situation where, e.g., if Heat wants to eventually move from python-glanceclient to our (currently named) openstack.image, can they do that? can every service like that do it? 19:07:26 I don't think anything else uses a toplevel openstack namespace right now? 19:07:47 i think they can 19:07:54 Does oslo? 19:07:59 i'm not aware of anything it would conflict with 19:08:06 openstack.common is used by oslo-incubator 19:08:08 Alex_Gaynor: no 19:08:23 dtroyer_zz: but that's always in the directory.... oh 19:08:34 I don't know of any existing conflicts, but I think we should be mindful of not assuming we have the whole thing to ourselves 19:08:36 Wouldn't the worse case scenario be they do something like `import openstack as ossdk`? 19:08:44 hmmm 19:09:05 -infinity to building an entire project and then telling people to import it as something else 19:09:10 no the case would be having openstack from oslo in your projects root and that overriding import openstack 19:09:29 you would need __futures__ everywhere? 19:10:07 i like the idea of having openstack.*, but i think dtroyer_zz is right that we probably can't assume it's ours just because most/all don't use it...unless it got some official blessing, which we're nowhere near 19:11:16 it just easier to fix now than in a month or three…but if we don't care then we should write that down, and why, so we don't re-visit it as new people come along... 19:11:16 Who would be the arbiters of if we can / should use taht namespace? 19:12:04 Alex_Gaynor: the TC is the only central jurisdiction like that, and they may not want to care…pragmatically it's first-come 19:12:19 until someone with a bigger stick wants your space 19:13:04 Unless folks think oslo-inccubator has a strong claim to the name; I think we should just roll with it. dhellmann can you weigh in? 19:13:14 I say we stick with it 19:14:03 i would like to stick with it, or at least stick with it for right now. if we need to come back to it before this goes big-time and make it openstack.sdk.foo, it's not the end of the world 19:14:28 something to think about, for sure 19:14:41 ok, now that it's logged, we can point to it the next time someone asks ;) 19:15:29 is it worth raising the question of the openstack namespace on openstack-dev? 19:17:05 No clue, that list is soooo high traffic :-) 19:17:30 ehh, i'll think about it, or come back to it after we've stewed on it for a bit 19:17:46 #topic https://review.openstack.org/#/c/99456/ - Important changes for service filtering 19:18:04 I was hoping jamielennox could take a look at that 19:18:38 It is all about combining what service the resource wants with what service the user wants 19:19:43 terrylhowe: hmm - this was the advantage to just using a dictionary and kwargs 19:19:52 join and setdefault are easy 19:20:52 Personally I try to avoid dicts with specific sets of keys, it makes documenting them difficult 19:21:22 why are you putting it into the Session? 19:21:52 so the session can get the right endpoint 19:22:37 oh, ok you're essentially doing the adapters part 19:22:38 those are the user preferences, most likely just region and service_name 19:23:41 https://review.openstack.org/#/c/86237/4 is how i was going to do it for the existing clients 19:23:52 though it's possibly not appropriate here 19:24:07 s/possibly/probably 19:25:45 that would add a whole new layer 19:26:34 yea, it's kind of necessary when you have multiple clients sharing the session, here because it's just us we can probably squash them 19:29:11 ok - so the main thing is you don't appear to deal with region_name in join(), and do we get weird situations when people supply a service_name to the session 19:29:22 just saw Alex_Gaynor's comment - good point 19:30:24 well, the join is to user preferences, so it uses the users region and service_name 19:30:28 oh - join overrides, something feels a little off there, but ok 19:30:52 I didn’t want to alter the current filter. 19:31:03 it means though that you can't say visibility=ADMIN on the preference 19:31:05 yeh, the thing works, I’m not thrilled with it either to be honest 19:31:07 for example 19:32:11 terrylhowe: i agree with Alex_Gaynor, and we can come back and fix this - but mark it as a FIXME or something to address later 19:32:13 I though the resource would dictate visibility 19:32:48 terrylhowe:well ADMIN is a bad example, but INTERNAL might be something you would set globally 19:33:10 okay 19:33:52 in the interests of covering the other stuff, moving on 19:33:52 well, at least it is contained in this class 19:34:00 sounds good 19:34:15 (sorry to cut you off, just want to make sure we get through) 19:34:25 #topic https://review.openstack.org/#/c/99458/ - json default for transport and resource __repr__ 19:35:05 This looks pretty straightforward to me 19:35:14 i +2'ed this, seems fine, and was approved by dean at some point 19:36:27 +A 19:36:42 Terry and I talked about it yesterday, I hadn't gotten back to the queue yet... 19:36:56 awesome 19:37:12 #topic https://review.openstack.org/#/c/99463/ - Very basic image resource 19:37:22 Let the bikeshedding begin! 19:39:48 Alex_Gaynor: we haven't been doing that yet? 19:40:01 tehe :-) 19:40:12 This looks mostly pretty reasonable to me, but I want to spend some more time wiht it 19:40:38 briancurtin: you said you were wokring on a swift resource right? I think that's probably useful since they work pretty differently, and it'd be good to make sure we don't box ourselves into a corner 19:41:21 Alex_Gaynor: i did say that, but time with my fingers on a keyboard was very little in the last week...i'm working on it in spirit, should be able to actually do stuff now that i'm back in town 19:41:46 terrylhowe: it looks pretty good to me 19:42:06 https://review.openstack.org/#/c/99463/4/examples/list.py 19:42:12 is really the only odd part about it 19:42:36 it is very convenient though passing in a string to import the resource 19:46:22 It seems like maybe we all need a bit more time to process this one, shall we move on? 19:47:55 i agree. i dont think we're far off, but maybe a few more looks, really. anything else at the moment? 19:48:29 Does anyone object to me adding us to projects.txt so that our requirements will be sync'd with global-requirements? 19:49:04 is there a downside to that? 19:49:14 We can't depend on any libraries not listed there 19:49:49 add it 19:49:51 without having looked, is that something we can do right now with no changes? 19:50:10 it's a CR we send to the requirements repo 19:50:42 sounds good to me 19:51:19 go for it then 19:51:22 ++ 19:52:37 Will do 19:52:51 #topic https://review.openstack.org/#/c/99477/ - Make the session command a little more friendly 19:53:01 this one is easy 19:53:19 it looks like it needs a rebase? 19:53:48 rebased 19:55:45 after that, anything else in the last 5 min? 19:55:55 (or is there any discussion on that one?) 19:58:41 Looks like no, cheers! 19:59:15 thanks everyone 19:59:22 thanks all 19:59:32 #endmeeting