19:00:30 #startmeeting python-openstacksdk 19:00:31 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:35 The meeting name has been set to 'python_openstacksdk' 19:01:18 if anyone's here for teh SDK meeting, which im guessing is just terrylhowe and i, say hi 19:01:28 o/ 19:01:36 (i think everett is back from vacation later this week) 19:02:50 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 For 0.6 the occ factory and dynamic plugins would be nice 19:03:38 it's a quick code change, but a bunch of tests broke 19:03:58 also, if we could include my plugin example as a repo in the big tent thing, that would be handy 19:05:01 https://github.com/TerryHowe/openstacksdk-plugin 19:05:16 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 obviously, it might need some changes if we change the plugin architecture, but I thought that was very cloe 19:06:01 well, the example is just for developers and I also wanted to use it for automated functional tests 19:06:46 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 yeah, we should eventually have something in stackforge or something 19:08:35 at least it shouldn’t be owned by me and it should be reviewed like any other OS project 19:09:58 those are details we could has Doug about though 19:12:12 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 sure 19:15:44 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 no idea Doug would know I guess 19:16:19 Tristan Cacqueray 19:16:33 i'll ping doug as well and see what he says and get that moving 19:17:51 dhellmann: around? 19:18:09 terrylhowe: here 19:18:49 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 enovance is part of redhat now 19:19:43 I think the infra team has docs on that 19:19:46 anteaya would know 19:19:56 o/ 19:20:00 what do I know? 19:20:12 docs for elecion? 19:20:34 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 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 start here: https://wiki.openstack.org/wiki/Election_Officiating_Guidelines 19:20:46 cool, thanks 19:20:47 anteaya: great, thanks 19:20:49 welcome 19:20:52 happy election 19:21:13 thanks 19:21:38 the other less important question dhellmann is how to bring in https://github.com/TerryHowe/openstacksdk-plugin as our sample plugin 19:21:52 Assuming we want a sample plugin 19:21:58 were you thinking as a new repo, or in the tree with the sdk? 19:22:08 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 a repo 19:22:18 oh god 19:22:18 what 19:22:23 http://docs.openstack.org/infra/manual/creators.html 19:22:35 briancurtin: if I don't have to use evote that's fine 19:22:40 sigmavirus24: PTL election (you don't have to do it, was sort of a joke) 19:22:42 hahahahahahhahahaha 19:22:51 Oh god 19:22:56 You reminded me I should resign 19:23:10 Before I have to run another election =P 19:23:49 thanks dhellmann that should work 19:25:24 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 er, liberty 19:25:31 the one at the end of kilo :-) 19:25:47 that saves us from having to run 2 elections back to back 19:26:48 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 yeh, sure 19:28:50 ok, i'll denote that in the file and get it pushed into gerrit 19:30:28 terrylhowe: i'll take a look at the reviews for dynamic and OCC. anything else we need short term? 19:31:30 https://review.openstack.org/#/c/197741/4/openstack/auth/service_filter.py 19:31:35 related to dyn load 19:32:02 we could also run one now and call it early -- I thought briancurtin was ptl :-) 19:32:48 jesse noller is technically 19:33:34 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 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 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 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 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 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 so that mesaging and message map to message or something like that 19:39:13 that or alternate service names 19:45:58 as in you would have Connection.message and Connection.messaging? 19:48:12 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 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 maybe we could add a list of aliases to service filter 19:52:41 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 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 do you have an example of that? is this a rax:messaging -> messaging thing or something else? 19:58:16 I was thinking maybe you’d create a service_type=messaging, aliases=[‘rax:message’, ‘rax:messaging’] 19:58:25 and we’d punt on the provider/vendor change 19:58:45 I meant to say service_type=message 19:58:51 no gerunds 19:59:01 terrylhowe: and where would this go? the alias thing is inside the SDK? 19:59:29 yes, we’d have to support aliases in the service filter 19:59:57 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 it wouldn’t 20:00:33 service filter would just need to be modified to have aliases 20:00:34 but who would enter that rax:message thing? is that included in the message classes within SDK/ 20:00:50 you would when you make your plugin 20:00:57 ah, ok 20:01:23 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 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 well, let’s get agreement on the dyn loading first, I think we were real close 20:02:23 yeah, that is close 20:02:39 k 20:02:43 #endmeeting