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