19:00:58 <briancurtin> #startmeeting python-openstacksdk
19:00:59 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:02 <openstack> The meeting name has been set to 'python_openstacksdk'
19:02:08 <briancurtin> anyone here for the SDK meeting?
19:02:15 <briancurtin> Brian Curtin, Rackspace
19:02:21 <terrylhowe> Terry Howe, HP
19:02:56 <Alex_Gaynor> Alex Gaynor, Rackspace
19:03:04 <dtroyer_zz> Dean Troyer, Nebula
19:03:42 <jamielennox> Jamie Lennox, Red Hat
19:03:57 <briancurtin> let's get started
19:04:09 <briancurtin> #topic the "openstack.*" namespace
19:04:36 <briancurtin> 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 <briancurtin> i dont know that we can squat on the openstack.* namespace without potentially hurting ourselves with server-side adoption
19:05:10 <edleafe> Ed Leafe, Rackspace (late as usual!)
19:05:11 <briancurtin> (and potentially other things)
19:05:48 <briancurtin> 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 <briancurtin> 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 <Alex_Gaynor> I don't think anything else uses a toplevel openstack namespace right now?
19:07:47 <jamielennox> i think they can
19:07:54 <Alex_Gaynor> Does oslo?
19:07:59 <jamielennox> i'm not aware of anything it would conflict with
19:08:06 <dtroyer_zz> openstack.common is used by oslo-incubator
19:08:08 <jamielennox> Alex_Gaynor: no
19:08:23 <jamielennox> dtroyer_zz: but that's always in the directory.... oh
19:08:34 <dtroyer_zz> 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 <edleafe> Wouldn't the worse case scenario be they do something like `import openstack as ossdk`?
19:08:44 <jamielennox> hmmm
19:09:05 <briancurtin> -infinity to building an entire project and then telling people to import it as something else
19:09:10 <jamielennox> no the case would be having openstack from oslo in your projects root and that overriding import openstack
19:09:29 <jamielennox> you would need __futures__ everywhere?
19:10:07 <briancurtin> 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 <dtroyer_zz> 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 <Alex_Gaynor> Who would be the arbiters of if we can / should use taht namespace?
19:12:04 <dtroyer_zz> 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 <dtroyer_zz> until someone with a bigger stick wants your space
19:13:04 <Alex_Gaynor> 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 <jamielennox> I say we stick with it
19:14:03 <briancurtin> 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 <briancurtin> something to think about, for sure
19:14:41 <dtroyer_zz> ok, now that it's logged, we can point to it the next time someone asks  ;)
19:15:29 <briancurtin> is it worth raising the question of the openstack namespace on openstack-dev?
19:17:05 <Alex_Gaynor> No clue, that list is soooo high traffic :-)
19:17:30 <briancurtin> ehh, i'll think about it, or come back to it after we've stewed on it for a bit
19:17:46 <briancurtin> #topic https://review.openstack.org/#/c/99456/ - Important changes for service filtering
19:18:04 <terrylhowe> I was hoping jamielennox could take a look at that
19:18:38 <terrylhowe> It is all about combining what service the resource wants with what service the user wants
19:19:43 <jamielennox> terrylhowe: hmm - this was the advantage to just using a dictionary and kwargs
19:19:52 <jamielennox> join and setdefault are easy
19:20:52 <Alex_Gaynor> Personally I try to avoid dicts with specific sets of keys, it makes documenting them difficult
19:21:22 <jamielennox> why are you putting it into the Session?
19:21:52 <terrylhowe> so the session can get the right endpoint
19:22:37 <jamielennox> oh, ok you're essentially doing the adapters part
19:22:38 <terrylhowe> those are the user preferences, most likely just region and service_name
19:23:41 <jamielennox> https://review.openstack.org/#/c/86237/4 is how i was going to do it for the existing clients
19:23:52 <jamielennox> though it's possibly not appropriate here
19:24:07 <jamielennox> s/possibly/probably
19:25:45 <terrylhowe> that would add a whole new layer
19:26:34 <jamielennox> 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 <jamielennox> 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 <briancurtin> just saw Alex_Gaynor's comment - good point
19:30:24 <terrylhowe> well, the join is to user preferences, so it uses the users region and service_name
19:30:28 <jamielennox> oh - join overrides, something feels a little off there, but ok
19:30:52 <terrylhowe> I didn’t want to alter the current filter.
19:31:03 <jamielennox> it means though that you can't say visibility=ADMIN on the preference
19:31:05 <terrylhowe> yeh, the thing works, I’m not thrilled with it either to be honest
19:31:07 <jamielennox> for example
19:32:11 <jamielennox> 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 <terrylhowe> I though the resource would dictate visibility
19:32:48 <jamielennox> terrylhowe:well ADMIN is a bad example, but INTERNAL might be something you would set globally
19:33:10 <terrylhowe> okay
19:33:52 <briancurtin> in the interests of covering the other stuff, moving on
19:33:52 <terrylhowe> well, at least it is contained in this class
19:34:00 <terrylhowe> sounds good
19:34:15 <briancurtin> (sorry to cut you off, just want to make sure we get through)
19:34:25 <briancurtin> #topic https://review.openstack.org/#/c/99458/ - json default for transport and resource __repr__
19:35:05 <Alex_Gaynor> This looks pretty straightforward to me
19:35:14 <briancurtin> i +2'ed this, seems fine, and was approved by dean at some point
19:36:27 <dtroyer_zz> +A
19:36:42 <dtroyer_zz> Terry and I talked about it yesterday, I hadn't gotten back to the queue yet...
19:36:56 <briancurtin> awesome
19:37:12 <briancurtin> #topic https://review.openstack.org/#/c/99463/ - Very basic image resource
19:37:22 <Alex_Gaynor> Let the bikeshedding begin!
19:39:48 <jamielennox> Alex_Gaynor: we haven't been doing that yet?
19:40:01 <Alex_Gaynor> tehe :-)
19:40:12 <Alex_Gaynor> This looks mostly pretty reasonable to me, but I want to spend some more time wiht it
19:40:38 <Alex_Gaynor> 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 <briancurtin> 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 <jamielennox> terrylhowe: it looks pretty good to me
19:42:06 <terrylhowe> https://review.openstack.org/#/c/99463/4/examples/list.py
19:42:12 <terrylhowe> is really the only odd part about it
19:42:36 <terrylhowe> it is very convenient though passing in a string to import the resource
19:46:22 <Alex_Gaynor> It seems like maybe we all need a bit more time to process this one, shall we move on?
19:47:55 <briancurtin> i agree. i dont think we're far off, but maybe a few more looks, really. anything else at the moment?
19:48:29 <Alex_Gaynor> Does anyone object to me adding us to projects.txt so that our requirements will be sync'd with global-requirements?
19:49:04 <briancurtin> is there a downside to that?
19:49:14 <Alex_Gaynor> We can't depend on any libraries not listed there
19:49:49 <jamielennox> add it
19:49:51 <briancurtin> without having looked, is that something we can do right now with no changes?
19:50:10 <Alex_Gaynor> it's a CR we send to the requirements repo
19:50:42 <terrylhowe> sounds good to me
19:51:19 <briancurtin> go for it then
19:51:22 <dtroyer_zz> ++
19:52:37 <Alex_Gaynor> Will do
19:52:51 <briancurtin> #topic https://review.openstack.org/#/c/99477/ - Make the session command a little more friendly
19:53:01 <briancurtin> this one is easy
19:53:19 <Alex_Gaynor> it looks like it needs a rebase?
19:53:48 <terrylhowe> rebased
19:55:45 <briancurtin> after that, anything else in the last 5 min?
19:55:55 <briancurtin> (or is there any discussion on that one?)
19:58:41 <Alex_Gaynor> Looks like no, cheers!
19:59:15 <jamielennox> thanks everyone
19:59:22 <briancurtin> thanks all
19:59:32 <briancurtin> #endmeeting