19:01:08 <briancurtin> #startmeeting python-openstacksdk
19:01:09 <openstack> Meeting started Tue Jul 28 19:01:08 2015 UTC and is due to finish in 60 minutes.  The chair is briancurtin. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:12 <openstack> The meeting name has been set to 'python_openstacksdk'
19:02:40 <etoews> o/
19:02:42 <briancurtin> if you're around for the meeting, which i dont think anyone currently is until terry arrives late, say hi. not much to talk about right now anyway
19:02:44 <briancurtin> oh hello
19:02:54 * etoews here today, gone tomorrow
19:04:03 <briancurtin> the only thing i have on the list until we're ready for a release is https://review.openstack.org/#/c/197741/ and https://review.openstack.org/#/c/191535/ (the latter of which i just +2'ed)
19:04:16 <stevelle> hui
19:05:53 <etoews> on the latter, apparently it has some impact on https://review.openstack.org/#/c/199318/
19:06:32 <etoews> in the BaseFunctionalTest
19:06:36 <briancurtin> i cant imagine how those are in any way related, but ok
19:06:45 <briancurtin> oh
19:08:53 <etoews> i suspect the occ config thing won't help me at all
19:09:37 <etoews> oh wait...maybe.
19:10:42 <etoews> once it merges, i'll rebase...after i get back from vacation.
19:11:11 <briancurtin> on 197741 i'm still not sure if we should be solving that problem within the SDK. providers using a provider-specific naming scheme seems like a thing to solve within a plugin, but terry hinted that that's true and this may still help, but i guess i dont totally get it then
19:11:55 <briancurtin> since rackspace has a few of these "rax:<something>" entries, i think we should handle that in our plugin. i dont want anyone to be exposed to "rax" anywhere
19:14:12 <etoews> seems like a path to vendor madness
19:20:49 <briancurtin> id prefer to just enable providers to load something, but not take it any further. us or anyone else using weird names or doing different things should just be handled outside of the sdk. if we need to subclass ServiceFilter and implement that on our own, that's probably what i'd do
19:21:18 <briancurtin> and it's really only a problem taht needs to be solved for rackspace and HP plugins. nothing within upstream openstack appears to need this
19:22:58 <terrylhowe> o/
19:23:17 <briancurtin> terrylhowe: the only thing i have on the list until we're ready for a release is https://review.openstack.org/#/c/197741/ and https://review.openstack.org/#/c/191535/ (the latter of which i just +2'ed)
19:24:07 <briancurtin> terrylhowe: we were just getting into talking about 197741, and im not sure we should be dealing with that within the SDK. only HP and rackspace have things named like that, so i think that's somethign we should be handling entirely within our plugins
19:24:28 <terrylhowe> maybe we should skip 197741 and go with a service type alias thing
19:24:44 <terrylhowe> I was working on aliases on my flight today
19:24:57 <briancurtin> terrylhowe: do we need this service alias thing for a release?
19:25:25 <terrylhowe> well, we’ll need something for the various plugins but not really for a release
19:26:28 <etoews> it is possible that private openstack clouds can change their service name/type in keystone.
19:26:45 <terrylhowe> yes
19:26:51 <etoews> why would they do that instead of the "devstack" default? who knows.
19:26:53 <briancurtin> terrylhowe: i think we should go on with a release then if 191535 checks out. right now just about every service will work fine as-is. a few with the colon just won't and we can get it in the next release
19:27:28 <terrylhowe> sounds good, 191535 is important for the OSC POC
19:27:44 <terrylhowe> the service type alias thing is not so important for that
19:29:33 <briancurtin> etoews: will you have time to take a look at https://review.openstack.org/#/c/191535/?
19:30:21 <etoews> sure
19:33:38 <etoews> fyi, the service type/name could change as a result of https://review.openstack.org/#/c/181393/5/specs/service-catalog.rst
19:37:25 <briancurtin> etoews: what's the timeframe on something like that being implemented?
19:37:57 <etoews> ¯\_(ツ)_/¯
19:38:08 <etoews> let's see if we can find annegentle
19:38:59 <etoews> the ping is out
19:39:49 * sigmavirus24 lurks
19:40:45 * briancurtin plays with new hockey stick while waiting
19:42:09 <etoews> hello annegentle
19:42:12 <annegentle> hey etoews
19:42:39 <etoews> so the service type/name could possible change as a result of https://review.openstack.org/#/c/181393/5/specs/service-catalog.rst correct?
19:43:33 <annegentle> So there's also the name changes for consistency in https://review.openstack.org/#/c/201160/
19:43:48 <annegentle> and the one that depends on that one, https://review.openstack.org/#/c/201670/
19:44:01 <annegentle> and I still need an assignee for writing a test for names
19:44:56 <annegentle> I talked about it at a cross project meeting about 2 weeks ago
19:45:11 <annegentle> seems generally appreciated
19:45:44 <annegentle> any questions about it? Still under discussion
19:47:15 <etoews> we really just need to know if we should provide some flexibility within the sdk to handle different service name/type
19:47:54 <etoews> to answer briancurtin and considering those are all spec
19:47:57 <etoews> doh
19:48:02 <annegentle> ah okay. I think so.
19:48:11 <annegentle> For example, check out this one https://review.openstack.org/#/c/206198/
19:48:28 <etoews> to answer briancurtin's question, considering those are all specs, it's anybody's guess when they'll be implemented.
19:48:32 <annegentle> Barbican's change from Key management service to Key manager service for example
19:48:53 <annegentle> Weird, I don't see any question from Brian. Anywho. The idea is that the names could then be used when reviewing.
19:49:02 <annegentle> But yes, it's fallable.
19:49:23 * redrobot lurks
19:49:56 <annegentle> The JSON Schema in line 154 could offer some testing against a known list.
19:49:57 <briancurtin> etoews: so...should we care about unimplemented specs?
19:50:17 <briancurtin> at least in terms of implementing code against them within the SDK
19:50:44 <briancurtin> seems like jumping too far ahead and being *too* flexible until we know we need to be
19:50:47 <annegentle> briancurtin: it's a fair question. What do you want the world to look like?
19:51:18 <briancurtin> i dont have time to care about the entire ecosystem. i just need to write code that works in real life and lets people build stuff.
19:52:02 <annegentle> briancurtin: then yeah, I would focus on now
19:52:22 <etoews> briancurtin: i know what you mean. i think we don't need to as long as we don't design ourselves into a corner. meaning if we did need to add code later that handle differing service name/type in the sdk that it wouldn't affect the public interface of the sdk.
19:52:57 <etoews> does that make sense?
19:53:03 <briancurtin> yep
19:53:38 <annegentle> I sound a little too philosophical :)
19:53:48 <etoews> :)
19:54:02 <etoews> ohmmmmmmm
19:56:28 <briancurtin> anything in these last few minutes to cover?
19:56:53 <etoews> i'm off on vacation. back aug. 10.
19:56:59 <annegentle> lucky!
19:57:01 <annegentle> :)
19:57:11 <etoews> \o/
19:57:26 <terrylhowe> etoews: you just got back!
19:57:34 <etoews> i know. :)
19:58:46 <terrylhowe> just a little envy here
19:59:36 <etoews> i had a bunch saved up. gotta spend it sometime.
20:01:01 <briancurtin> #endmeeting