20:03:22 #startmeeting trove 20:03:22 cool 20:03:22 Meeting started Wed Sep 25 20:03:22 2013 UTC and is due to finish in 60 minutes. The chair is grapex. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:03:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:03:25 The meeting name has been set to 'trove' 20:03:27 thanks grapex 20:03:31 7o7 20:03:36 #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting 20:03:48 o/ 20:04:02 #link http://eavesdrop.openstack.org/meetings/trove/2013/trove.2013-09-18-20.01.html 20:04:14 #topic Update to Action items 20:04:26 First one is mine. 20:04:40 1. SlickNik to check with hub_cap to make sure all contributors can create/edit blueprints. 20:04:55 I checked with hub_cap, and he is aware. 20:05:17 We need to sync with other teams to find out how they do the permissions on LaunchPad. 20:05:17 tap tap tap... is this thing on 20:05:20 hi guys 20:05:27 oya we didnt do that SlickNik :D 20:05:29 hey 20:05:34 yeah, still WIP 20:05:46 reaction it 20:05:48 hey, im not sure how long its taking for my stuffs to reach you.... im on a slow connection 20:05:58 hub_cap: fail 20:06:00 im gonna go directly to my proxy server 20:06:05 are you traveling again 20:06:26 somewhere in berkeley there is a train with carrier pigeons streaming out of the back trying to carry irc packets 20:06:31 #action SlickNik, hub_cap to check with other teams to set groups permissions correctly on LaunchPad 20:06:59 ok im on irssi now 20:07:04 should be good to go 20:07:24 Move on to ML or die? 20:07:27 yes fail imsplitbit, im at UC berkeley career fair tethered to my phone.. 500+ kids w/ att iphones 20:07:43 ML OR DIE 20:07:45 #topic ML or die 20:07:47 yes, grapex move on 20:07:48 thx 20:07:52 ok thats me 20:08:04 sooooooo 20:08:07 so what things should we send through the ML? 20:08:12 ive had a ton of private conversations w/ people 20:08:14 can we reply-all instead of irc? 20:08:25 for instance, weve talked a lot of service types 20:08:38 hub_cap: Service types seems perfect for the mailing list 20:08:41 and amcrn and i have been talking a lot about how itll work 20:08:44 yes i agree 20:08:45 altough about clustering API 20:08:53 yes clustering is perfect for the ML 20:08:57 and clustering itself 20:09:01 basically use this as a rule of thumb 20:09:11 if you want people to talk about if for more than 1 hr 20:09:13 send it ot the mailing list 20:09:15 just tag it as [trove] in the subject of course 20:09:19 ie, api design discussions 20:09:24 yes datsun180b good point to note 20:09:40 is the tag case sensitive? 20:09:46 [TrOvE]? 20:09:49 i get a lot of private emails, and i will send them to the ML 20:09:53 kevinconway: would advise sticking to all lowercase 20:09:56 kevinconway: if you are jorgewiliams you can do that 20:10:03 grapex: knows what im talking about 20:10:13 hub_cap: lol 20:10:24 I wonder if there's a good catalyst here? Seems like has come up before. :) 20:10:24 not terribly case sensitive, but trove looks cleaner than say Trove or TrOvE 20:10:29 or TROVE 20:10:36 i like TROVE 20:10:40 it matches HEAT 20:10:51 ill do my best to reply to people and ask them to push convo to the mailing list 20:10:58 sounds good 20:11:06 hub_cap: Cool 20:11:07 lol kevinconway nice nod to the heat is not a acronym 20:11:10 openstack-dev 20:11:15 yes 20:11:25 lets start discussing in the public... we have good points to make 20:11:30 and design especially 20:11:40 are there topics that should start in ML rather than IRC? 20:11:41 if we didnt cover it in a summit, lets hash it out together 20:12:02 kevinconway: i think its fair to say if youre writing a email, send it to the list 20:12:11 but you can always say things in irc and we can say 20:12:20 hey, this seems like we shoudl get input from people who arent around right now 20:12:26 and send out thoughts to the ML 20:12:27 gotcha 20:12:30 my rule of thumb 20:12:37 if you think it cant be solved in ~1 hr 20:12:46 Yea, thre have been several discussions in the past few weeks like that.. that i've missed 20:12:51 yes me too vipul 20:13:00 #agree 20:13:00 and the more i travel lol the less i see :) 20:13:05 It also is easier to start a thread of communication on the ML than on the wiki 20:13:17 or gists 20:13:20 ya wiki is terible for conversation 20:13:27 cp16net: agreed 20:13:28 gists are great to add in to a ML 20:13:30 yeah, i'm really not liking the gists thing 20:13:32 true 20:13:41 cuz u can fork them and say "this is what im thinking" 20:13:43 none of them fit in the text box and i have to raw view them 20:13:49 but lets not use them as _the_ method of comm 20:13:55 show examples there so to speak 20:14:07 yea code 20:14:11 weve been saying this for a long time "we need to use the ML more" 20:14:17 now that its not rax and hp 20:14:19 its time 20:14:22 let's finally do it? 20:14:25 :) 20:14:35 yes vipul and i have probably had this conversation 20+ times 20:14:37 what about the 'die part' 20:14:44 its like vote ore die 20:14:51 if you dont use the ML puffy will come to your house and scream at you 20:14:52 :) 20:15:04 heh 20:15:05 Do I need to add an action that if people don't use the ML there will be... consequences? 20:15:05 or p diddy or whatever his name is 20:15:18 "dire consequences" ;) jk 20:15:22 Ok, ready to move on? 20:15:23 actually there are consequences 20:15:27 one more point 20:15:41 the consequences of "you will have to re-explain this 900 times" 20:15:42 The consequences is we never settle the debate. 20:15:43 to 900 different people 20:15:47 hub_cap: That too 20:15:47 yup grapex 20:15:52 that's a horrible consequence. 20:15:53 same vain really.. 20:16:05 everyone will say something else and itll be hard to settle things 20:16:21 so hip hip horray for the ML! 20:16:38 make a smart inbox for [trove]|[TrOvE] 20:16:52 cuz u know kevinconway si gonna do that ;) 20:16:57 would we create an ouroboros by declaring on the ML that we're supposed to be using the ML 20:17:02 * cp16net starts typing email to the list.... 20:17:05 datsun180b: That's perfect 20:17:15 yes cp16net's config stuff is also great for the ML 20:17:22 yup 20:17:28 lol @ datsun180b's comment 20:17:41 ok horse beat 20:17:44 to death 20:17:47 Alright 20:17:49 #topic voting out of band 20:18:11 hub_cap: Is this about your recent experiment? 20:18:23 yes it is 20:18:28 how do yall think it went? its kinda odd 20:18:32 weird 20:18:38 hub_cap: what's this topic about ?? 20:18:41 but it was suggested by -infra guys 20:18:50 yeah but it worked out 20:18:55 we recently voted to log the channel communication dmakogon_ 20:18:55 I think it was okay. 20:18:56 and its on record now 20:19:01 by pushing a review to gerrit 20:19:03 aaa 20:19:06 and then +1'ing it 20:19:08 i dont understand why the doc had to be merged in tho... 20:19:16 cp16net: formal record 20:19:27 we can go back and see the vote 20:19:35 i could see it clutter commit history 20:19:37 gerrit holds that shiz forever 20:19:42 if we do this often that is 20:19:44 yes vipul it would if we do it a ton 20:19:47 only issue is git logs show voting stuff now. 20:19:57 #link https://github.com/openstack/trove/commit/15b706e2e0c37c2fa18e10c140d876c54c65fef4 20:20:00 im ok w that 20:20:04 git is a history 20:20:09 there shouldnt be a reason to do something like that out of band REALLY tho... 20:20:11 its up to us to fill in what that history is 20:20:34 do we have by-laws that describe if and when we can call for a revote on a topic? 20:20:41 nope 20:20:43 and is it pure majority or some other rule? 20:20:44 its very grey 20:20:52 its what we want as a community (trove) 20:20:55 Can we have the formal records in the trove-integration repo? 20:21:11 SlickNik: assuming trove-integration stays around forever, yes ;) 20:21:21 SlickNik: Good idea 20:21:22 that's what i was going to bring up, that repo's longevity 20:21:23 we are teh only project that requires a "extra" noncode repo 20:21:37 but lets not get into that now :D 20:21:46 i think for doc related stuff we can use database-api 20:21:47 and honestly 20:21:49 I know the infra team uses it but I bet at some point someone will join the project and object to having a ton of text files int he votes directory. 20:21:52 some of this will be solved w the ML 20:21:54 so can anyone call a vote for trove? 20:22:04 grapex: they dont really... it was a experiment 20:22:07 how do we make sure everyone gets a chance to vote? ML? 20:22:07 kevinconway: sure why not 20:22:18 but remember this is for something specific that is not needed to be voted on in a meeting 20:22:23 or something the ML cant solve 20:22:39 so what about spec/designs? 20:22:46 spec/design i think is ML 20:22:53 unless we have a total split and it dies on the ML 20:22:57 then its kinda up to core to decide 20:23:08 right, i meant as more of a feedback type system 20:23:15 sure i thin kthats faire 20:23:17 *Fair 20:23:28 but again, voiceing on the ML will help this 20:23:34 especialy if we are using the ML to talk design 20:23:44 those things could also be voted on in meetings 20:23:53 assuming you've had good enough conversation on ML 20:24:01 the vote would be quick 20:24:07 vipul: Good point 20:24:07 yes thats a good point 20:24:11 the votes work just like code reviews though right? core has final decision. 20:24:17 I think this is a neat idea, but long term I think the artifacts might be too awkard. 20:24:18 keep out weird one off votes. 20:24:58 once we are all voting it might be mo-bettah 20:25:02 errrrrr 20:25:10 I'm thinking +1, or −1 for everyone. Unless we need to break a tie. 20:25:12 once we are all reading the ml voting will be mo-bettah 20:25:18 SlickNik: thats the job of ptl 20:25:22 and of core in general 20:25:41 to me its, core first, if core is split, ptl makes a hard decision 20:25:43 Agreed, the fact core votes count more won't matter if we're fair. If this is for odd one-offs that won't be an issue. 20:25:45 ^ ^ for a tie 20:25:52 do we need a set timeout for voting? 20:26:00 or when do we declare voting done? 20:26:11 kevinconway: i think we can set a majority # 20:26:16 if it gets X votes in teh pos/neg its done 20:26:17 hub_cap: yup, sounds good 20:26:21 but really 20:26:27 i think the ML is gonna help deal w this 20:26:35 so lets focus a bit less on this now and try the ML 20:26:46 and i agree w vipul that it will sort itself out 20:26:51 but we NEEEEEED to do our homework 20:27:01 dont come to a meeting not being up to speed on your mail 20:27:13 if you are not reading the trove ML things, you arent participating 20:27:23 then its the same as where we were in teh past :) 20:27:57 itll be kinda bumpy in the beginning... just set a special tag / smart inbox whatever for trove 20:28:11 and make sure u stay up on them if u care about the direction of trove ;) 20:28:17 #done 20:28:31 Ok. 20:28:40 #topic capabilities (example, mysql+redis, under same api server, one having volumes and one not) 20:28:51 ok i put this 20:29:02 and i think its a GREAT ML discussion so i may just punt it to the ML 20:29:11 but to let everyone udnerstand 20:29:25 not every service will have the same capabilities (such as maybe we dont want floating ips for a particular service) 20:29:36 so we need a way to say "this service has these", or at least i think we do 20:29:49 and a way to config the services so they are, and can be, different 20:30:00 maybe we dont need a way to tell a customer how its different 20:30:03 * grapex just realized we could solve the ML problem by putting all topics on the mailing list and ending the meeting early. 20:30:11 #endmeeting 20:30:12 lol 20:30:14 i remember sometime back we talked about this being handled through service extensions 20:30:18 good thing i cant do that ;) 20:30:19 :) 20:30:23 yeah, good thing 20:30:33 service_type based config? 20:30:41 yogesh: yes theres was talk about that 20:30:44 vipul: kinda... ya 20:30:47 hub_cap: grapex: a pre-meeting ML of the agenda might not be a bad idea either. 24hrs ahead? 20:30:47 hub_cap, as requested, I added a blueprint for this particular item https://blueprints.launchpad.net/trove/+spec/capabilities 20:31:00 off topic. sorry. 20:31:04 maybe we mod the config to do [service_type]\nthing=value.... 20:31:13 hub_cap: Are you suggesting we make the values of certain capabilities traditionally in the conf files available via an API or something? 20:31:13 thank you david-lyle 20:31:25 ohhhhhh yes yes, so things like horizon do need this exposed 20:31:30 so they know how to craft the ui 20:31:39 would there be a master set of capabilities...? 20:31:41 i knew there was a reason for that, david can you do a #link .... 20:31:55 that's a bit different from service_type based config though.. 20:32:11 yogesh: possibly? i dont think its out of the question to have a default list if you dont have that explicitly defined in the service_type 20:32:19 and dug up a past mailing list thread regarding extensions and capabilities in general http://lists.openstack.org/pipermail/openstack-dev/2013-May/008436.html 20:32:23 you could solve it by requiring that you run separate config-specific deployment of a component (like nova-compute or something) 20:32:41 david-lyle: when putting links on the meeting start a new line with #link http.... 20:32:49 so it shows up on the meeting logs fancy style 20:32:58 can u #link the BP and the ML 20:33:05 #info you can #link things 20:33:10 #link https://blueprints.launchpad.net/trove/+spec/capabilities 20:33:20 You could have a system where if a [service_type] \n thing=value is defined, we use that. 20:33:24 perfect!!!! (nice kevinconway ) 20:33:26 #info you can #info things too 20:33:32 #undo 20:33:36 :P 20:33:37 If not we fallback to the [default]\n thing=value 20:33:39 #info #agreed 20:33:42 couldn't resist 20:33:43 yes i think so SlickNik 20:33:44 #link http://lists.openstack.org/pipermail/openstack-dev/2013-May/008436.html 20:33:47 thx david-lyle 20:33:51 np 20:33:58 it would also break up the config in general 20:34:11 i fear itll get hairy if u have 6 services running and dont split them up 20:34:23 there are going to be things that have NO reason to be in [DEFAULT] 20:34:33 So we would maintain backwards compat with existing configs as well. 20:34:35 redthrux: #agreed? 20:34:52 SlickNik: yes thatll be the default effectively.. 20:35:02 #agreed 20:35:17 then maybe custoomize it with [mysql]volume_support=False 20:35:28 every lookup of a cfg will require passing looking up the service_type? 20:35:45 i did somethign on cinder that did this 20:35:48 for multi backends 20:35:59 it first checked the service_type and then falldeded back to default 20:36:02 parsing that wont be very hard 20:36:02 let me find 20:36:11 it was for multi backends 20:36:26 Would it change the code so that rather than referencing a single config object, it would grab a collection of config objects using the service_type as a key and then pass that around via method arguments? 20:36:47 ehh cant find it right now 20:36:58 cfg.service_type.blah is how it works grapex 20:37:14 if its in a [different] area it would be cfg.different.some_value 20:37:22 hub_cap: Ok, the reason I ask is that "volume_support" could be in a general Trove code path 20:37:41 #link https://github.com/openstack/cinder/blob/master/cinder/volume/configuration.py 20:37:48 So we'd probably want to find it via "configs = cfg[service_type]\n configs.some_value" 20:38:11 grapex: this code first checks for cfg.service_type.volume_support, if its not ther it asks for cfg.volume_support 20:38:55 hub_cap: I see. I guess my point is the Trove code path to provision a server and volume may not normally care about the service type. I guess all I'm saying is we use a dictionary key instead of an attribute. 20:39:29 if we dont put a particular [service_type] in it, it wont care 20:39:35 itll be up to the configuror of the system 20:39:37 hub_cap: This is getting into the weeds, we'll figure it out. :) 20:39:44 grapex: I think you'd still be able to get the default values if you don't specify the service type. 20:39:50 yes 20:40:04 ya we are 40 in and likely need to move on 20:40:17 Sounds god. 20:40:21 good* 20:40:23 #info defaults + [service_type] values are a good thing 20:41:07 WOO my legs r shaking ive almost downed a quad americano from a little coffee shop across the street from Cal 20:41:18 #topic decision on servicetype/flavor in trove (yet again :-)), https://gist.github.com/mehrayogesh/1dfac0b4ffaf97fb885b (yogesh) 20:41:35 so there are couple options...per gist 20:41:55 longest topic name. evar. 20:42:11 hub_cap: Copy and paste fail on my part. 20:42:16 :P 20:42:19 :-) 20:42:39 maintaining the nova flavors from within trove api or not, thats the main difference 20:43:07 It seems like the moment we have extra Trove info for flavors, we have to maintain them in the database. 20:43:16 So there's no other option. Unless I'm missing something? 20:43:35 i think he means creating/destroying from trove, correct yogesh 20:43:37 ? 20:43:45 Wasn't there some way of maintaining metadata as part of the flavor in nova. 20:43:45 What i see is we introduce a 'registration' API 20:43:47 ? 20:44:11 yes i do not want to add/delete from trove. register is a good word for the functionality vipul 20:44:18 i want to "add" to trove 20:44:26 but barf if the flavor specified is not in nova 20:44:30 are we taling about option 2 20:45:02 flavor has to be there in nova, for option 2 to work 20:45:14 #link https://gist.github.com/mehrayogesh/1dfac0b4ffaf97fb885b 20:45:36 yogesh: nice gist. perfect for the mailing list (future, not this one... :) ) 20:45:39 thanks hub_cap 20:45:48 sure 20:46:06 ogeez.. deregister is perfect for http PATCH 20:46:12 * hub_cap jumps on PATCH soapbox 20:46:14 jk 20:46:31 i think option 2 makes more sense 20:46:41 we may not be able to add flavors to nova even 20:46:47 hub_cap: Agreed. 20:47:05 yeah 20:47:14 Ok. Moving on... 20:47:24 #topic Configuration API update 20:47:24 so, option 2 is decided...thanks 20:47:26 I prefer approach 2 as well 20:47:41 GO GO GO cp16net 20:47:50 joy 20:47:51 cp16net: gist looks good 20:47:54 is amcrn around? poop i guess not hes not tab completing 20:48:04 yeah so i compiled a list of all th api calls 20:48:25 #link https://gist.github.com/cp16net/6704590 20:48:42 for the record, not having to do w/ this 20:48:46 * cp16net is in the process of putting this in ML 20:48:47 :-P 20:48:48 public gists plz (thx cp16net !!!!) 20:48:53 https://gist.github.com/cp16net/6704590 20:48:55 there is no reason for private gists... 20:49:03 sure 20:49:14 hmm its public 20:49:18 cp16net: u KNOW im gonna be all over PATCH 20:49:26 cp16net: slow your roll... i thanked u above 20:49:28 ;) 20:49:43 what about making Configurations API being a part of Clustering API 20:49:50 but the main thing is making everyone aware of what is happening 20:50:08 the PUT could be changed to PATCH but its still relativley new 20:50:12 cuz we have no ability to pass additional parameters to group of nodes in cluster 20:50:14 dmakogon_: there should be a way to have cluster based configurations but it should be its own api 20:50:26 clusteing will have to use configurations 20:50:28 i've thought alot about using PATCH and i am not sold on it in at least this rev of the API 20:50:36 hub_cap: there could be an overlaps 20:50:37 i'd say don't even bother with PATCH until we can be sure it works on different clients 20:50:41 pssh. put it on the ML 20:51:00 ok 20:51:04 dmakogon_: lets make sure we do it so there arent.. configuratiosn are not unique to clusters 20:51:19 yeah thats where this is headed today.... to the ML! 20:51:22 :-) 20:51:23 hub_cap: +1 20:51:27 dmakogon_: the "pssh" was to cp16net and his "PATCH is new" comment 20:51:29 Hurray for the ML! 20:51:32 aaa 20:51:36 Ok, moving on 20:51:41 lets do 20:51:44 #topic Configuration + service type and versions 20:51:47 Agh 20:51:48 kevinconway: /me doesnt care about someone building a rest api in their browser ;) 20:51:51 :) 20:51:53 alright 20:51:58 wow nice grapex 20:52:02 copy pasta fail #2 20:52:05 :P 20:52:10 hub_cap: that is why i'm wondering firstly adding Configurations to CLusteing and then re-use it in Conf.API 20:52:20 cuz clustering doesnt exist 20:52:24 we good... 20:52:39 cp16net: Ok. 20:52:42 ya i guess you have to start over again cp16net 20:52:48 so i notcied there was overlap on the configuration and some of the service type stuff 20:52:50 #topic MySQL HA 20:53:00 oh this is different! ML topic again? amcrn has input on thsi 20:53:02 *this 20:53:18 my bad for copy pasta remark grapex !!!! i didnt notice the subtle differences ;) 20:53:26 arg... 20:53:32 hub_cap: Me neither. I thought I'd copied it in twice it was so similar. 20:53:37 kwarg? cp16net 20:53:40 Which ironically means I was paying more attention than I thought. 20:53:40 well amcrn isnt here 20:53:49 ya cp16net MAAAAAAAILING LIST 20:53:52 * hub_cap harps 20:53:53