19:00:30 <briancurtin> #startmeeting python-openstacksdk
19:00:31 <openstack> Meeting started Tue Jul 21 19:00:30 2015 UTC and is due to finish in 60 minutes.  The chair is briancurtin. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:35 <openstack> The meeting name has been set to 'python_openstacksdk'
19:01:18 <briancurtin> if anyone's here for teh SDK meeting, which im guessing is just terrylhowe and i, say hi
19:01:28 <terrylhowe> o/
19:01:36 <briancurtin> (i think everett is back from vacation later this week)
19:02:50 <briancurtin> terrylhowe: all i really have is to just finalize that big tent thing and then see what we need reviews on in order to release. i still have to finish the implementation of that create-not-updating-attrs thing
19:03:32 <terrylhowe> For 0.6 the occ factory and dynamic plugins would be nice
19:03:38 <briancurtin> it's a quick code change, but a bunch of tests broke
19:03:58 <terrylhowe> also, if we could include my plugin example as a repo in the big tent thing, that would be handy
19:05:01 <terrylhowe> https://github.com/TerryHowe/openstacksdk-plugin
19:05:16 <briancurtin> terrylhowe: i can push a release of my rackspace plugin that works with the dynamic branch as well, i just had to update my entry points and it worked
19:05:24 <terrylhowe> obviously, it might need some changes if we change the plugin architecture, but I thought that was very cloe
19:06:01 <terrylhowe> well, the example is just for developers and I also wanted to use it for automated functional tests
19:06:46 <terrylhowe> but it should be an official thing if we do that. OSC was looking to do the same thing, bring in a plugin example
19:07:36 <briancurtin> yeah, we should eventually have something in stackforge or something
19:08:35 <terrylhowe> at least it shouldn’t be owned by me and it should be reviewed like any other OS project
19:09:58 <terrylhowe> those are details we could has Doug about though
19:12:12 <briancurtin> terrylhowe: back to the big tent piece though: for the PTL slot, i'm still interested, and are you interested in running for PTL for the time between now and the next election, which i think is november (last one was may)
19:12:43 <terrylhowe> sure
19:15:44 <briancurtin> terrylhowe: do you happen to know who we talk to about getting an election setup? the one name i know i've seen before is a guy named tristan from enovance (or whatever they became)
19:16:14 <terrylhowe> no idea Doug would know I guess
19:16:19 <briancurtin> Tristan Cacqueray
19:16:33 <briancurtin> i'll ping doug as well and see what he says and get that moving
19:17:51 <terrylhowe> dhellmann: around?
19:18:09 <dhellmann> terrylhowe: here
19:18:49 <briancurtin> dhellmann: we're about to apply for big tent and both terrylhowe and i are interested in being PTL. how should we proceed? election? if yes, how do we initiate said election?
19:18:52 <dhellmann> enovance is part of redhat now
19:19:43 <dhellmann> I think the infra team has docs on that
19:19:46 <dhellmann> anteaya would know
19:19:56 <anteaya> o/
19:20:00 <anteaya> what do I know?
19:20:12 <anteaya> docs for elecion?
19:20:34 <briancurtin> anteaya: setting up an election between terrylhowe and i for a PTL spot on a project (python-openstacksdk) applying for big tent
19:20:38 <dhellmann> anteaya: yeah, the sdk team would like to run an election as part of asking to be part of the big tent
19:20:38 <anteaya> start here: https://wiki.openstack.org/wiki/Election_Officiating_Guidelines
19:20:46 <briancurtin> cool, thanks
19:20:47 <dhellmann> anteaya: great, thanks
19:20:49 <anteaya> welcome
19:20:52 <anteaya> happy election
19:21:13 <terrylhowe> thanks
19:21:38 <terrylhowe> the other less important question dhellmann is how to bring in https://github.com/TerryHowe/openstacksdk-plugin as our sample plugin
19:21:52 <terrylhowe> Assuming we want a sample plugin
19:21:58 <dhellmann> were you thinking as a new repo, or in the tree with the sdk?
19:22:08 <briancurtin> terrylhowe: so we have to find an election administrator. i bet we can convince sigmavirus24 to do it (hi ian, expert election administrator)
19:22:11 <terrylhowe> a repo
19:22:18 <sigmavirus24> oh god
19:22:18 <sigmavirus24> what
19:22:23 <dhellmann> http://docs.openstack.org/infra/manual/creators.html
19:22:35 <sigmavirus24> briancurtin: if I don't have to use evote that's fine
19:22:40 <briancurtin> sigmavirus24: PTL election (you don't have to do it, was sort of a joke)
19:22:42 <briancurtin> hahahahahahhahahaha
19:22:51 <sigmavirus24> Oh god
19:22:56 <sigmavirus24> You reminded me I should resign
19:23:10 <sigmavirus24> Before I have to run another election =P
19:23:49 <terrylhowe> thanks dhellmann that should work
19:25:24 <dhellmann> briancurtin, terrylhowe : this close to what would be the normal election season, it may also be safe to just say we're going to hold one then -- I think we've approved one other project under similar circumstances right before the kilo summit
19:25:27 <dhellmann> er, liberty
19:25:31 <dhellmann> the one at the end of kilo :-)
19:25:47 <dhellmann> that saves us from having to run 2 elections back to back
19:26:48 <briancurtin> i guess that works too...we've been officially PTL-less since the start, and if that works with the people reviewing big tent stuff, terrylhowe should we just keep going as-is and figure it out during the big election?
19:27:54 <terrylhowe> yeh, sure
19:28:50 <briancurtin> ok, i'll denote that in the file and get it pushed into gerrit
19:30:28 <briancurtin> terrylhowe: i'll take a look at the reviews for dynamic and OCC. anything else we need short term?
19:31:30 <terrylhowe> https://review.openstack.org/#/c/197741/4/openstack/auth/service_filter.py
19:31:35 <terrylhowe> related to dyn load
19:32:02 <dhellmann> we could also run one now and call it early -- I thought briancurtin was ptl :-)
19:32:48 <terrylhowe> jesse noller is technically
19:33:34 <briancurtin> he created it but i dont think anyone technically ever became PTL, or at least i dont think we ever voted on anything
19:34:45 <briancurtin> terrylhowe: +1 on the provider name (from vendor). i think that colon piece is fine - it looks ok, and we have a few services that use it, but i think i looked into a different way to solve their names (but it was hacky)
19:36:11 <terrylhowe> the only reason for it really is to remove the awkward : out of the name.  It doesn’t make much sense when you are using a connection I don’t think
19:36:54 <briancurtin> terrylhowe: is this something that should be handled within a plugin, though? that's where i looked at solving it for our implementation of messaging, it's like rax:messaging or rax:message
19:37:35 <briancurtin> so when i created my ServiceFilter subclass for MessagingService (or howeer its named), i had some dance to get that to find the right entry in the service catalog
19:38:40 <terrylhowe> well, either way, I think we should strip off the provider/vendor part, but maybe there is something else as well where the service has some attribute how it wants to be idenfied as an attribute in connection
19:39:05 <terrylhowe> so that mesaging and message map to message or something like that
19:39:13 <terrylhowe> that or alternate service names
19:45:58 <briancurtin> as in you would have Connection.message and Connection.messaging?
19:48:12 <terrylhowe> well, if they are the same service, I’d hope they’d both map to Connection.message if that was the desired name
19:48:48 <briancurtin> either way, -2 on offering the same thing in multiple namespaces. i think we can solve this through configuration, but it should never affect how you'd write code
19:51:41 <terrylhowe> maybe we could add a list of aliases to service filter
19:52:41 <briancurtin> i guess i'd have to see how it works. it seems like providers doing their own thing with names is something the provider's plugin should probably handle
19:56:28 <terrylhowe> the whole alias thing might be more flexible, but I’d almost want to let users map some arbitrary service_type to a service we know about
19:57:21 <briancurtin> do you have an example of that? is this a rax:messaging -> messaging thing or something else?
19:58:16 <terrylhowe> I was thinking maybe you’d create a service_type=messaging, aliases=[‘rax:message’, ‘rax:messaging’]
19:58:25 <terrylhowe> and we’d punt on the provider/vendor change
19:58:45 <terrylhowe> I meant to say service_type=message
19:58:51 <terrylhowe> no gerunds
19:59:01 <briancurtin> terrylhowe: and where would this go? the alias thing is inside the SDK?
19:59:29 <terrylhowe> yes, we’d have to support aliases in the service filter
19:59:57 <briancurtin> i'd rather the SDK not even now rackspace exists. i think it can enable rackspace's existence, but it shouldnt solve our problems for us
20:00:05 <terrylhowe> it wouldn’t
20:00:33 <terrylhowe> service filter would just need to be modified to have aliases
20:00:34 <briancurtin> but who would enter that rax:message thing? is that included in the message classes within SDK/
20:00:50 <terrylhowe> you would when you make your plugin
20:00:57 <briancurtin> ah, ok
20:01:23 <briancurtin> maybe this could work, i still need to see it, i guess. too many things around names on my mind in this area
20:02:13 <briancurtin> anyway, we're at the end of time and i have to head out of here. i'll try to look at reviews later today or tomorrow morning. i dont know that i'll have a lot of time to work on the create bug you entered until later in the week again
20:02:16 <terrylhowe> well, let’s get agreement on the dyn loading first, I think we were real close
20:02:23 <briancurtin> yeah, that is close
20:02:39 <terrylhowe> k
20:02:43 <briancurtin> #endmeeting