18:01:16 <hub_cap> #startmeeting trove
18:01:18 <openstack> Meeting started Wed Mar 26 18:01:16 2014 UTC and is due to finish in 60 minutes.  The chair is hub_cap. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:21 <vipul> o/
18:01:22 <openstack> The meeting name has been set to 'trove'
18:01:24 <grapex> o/
18:01:25 <kevinconway> \o/
18:01:35 <robertmyers> o/
18:01:35 <juice> o/
18:01:35 <SlickNik> o/
18:01:48 <peterstac> o/
18:01:52 <doug_shelley66> o/
18:01:56 <cp16net> (ʘ෴̴͜ʘ)
18:02:02 <hub_cap> umm
18:02:03 <vipul> woah
18:02:03 <SnowDust> <o>
18:02:08 <cp16net> lol
18:02:11 <amcrn> o/
18:02:14 <juice> cp16net: I know you have been waiting all week for this
18:02:15 <amrith> in some language that must look pretty
18:02:18 <amytron> o/
18:02:28 <juice> cp16net: you probably got up early to rehearse:
18:02:37 <hub_cap> lol juice
18:02:40 <SnowDust> juice: LOL
18:02:40 <amytron> juice:  how did you know?!
18:02:50 <amcrn> the early bird gets the worm juice, don't be jealous ;)
18:02:55 <hub_cap> #topic openstack summit
18:03:02 <grapex> juice: What's interesting is cp16net in real life has no mustache
18:03:04 <hub_cap> so, we only have 1 session proposed
18:03:07 <esmute> o/
18:03:12 <vgnbkr> o/
18:03:39 <kevinconway> hub_cap: we could probably fill several days of the conference with users
18:03:40 <hub_cap> lets rally and get some sessions pushed up
18:03:44 <hub_cap> LOOL kevinconway
18:03:46 <cp16net> hah
18:03:54 <vipul> what's the deadline?
18:04:07 <cp16net> let do eet
18:04:09 <annashen_> o/
18:04:26 <hub_cap> vipul: good question, idont know
18:04:28 <SlickNik> I'm looking at pushing up info for a couple of sessions by the end of this week.
18:04:28 <hub_cap> les say today
18:04:29 <hub_cap> ;)
18:04:35 <vipul> :p
18:04:40 <hub_cap> ok lets try to push someting, anything, by EOW
18:04:49 <cp16net> word
18:04:58 <hub_cap> remember, anyone can propose
18:05:38 <hub_cap> and u can update it once u propose
18:05:46 <hub_cap> i wont start scheduling for about 2 more wks
18:05:54 <hub_cap> so i guess ill speak about the process a bit
18:05:58 <hub_cap> just so we are aware
18:06:11 <hub_cap> so anyone proposes to summit.o.o
18:06:24 <hub_cap> and i take those and i have the abilty to schedule them, regject them, mark as dups etc
18:06:41 <hub_cap> i rely on the core team to help
18:07:01 <hub_cap> so we can all get it iron outdddddddddddddd
18:07:08 <hub_cap> ^ ^ joke for grapex
18:07:21 <hub_cap> any questions on the process?
18:07:42 <doug_shelley66> i assume the actual time/room scheduling is done by the conf organizers?
18:07:59 <hub_cap> so the blocks of time are done by ttx
18:08:03 <doug_shelley66> so could be scattered anywhere across the 4 days
18:08:14 <hub_cap> and he consults the ptls to talk about the room blocks and how they coincide
18:08:17 <hub_cap> and if there are conflicts
18:08:23 <amytron> if a session is marked as a dup, do the two proposers need to pair up?
18:08:25 <doug_shelley66> ah ok
18:08:27 <hub_cap> but once we have a "block" we are in the same room
18:08:30 <vipul> do we get > 1 day now?
18:08:30 <hub_cap> amytron: if they wish :)
18:08:47 <hub_cap> vipul: nope but we get a full day iirc
18:08:51 <hub_cap> or 2x the ammt of sessions
18:08:52 <hub_cap> as for dups
18:09:00 <hub_cap> the one that is best written up usually "wins"
18:09:11 <hub_cap> but i will consult both authors and get them to work together
18:09:47 <hub_cap> these are design sessions, so both authors will likely bein the same room anyway
18:10:04 <hub_cap> so doug_shelley66 to reiterate (not sure if i did) we have 1 room the entire time
18:10:22 <vipul> yea and for folks new... these are super informal.. the presenter just starts the discussion
18:10:22 <doug_shelley66> hub_cap from tues to friday? or just 1 day?
18:10:28 <vipul> doesn't ahve to have everything prepared
18:10:30 <hub_cap> doug_shelley66: 1 day, back to back to back to back
18:10:45 <hub_cap> yup vipul, we end up having an etherpad / blueprint
18:10:48 <hub_cap> and then discuss it
18:10:52 <grapex> hub_cap: If all of ours end up being on the same day then I submit "Trove: Nap time" to be preceded by juice boxes.
18:10:53 <juice> hub_cap: will the revolution be televised?
18:10:56 <hub_cap> and this time we wont have HELLA jetlag
18:11:09 <juice> or for those that are not there, they just don't participate
18:11:13 <hub_cap> grapex: did u consult juice ?
18:11:25 <hub_cap> juice: ummm i think we are getting better w/ televising
18:11:30 <juice> I know openstack provides video that next day or the day after
18:11:34 <hub_cap> but in the past its been pretty bad heh
18:11:43 <grapex> hub_cap: I actually meant juice which give us each a specially wrapped box with a present he picked out for us.
18:11:52 <hub_cap> grapex: ++
18:11:58 <kevinconway> so do the proposers need to also be presenters?
18:12:01 <cp16net> how many session will we have?
18:12:07 <amytron> should we plan to stay for a full day on friday? are there usually a lot of sessions planned on the last day?
18:12:36 <hub_cap> amytron: the sessions go till EOD friday
18:12:37 <amrith> hub_cap: since some of us plan to come in late or leave early (not stay the whole week) it would help to know which day was the trove design sessions
18:12:55 <hub_cap> and there is _always_ a possiblity we will have sessions "moved" to friday because of conflicts
18:13:07 <hub_cap> amrith: ill ask ttx if what hes proposes is irond out
18:13:20 <amrith> can we assume that there are no design sessions on Monday and Tuesday?
18:13:30 <amrith> only W, T and F?
18:13:46 <hub_cap> but if say, 2 other projects are conflicting and they need us to switch
18:13:49 <hub_cap> i wont say no
18:13:55 <hub_cap> there was a bit of switching in HK but not a ton
18:14:06 <hub_cap> and i ALWAYS ALWAYS ALWAYS recommend staying the whole time
18:14:15 <vipul> amrith: i think sessions will be T-F
18:14:21 <amrith> ok, any heads up you can provide in this regard would be much appreciated.
18:14:22 <doug_shelley66> but you are saying that when you pick the topics you will only pick enough to fill 1 day?
18:14:23 <hub_cap> yes vipul T-F
18:14:34 <hub_cap> doug_shelley66: i will pick enough to fill our slots we are given
18:14:37 <esmute> T for tuesday or thursday?
18:14:38 <amytron> what time is "EOD" on friday?
18:14:43 <hub_cap> TUE-FRI
18:14:43 <vipul> lol
18:14:44 <amrith> t for thursday
18:14:47 <amrith> oh
18:14:47 <SlickNik> T=Tuesday
18:14:49 <hub_cap> monday is just keyonets
18:14:50 <amrith> t for tuesday
18:14:52 <vipul> good thing you clarified :)
18:14:53 <amrith> ok
18:14:57 <hub_cap> its on the splash page yall
18:14:57 <amrith> good thing you clarified
18:15:06 <vipul> https://www.openstack.org/summit/openstack-summit-atlanta-2014/
18:15:08 <vipul> scroll down :)
18:15:10 <SlickNik> #link https://www.openstack.org/summit/openstack-summit-atlanta-2014/
18:15:13 <hub_cap> thx vipul i was just getting that too
18:15:16 <hub_cap> thx SlickNik
18:15:39 <hub_cap> but srsly guys, i ALWAYS recommend staying, but a good bit of people do leave early
18:15:53 <hub_cap> so if u leave, and we have a friday session, then ill be there to hold down the fort
18:16:57 <cp16net> i just make the decisions for everyone
18:17:01 <cp16net> :-P
18:17:05 <cp16net> j/k
18:17:16 <esmute> you guys dont want to miss the party that we throw out anyways
18:17:37 <hub_cap> esmute: plz tell me yer party is not friday LOL
18:18:01 <juice> HP is cutting budget this year so we are trying to minimize attendees to the party
18:18:05 <esmute> throw down* Thanks juice for correcting
18:18:11 <esmute> lol
18:18:15 <hub_cap> juice: WEAK ;)
18:18:20 <juice> just kidding
18:18:35 <amrith> ah, I see. cost cutting, everyone brings their own juice. I'm claiming first dibs on juice ;)
18:18:36 * hub_cap goes to the press w/ juice 's comment
18:18:37 <juice> I'm sure we will have all you can eat chicken and waffles
18:18:49 <hub_cap> amrith: ummmmmmmmmm u can have all dibs on juice
18:18:51 <hub_cap> ;)
18:18:55 <cp16net> thats delish
18:18:56 <doug_shelley66> should i sell my HP stock?
18:19:18 <juice> doug_shelley66: it's skyrocketing
18:19:32 <doug_shelley66> ah because of the cost cutting :) i see
18:19:35 <hub_cap> dude im so having c&w there
18:19:53 <juice> what's the next topic :)
18:19:57 <hub_cap> lol ya
18:20:10 <vipul> lol juice doesn't want to get caught giving insider trading advice :)
18:20:15 <hub_cap> amrith: is up :)
18:20:21 <amrith> ok
18:20:23 <hub_cap> #topic datastore abstraction
18:20:31 <amrith> Two related topics that I want to discuss.
18:20:31 <amrith> One is the blueprint for the proposed change; not for icehouse, likely later.
18:20:31 <amrith> The second is the review for https://review.openstack.org/#/c/82080/
18:20:31 <amrith> To the blue print.
18:20:40 <amrith> Unix'es have implemented abstractions like /etc/init.d or upstart to address the issue of a simple mechanism to handle service start and stop. It is an abstraction that allows the OS to easily start and stop services, and for the services to implement basic functionality in this regard.
18:20:42 <hub_cap> #link https://blueprints.launchpad.net/trove/+spec/trove-guest-agent-datastore-control
18:20:54 <amrith> yes, that one
18:20:58 <hub_cap> amrith: nothign is for icehouse anymore ;)
18:21:07 <amrith> absolutely
18:21:11 <amrith> says so in the bug and the bp
18:21:26 <amrith> Unfortunately, there are more than one standard.
18:21:26 <amrith> Therefore, a meta service like the guest agent needs to build an abstraction layer as well.
18:21:42 <amrith> The benefits are obvious.
18:21:42 <amrith> We should not have bugs like https://bugs.launchpad.net/trove/+bug/1295313
18:21:42 <amrith> The common abstraction would provide a mechanism in which each data store would describe the right way to start/stop/control itself.
18:21:42 <amrith> Defaults would be provided (use service start) or some such.
18:22:10 <amrith> so I guess my first question to core is this ...
18:22:18 <amrith> I've not done any of the implementation  (yet)
18:22:24 <amrith> have some thoughts on the implementation though
18:22:43 <amrith> should this BP move to the BP review meeting which is on Monday or can we discuss now?
18:22:52 <amrith> reason I put it on now is because I have a part 2 to this conversation
18:23:01 <juice> amrith: I think you keep going
18:23:07 <yogesh> amrith: are we talking about an interface which all the guest agents should implement OR are u talking about a base guest agent implementation...?
18:23:30 <amrith> I am talking about an interface that would be part of each guest agent
18:23:45 <amrith> right now, there's some code in operating_system.py which attempts to abstract some of this knowledge
18:24:13 <vipul> so each datastore manager implement start() and stop()? and the logic for each datastore would be different?
18:24:31 <amrith> so each data store will tell how it wants start() and stop() to be done
18:24:37 <juice> amrith: a question off the top of my head is isn't the abstraction in the datastore/manager.py enough
18:24:39 <amrith> it could simply be to say "use service" in some fashion
18:24:50 <amrith> juice, I'll get to that in a second
18:24:52 <grapex> amrith: So this is just helped code to call the unix based stop / start scripts for an implementation if you want
18:24:53 <grapex> ?
18:25:30 <amrith> to vipul's quesiton, a data store that has a simple service command (eg mysql) would just use that but would explicitly state that.
18:25:38 <amrith> for a sevice (say cassandra) it would be the same thing
18:25:52 <amrith> for mongo on the other hand, the data store would provide the commands to execute for start/stop etc.,
18:26:14 <amrith> to juice's question: the code in oeprating system.py is called adhoc by some data stores (I believe).
18:26:26 <amrith> and the code attempts to guess based on what it sees on the file system
18:26:34 <grapex> amrith: But what if a Trove operator wants to run MySQL on Windows?
18:26:36 <amrith> it attempts to pick which to do in some order
18:26:41 <grapex> J/k!
18:27:09 <amrith> but if we have a data store (for example) that requires multiple services, the code in oeprating system.py is not capable enough
18:27:28 <amrith> so in effect, we have a situation where each data store has to implement or adopt the code in operating_system.py
18:27:47 <amrith> instead, I'm proposing that in order to avoid bugs like the one amcrn found, that we make this a clear abstraction.
18:27:56 <amrith> to grapex question, yes
18:27:59 <amrith> it may not be scripts
18:28:02 <grapex> amrith: This sounds like it's just adding some helper code different implementations can choose to use. Doesn't seem too controversial.
18:28:03 <amrith> it may be commands that have to be run
18:28:11 <amrith> for example "mongodb --shutdown"
18:28:30 <amrith> grapex, i think the implementation would be along the lines you are proposing
18:28:34 <vipul> +1 i think each manager owning its own stop/start routines is good.. shouldnt' try to shoehorn everything into a single class
18:28:34 <amrith> it is largely helper code
18:28:54 <amrith> and it will allow each data store to pick its own start/stop without necessarily duplicating the code in many places
18:29:22 <amrith> and it would handle things like cleaning up PID files etc.,
18:29:29 <amrith> which a simple KILL command doesn't do
18:29:50 <amrith> to the question of windows, sure it is supported, in v16
18:29:51 <amrith> j/k
18:29:52 <SlickNik> amrith: +1 I think this is a good idea.
18:30:09 <amrith> so, my second process question.
18:30:11 <amcrn> +1, on-board.
18:30:13 <amrith> what's the next stop?
18:30:22 <vipul> atlanta
18:30:27 <amrith> I flesh out the implementation details in the BP and come back to all-y'all at Atlanta?
18:30:48 <vipul> j/k I think this is a minor one
18:30:51 <amrith> ok, thx vipul
18:31:01 <amrith> now to the more controversial issue
18:31:02 <SlickNik> amrith: Clarification, does this tackle discovery of the start stop service? (systemd vs. upstart, for example) or is that v2?
18:31:07 <vipul> actually you should just fix it and do it before that
18:31:15 <vipul> if it's possible.. no need to wait for summit
18:31:21 <amrith> one second
18:31:31 <amrith> SlickNick, answer re: discovery
18:31:41 <amrith> I will try and keep that logic around
18:31:46 <amrith> but I'm dubious about it
18:32:14 <amrith> let me think more and come back to you with a cogent argument rather than some rambling
18:32:25 <amrith> OK?
18:32:47 <amrith> vipul: were you talking about the more controversial issue (https://review.openstack.org/#/c/82080/)?
18:33:00 <amrith> this is the other half of amcrn's https://review.openstack.org/#/c/81914/
18:33:04 <SlickNik> amrith: Sounds good.
18:33:21 <amrith> SlickNick: thx
18:33:29 <vipul> amrith: i guess i don't know why this one is so controversial.. seems like we shoudl be using service stop for c*
18:33:39 <amrith> I don't know why it is that https://review.openstack.org/#/c/81914/ is +1 but https://review.openstack.org/#/c/82080/ is -1. I assume we don't have to rehash the email exchanges re: the MySQL bug that was part of the discussion of amcrn's fix. I was asked to "provide proof" which I did. But the person asking for it is now silent.
18:33:53 <amrith> CORE: What is your guidance on this?
18:34:10 <amrith> could I get a code review either up or down for https://review.openstack.org/#/c/82080/
18:34:18 <hub_cap> well amrith if it was denis_makogon its cuz he had to leave for the meeting
18:34:24 <kevinconway> i'd prefer a dramatic reading of the email exchanges
18:34:32 <amrith> I can't grok why service start works in ubuntu but service stop doesn't ;)
18:34:36 <grapex> Who here is using Casandra or running it today?
18:34:38 <hub_cap> kill should not be used
18:34:44 <vipul> if you say it works.. i'd +2 it :D
18:34:50 <amrith> kevinconway: action item, I'll do the dramatic reading (in costume in Atlanta)
18:34:58 <konetzed> amrith: why arnt these config values and not hardcoded
18:34:59 <konetzed> ?
18:34:59 <SlickNik> amrith: I'd +2 the review based on Viswa's reply. We should _not_ be using kill.
18:35:14 <amrith> I pasted into chat a login session with service start and stop
18:35:23 <konetzed> amrith: so anyone can use what ever they want for start and stop w/o having to change the code
18:35:29 <amrith> ViswaV and I had a very detailed discussion of this as well
18:35:40 <vipul> amcrn: what do you think? you guys run cassandra?
18:36:00 <amcrn> yeah, let me test the stop server command, and ensure it works
18:36:02 <amrith> konetzed: the idea is that in the blueprint they would be to make this do'able
18:36:19 <amcrn> because it looks like everyone agrees that kill is overkill if service-stop works
18:36:30 <hub_cap> konetzed: i think thats a good question
18:36:35 <grapex> amcrn: That's my view- it's overkill, *if* something else works.
18:36:56 <amrith> give me a second and I'll find the URL to the paste
18:37:11 <grapex> I'll admit it everyone... I'm not above writing a call to "kill" into the guest code, but only if there's a great reason. Probably don't want to kill a service we'll be handing to end users either.
18:37:23 <grapex> Better for an admin to log in and figure out why it won't die.
18:37:48 <kevinconway> we can use Python's os.kill()
18:37:55 <kevinconway> skip the subshell
18:38:16 <grapex> kevinconway: But first we'll call grep to get the process ID, so we know we have the right one.
18:38:17 * hub_cap marks kevinconway as a perma-troll
18:38:18 <vipul> yea than we wouldn't feel so guilty
18:38:19 <amrith> http://paste.openstack.org/show/74160/
18:38:42 <amrith> so, there's more to killing the process than the kill with the right pid
18:38:46 <hub_cap> so amrith i think koko is saying make the start/stop/restart configurable from the config.file
18:38:48 <amrith> there's also the issue of cleaning up a pid file
18:39:00 <hub_cap> as opposed to putting it in a .py file
18:39:03 <amrith> tht would be a good option for the bp
18:39:16 <hub_cap> yea i think thats valid, so if kevinconway wants to use pkill w/ his bash agent he can
18:39:18 <amrith> do you want to do that now, given that amcrn's fix is in already?
18:39:32 <esmute> lol
18:39:36 <amrith> amcrn: pl take a look at the paste output I put above
18:39:37 <SnowDust> koko :D !
18:39:40 <amrith> it has the service start/stop
18:39:43 <kevinconway> pkill -9 -f * to be exact
18:40:00 <amrith> hub_cap: you proposed init 0 yesterday. That worked.
18:40:11 <hub_cap> HAHAHAHA
18:40:31 <amrith> so what does core propose?
18:40:39 <amrith> I have a +1 and a -1
18:40:42 <juice> kevinconway: the ONLY problem with that is that the guest agent won't be around to report back status
18:40:53 <hub_cap> i think we should do this
18:40:57 <kevinconway> juice: it's scheduled on a cron job to restart
18:40:59 <kevinconway> self-healing
18:41:00 <hub_cap> but i also think we should go further and make it configurable
18:41:03 <hub_cap> lol kevinconway
18:41:07 <grapex> hub_cap: Agreed
18:41:09 <amrith> if a data store dies in the forest and there is no guest agent to see, does it send a notification?
18:41:40 <amrith> so hub_cap: do you want to do that for both start and stop, now?
18:41:42 <grapex> amrith: Nope.
18:41:47 <amrith> I'm asking the tactical question for now
18:41:48 <hub_cap> amrith: im pretty sure i saw a commercial about that recently
18:41:59 <SlickNik> We could make it configurable as part of the abstraction bp amrith suggested previously.
18:42:02 <grapex> hub_cap: Was it for life insurance?
18:42:09 <hub_cap> so amrith i think its ok to do that in multiple parts, but i dont think itll be a ton of work to do them together
18:42:16 <hub_cap> grapex: it was for toaster pastries
18:42:23 <grapex> hub_cap: Odd
18:42:26 <hub_cap> hahahahaha
18:43:07 <hub_cap> vipul: SlickNik grapex what do yall think?
18:43:37 <grapex> I am down for this blueprint. I do think in the future we might want to make things more configurable but this seems like it will work for everyone atm.
18:43:40 <SlickNik> I'm good with doing it incrementally.
18:43:46 <vipul> i'm ok with the current patch, and as part of the start() stop() abstraction mentioned earlier.. we can make it somehwat configurable
18:44:04 <konetzed> i think it should end up configurable sooner rather then later but i think its ok getting in amrith changes in now, just my 3 cents
18:44:56 <esmute> what is being configurable? Whether to use systemd/upstart/killall etc?
18:45:07 <cp16net> looking at this more i think all of the {datastore}/system.py is just a big configuration
18:45:24 <cp16net> shouldnt this be in configurations?
18:45:29 <hub_cap> ++
18:45:45 <SnowDust> cp16net : +1
18:45:57 <amrith> OK folks, I'll be prepared to talk more about this in Atlanta (the blueprint, that is). if you approve https://review.openstack.org/#/c/82080/ it is good to go.
18:46:33 <SnowDust> if cfg.py defines datastore options why not start/stop/ for it as commands too ?
18:46:43 <amrith> cp16net: yes I think it should be configurations but preferably in some way such that you don't have duplicated code that ends up being a bug fix requiring identical changes in five places.
18:47:09 <robertmyers> SnowDust: yes, we should do that
18:47:11 <amrith> SnowDust: that is a good place to put it.
18:48:51 <amrith> Other thoughts? hub_cap, amcrn, grapex, SlickNick
18:49:02 <hub_cap> honestly
18:49:11 <hub_cap> this file is a big config file just like its been said already
18:49:16 <hub_cap> we should, porbably in a diff review
18:49:23 <hub_cap> move it all to config based w/ sane defaults
18:49:30 <grapex> hub_cap: And once the freeze thaws lets move the guest agent around a bit
18:50:06 <grapex> I think at that time it'll be pretty simple to see how the configs work and whoever fixes it might get an easier consensus.
18:50:06 <hub_cap> we could probably do CONF.ubuntu.blah and CONF.redhat.blah (im sure we can come up w/ better names but u get the point)
18:50:11 <hub_cap> ++
18:50:13 <SnowDust> amrith, my bp that abstracts cfg.py for datastore options https://blueprints.launchpad.net/trove/+spec/refactoring-datastore-options-in-cfg is already approved, i can extend that to include what i was talking
18:50:15 <amcrn> sorry, back, was on phone call
18:50:43 <amrith> SnowDust: let's talk about that approach
18:50:58 <amrith> will u be in Atlanta?
18:51:03 <hub_cap> way to go amcrn we wouldnve never known
18:51:13 <hub_cap> amrith: this should be solvable befoere atl
18:51:14 <grapex> amrith: Maybe we don't need to wait until Atlanta
18:51:17 <hub_cap> LOL
18:51:45 <amrith> hard to put a face to a name on IRC
18:51:54 <hub_cap> AHHHHH
18:51:56 <SnowDust> amrith i got my atendee pass free .. sponsor tesora tickets :) as well .. i will be there :D
18:51:56 <amrith> austin was good
18:52:00 <hub_cap> nm then amrith
18:52:02 <amrith> also for brisket
18:52:06 <amrith> and I'm a vegetarian
18:52:14 <hub_cap> YESHHHHH
18:52:21 <hub_cap> ok so one last thing
18:52:24 <hub_cap> i assume we are done w/ this
18:52:30 <hub_cap> amrith: do u feel good about the outcome?
18:52:34 <hub_cap> service is valid
18:52:36 <amrith> I'm assuming that reviewers will do their +1's offline
18:52:37 <amrith> I'm good
18:52:43 <amrith> thx all
18:52:48 <amcrn> so reading through the chat log: we're going to merge the service start/stop (assuming stop actually works), but in the long-term amrith and others will work out the long-term strategy?
18:52:48 <hub_cap> but we also need to eventually make tehse configurable
18:52:54 <amrith> SnowDust: sorry have to dissapoint on the tickets
18:53:04 <hub_cap> amcrn: gosh why dont u say waht i said but smarter
18:53:19 <SnowDust> amrith: .. will feel happy to discuss on the approach anyway
18:53:24 <amcrn> :)
18:53:35 <hub_cap> #topic icehouse rc1
18:53:45 <hub_cap> soooooo
18:53:51 <hub_cap> we are one bug out from being RC1 complete
18:53:57 <hub_cap> we will merge that today
18:54:01 <cp16net> yay
18:54:07 <hub_cap> and ttx  will cut RC1 tomorrow
18:54:07 <SnowDust> congrats !!!
18:54:13 <cp16net> you feel the excitment?
18:54:21 <cp16net> (sp)
18:54:23 <vipul> (party)
18:54:36 <SnowDust> cores, <3
18:54:36 <grapex> hub_cap: I knew if we tried hard enough we'd eventually be able to merge all the bugs to RC1.
18:54:37 <SlickNik> hell yea!
18:54:41 <hub_cap> HAHAH
18:54:48 <hub_cap> once RC1 is cut
18:54:49 <grapex> So, when do we ship the CDs?
18:54:55 <amcrn> grapex: just click +2 next to every review, it's the gates job to protect us, right?
18:54:57 <hub_cap> grapex: lets let ubuntu do that ;)
18:55:00 <amcrn> ;)
18:55:04 <hub_cap> amcrn: ++
18:55:06 <SlickNik> lol @ amcrn
18:55:09 <vipul> grapex: so you can put it in your microwave :p
18:55:11 <hub_cap> so once RC1 is cut, juno officially opens
18:55:12 <grapex> I've been looking forward to putting it up next to my copy of Norton Desktop Commander 98.
18:55:24 <grapex> hub_cap: Awesome.
18:55:32 <hub_cap> hey m$ opensourced "word for windows"
18:55:34 <cp16net> grapex: i need 500 hours free
18:55:36 <amrith> sorry to be the party pooper ... amcrn and grapex (maybe others) have to +1 my review ;)
18:55:48 <amrith> I'll get right on to the guest agents on Windows blueprint after that
18:55:53 <vipul> i heard the same for MS DOS...
18:56:00 <hub_cap> yuppp
18:56:04 <hub_cap> so i just wanted to say
18:56:08 <vipul> only 30 years later
18:56:10 <grapex> vipul: Free Dos as a service....
18:56:29 <hub_cap> core will be looking at all the reviews, so plz dust them off, take them out of abandon mode
18:56:32 <hub_cap> and rebase them
18:56:43 <vipul> i bet people are dieing to have that
18:56:43 <hub_cap> we will likely do a run thru of tox before looking at code
18:56:46 <hub_cap> recheck no bug ;)
18:57:08 <SnowDust> vipul, :p
18:57:17 <hub_cap> so if your code fails tox, we will not look at it yet ;)
18:58:17 <hub_cap> ok so if no one has Qs im going to end this early
18:58:21 <kevinconway> o/      gpg keys ==> sign them
18:58:38 <vipul> oh what about the vote on Cluster API?
18:58:53 <kevinconway> i need to wire bitcoins to a wealthy long lost relative in another country
18:58:59 <kevinconway> i can't do that without a well signed key
18:59:20 <vipul> kevinconway: they prefer real money i think
18:59:24 <amcrn> vipul: imsplitbit doug_shelley66 and myself mentioned in the chat earlier this morning that we need to sync up next week
18:59:36 <imsplitbit> yeah
18:59:40 <imsplitbit> I'm in
18:59:42 <vipul> amcrn: Ok, sounds good..
18:59:47 <hub_cap> lol kevinconway
18:59:59 <hub_cap> cool on that note
19:00:01 <hub_cap> #endmeeting