20:00:25 <grapex> #startmeeting trove
20:00:26 <openstack> Meeting started Wed Oct 16 20:00:25 2013 UTC and is due to finish in 60 minutes.  The chair is grapex. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:28 <grapex> o/
20:00:30 <openstack> The meeting name has been set to 'trove'
20:00:37 <vipul> \o
20:00:38 <juice> o/
20:00:40 <grapex> #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting#Agenda_for_the_next_meeting
20:00:43 <robertmyers> o/
20:00:56 <datsun180b> hello
20:00:59 <juice> _o/
20:01:03 <SlickNik> here
20:01:12 <grapex> Agenda looks a tad sparse on the wiki!
20:01:14 <pdmars> o/
20:01:19 <redthrux> o/
20:01:23 <grapex> #topic Action Items
20:01:29 <grapex> #link http://eavesdrop.openstack.org/meetings/trove/2013/trove.2013-10-09-20.00.html
20:01:35 <grapex> 1. SlickNik to check with other teams to set groups permissions correctly on LaunchPad
20:01:47 <SlickNik> So I checked with others on openstack-infra
20:01:51 <dmakogon> o/
20:02:05 <esp> o/
20:02:12 <SlickNik> And it seems like the permissions for the bp's are set up exactly the way they are in the other groups.
20:02:26 <SlickNik> There's only a subset of fields that are editable by everybody.
20:02:38 <esmute> o/
20:03:03 <SlickNik> And only members of the *-drivers group are allowed to edit _all_ fields for blueprints.
20:03:27 <SlickNik> So there's really not any work for us that needs to be done for this action item.
20:03:53 <grapex> SlickNik: Cool
20:04:04 <grapex> Who brought this up last time? Was it dmakogon?
20:04:11 <SlickNik> I hope that's not going to be an issue for most folks.
20:04:13 <grapex> Maybe we just need to make sure people are in the Drivers group
20:04:22 <SlickNik> I'm not sure. It was brought up by multiple people.
20:04:37 <SlickNik> And there was confusion around it.
20:04:47 <grapex> Ok, if anyone brings it up we'll just remember to ask them to join the drivers group on launchpad.
20:04:52 <grapex> #link https://launchpad.net/~trove-drivers/+members#active
20:04:55 <grapex> Cool.
20:04:55 <SlickNik> Sounds good.
20:04:58 <SlickNik> Thanks grapex.
20:05:09 <grapex> SlickNik: Thank you for sorting that out!
20:05:11 <grapex> Moving on...
20:05:13 <grapex> 2. Fix bug with DELETE to allow instances in BUILDING_ERROR_DNS state to be deleted.
20:05:27 <grapex> I'll take this one
20:06:22 <grapex> Actually, I think dmakogon fixed this?
20:06:34 <grapex> n/m, that was something else
20:06:49 <dmakogon> no, this was not me
20:06:53 <grapex> To reiterate, this issue was related to redthrux / dmakogon's discussion around resources last time. In the end we agreed that there was a seperate bug in DNS. No one has worked on it I guess.
20:07:07 <grapex> #action grapex to fix issue where instances in BUILDING_ERROR_DNS cannot be deleted.
20:07:26 <SlickNik> thanks for the re-action, grapex.
20:07:27 <dmakogon> grapex: we could fix it, quickly
20:07:38 <grapex> dmakogon: Agreed
20:07:49 <grapex> SlickNik: I'll try to actually get to this by next meeting, I swear. :)
20:07:55 <grapex> Ok, agenda items.
20:07:57 <dmakogon> even we should
20:08:07 <grapex> #topic Conductor changes. (datsun180b)
20:08:08 <datsun180b> #link https://review.openstack.org/#/c/45116/
20:08:17 <kevinconway> datsun180b: do you have an update on conductor?
20:08:37 <datsun180b> Thanks for helping get the devstack and integration pieces merged. This is the last piece, the actual conductor
20:09:12 <SlickNik> nice work on the devstack pieces, datsun180b
20:09:14 <datsun180b> Once the auto job is happy please look at it--it changes the way guest agents communicate their status--no more talking directly to the DB
20:09:24 <dmakogon> datsun180b, nicely done
20:09:38 <vipul> awesome
20:09:39 <redthrux> datsun180b: +++
20:09:43 <datsun180b> Once it's merged you will probably have to update your own GAs if you haven't already been cribbing from my notes
20:10:03 <grapex> datsun180b: That should really help, the direct DB access by the agent is easily one of the most disliked features of the current architecture.
20:10:24 <SlickNik> datsun180b: Haven't had a chance to look at the patch yet; will review it when I get a chance and take it for a spin on devstack. :)
20:10:24 <datsun180b> That's all I've got about conductor for now.
20:10:31 <vipul> datsun180b: so are we at a point where we can remove the sql_connection string from conf?
20:10:41 <datsun180b> wakaranai
20:10:48 <datsun180b> but probably
20:10:54 <vipul> I imagine for some things, we still need to talk to the DB? maybe backups
20:11:00 <kevinconway> instead of conductor the guest could keep a local sqlite db
20:11:04 <kevinconway> and rsync it back sometimes
20:11:55 <vipul> anyway, so my question is.. do we need to address any other palces that require db access in this patch?
20:12:03 <vipul> or do you envision that as separate things
20:12:03 * grapex hits kevinconway with a rusty fish or something
20:12:18 <kevinconway> i would go ahead with this patch and let the rest be additional reviews
20:12:21 <datsun180b> i've had kind of a narrow focus, i don't know that i can answer that confidently
20:12:22 <grapex> Sorry I don't know what trick hub_cap does to make those phrases appear so I had to improvise.
20:12:44 <vipul> ok works for me
20:12:48 <grapex> By the way, hub_cap is traveling today if anyone was curious. Sorry I didn't announce that at the start.
20:12:49 <kevinconway> grapex: slash slap i think
20:12:53 <datsun180b> there's probably other components to wean off the db, but that's for additional conductor methods probably
20:13:22 <robertmyers> baby steps :)
20:13:27 <dmakogon> could we make trove-api talk to conductor ?
20:13:39 <datsun180b> dmakogon: that's planned in future phases
20:13:39 <vipul> why would you need to?
20:14:08 <grapex> Ok. But if the backups feature still uses the db it means we have to run conductor w/o the benefits of denying the guest db access.
20:14:31 <datsun180b> one plan is for conductor to be the source of truth for guest statuses
20:14:32 <grapex> dmakogon: The trove-api usually just uses rpc calls to the agent so there's already no db access from there. Anything else goes through task manager.
20:14:37 <kevinconway> can't we merge this review and then open another BP or defect for it?
20:15:10 <dmakogon> grapex, trove-api still writes some data into database, should it be moved to taskmanager ?
20:15:17 <vipul> kevinconway: i'm fine with doing that.. but there should be a use_conductor flag..
20:15:35 <grapex> dmakogon: Ah, you mean trove-api in general talking to the infrastructure db? I guess I don't understand.
20:15:39 <datsun180b> vipul: that's ENABLED_SERVICES in localrc
20:15:53 <grapex> Honestly, I think maybe the existing conductor pull request should wait until the backup feature also uses it.
20:16:03 <grapex> IIRC that is the only remaining place where the database is used.
20:16:05 <datsun180b> of course that won't prevent the guestagent from trying to put messages on a q
20:16:06 <dmakogon> grapex, to make api only transform calls from http to rpc
20:16:46 <dmakogon> have any one thought about getting rid of rpc at all ?
20:17:07 <kevinconway> dmakogon: we can switch to Node.js and use HTTP requests for everything
20:17:08 <datsun180b> i don't think that argument is within the scope of the implementation of a new rpc-consuming service
20:17:11 <vipul> hub_cap mentioned protobuff dmakogon
20:17:23 <SlickNik> dmakogon: there was some thought of moving to protobuffers, but we didn't discuss it yet.
20:17:24 <grapex> dmakogon: The idea of conductor is the rpc stuff should be swappable, and allow for other implementations.
20:17:43 <dmakogon> http would be preferable
20:17:51 <dmakogon> easy to redirect
20:17:59 <vipul> Hmm.. how do you do async things
20:18:00 <dmakogon> easy to handle
20:18:01 <redthrux> dmakogon: can we shelve that?
20:18:06 <vipul> redthrux: +1
20:18:14 <grapex> dmakogon: I agree. I think future iterations of conductor could support that.
20:18:16 <SlickNik> That's a whole another discussion, +1 to shelving it.
20:18:25 <dmakogon> redthrux, yes
20:18:33 <grapex> Ok, let's move on.
20:18:37 <vipul> ok grapex your call
20:18:44 <vipul> wait for backups to use conductor or not
20:19:57 <grapex> #action datsun180b to add backup status updates to conductor
20:20:04 <datsun180b> booo, i've been done for a month
20:20:05 <grapex> #topic Fake mode daemon fix, how to use it. (grapex)
20:20:19 <grapex> I'll be honest guys, I put this on here because the wiki looked skinny.
20:20:28 <grapex> Are we sure it didn't get vandalized? :)
20:20:40 <redthrux> grapex: you are so image-driven
20:20:43 <grapex> Anyway, I have a tiny pull request sitting on gerrit right now that fixes the daemon version of fake mode
20:20:43 <redthrux> :P
20:20:55 <grapex> #link https://review.openstack.org/#/c/51262/
20:21:24 <grapex> Just wanted to take a brief moment to explain how this works. Essentially you can run trove-api in fake mode which makes it possible to experiment with API changes and other features.
20:21:36 <grapex> You can, for example, allow an external team to hit an API and see how it reacts.
20:22:13 <grapex> Anyway, just my PSA on this feature. I know a few of you have used it when testing the XML version of some API calls.
20:22:17 <grapex> That's all. :)
20:22:25 <vipul> do you guys run it often?
20:22:43 <grapex> vipul: All the time.
20:22:48 <datsun180b> before we submit code, and a dozen times before then
20:23:15 <vipul> Ok.. yea we have not yet run it
20:23:23 <grapex> Anyway, if anyone's curious hit me up after the meeting. Moving on...
20:23:25 <grapex> #topic Tempest for integration tests. (SnowDust)
20:23:41 <dmakogon> wow
20:23:44 <dmakogon> tempest
20:23:54 <dmakogon> i thought this question is closed
20:23:55 <SlickNik> SnowDust, around?
20:23:57 <grapex> I know hub_cap is working on this. I haven't heard any updates from him recently so I'm not sure what news to report here.
20:24:25 <SlickNik> Same here.
20:24:30 <dmakogon> hub_cap said "wait until trove tempest framework would be finished"
20:24:45 <grapex> SnowDust isn't in attendance so I guess we can move on.
20:24:46 <vipul> there was some discussion about what creates the guest images
20:25:02 <vipul> anyone know how that works w/tempest?
20:25:27 <dmakogon> nope
20:25:33 <grapex> vipul: Test resources probably
20:25:47 <grapex> vipul: Just speculation is all we have for now though. Let's move on...
20:26:02 <SlickNik> There was a discussion we had with clarkb where we decided that we'd have a devstack? job that creates a vetted disk-image and publishes it on o.o somewhere.
20:26:31 <SlickNik> The tempest job can then use these pre-created disk-images so they don't have to build one _every_ time
20:27:00 <SlickNik> That's just a heads up. Things are still in flux, so I'd move on until we have more details.
20:27:04 <vipul> ok cool
20:27:05 <grapex> SlickNik: I'm a bit confused about the philosophy of where things get created. hub_cap has been telling me that users will be created now from within the Tempest test themselves. I guess I'm curious as what the cut off point is for an expensive resource where you can no longer put it in Tempest.
20:27:28 <grapex> Should probably just wait until hub_cap returns. Sorry for the tangent, lets move on.
20:27:29 <grapex> #topic open discussion
20:27:44 <dmakogon> could i take a word ?
20:27:51 <SlickNik> grapex: I'm not sure. Let's discuss when hub_cap get's back.
20:27:58 <grapex> dmakogon: Sure.
20:27:59 <SlickNik> Sure, dmakogon go for it.
20:28:17 <dmakogon> https://review.openstack.org/#/c/45116/ - i'd like everyone take a look at this refactoring
20:28:33 <vipul> conductor?
20:28:33 <dmakogon> it is really significant for future GA development
20:28:35 <dmakogon> no
20:28:40 <datsun180b> probably copy/paste mistake
20:28:41 <kevinconway> +1 dmakogon
20:28:47 <kevinconway> great work
20:28:49 <dmakogon> https://review.openstack.org/#/c/50686/
20:28:58 <dmakogon> yes, sorry
20:29:41 <dmakogon> i know that some of you discussed how to call database it trove terms
20:30:08 <dmakogon> so you came into suggestion with "datastrore" term
20:30:11 <vipul> cool dmakogon we did need this reorg to support other types
20:30:36 <redthrux> yeah i thought it was very useful dmakogon
20:30:42 <dmakogon> yes
20:30:49 <dmakogon> this review is a big cake peace
20:31:10 <dmakogon> there a still some improvements need to be done
20:31:47 <SlickNik> I think it still needs some improvements, dmakogon. Will review and put up some comments in a bit.
20:31:53 <vipul> I did want to ask regarding the 'datastore' term... did we also decide on 'datastore_version" or just 'version'
20:31:53 <dmakogon> step-by-stem we coming to more and more flexible guestagent
20:31:56 <grapex> dmakogon: Maybe this is too specific for the meeting
20:32:32 <dmakogon> we are in Open Discussions
20:32:38 <grapex> It might be easier to discuss over the mailing list.
20:33:07 <esmute> i want to get your input on something guys.
20:33:09 <esmute> grapex, dmakogon: what is the status of this https://review.openstack.org/#/c/45708/?
20:33:32 <esmute> i know there has been some talk aobut not implementing this because future heat implementation will take care of it
20:33:34 <dmakogon> esmute, grapex should re-review it
20:33:46 <dmakogon> esmute, yes
20:33:48 <esmute> but part of this fix also fixes a quota issue.. So we need it
20:34:01 <grapex> esmute: I'll try to look at that review soon.
20:34:19 <esmute> this patch has been under review for a long time.
20:34:31 <dmakogon> esmute, yes =(
20:34:35 <grapex> Sorry, things here have been pretty hectic lately, but I should have more time for reviews soon. I understand your frustration.
20:34:43 <esmute> and i would like to get it merged.
20:34:44 <SlickNik> esmute / dmakogon: If there's some contention regarding the security groups review, perhaps we should break the quota fix out into a different patch?
20:34:45 <vipul> yea we need to get better reviewing overall .. myself included
20:35:12 <SlickNik> +1 to better reviewing.
20:35:36 <esmute> grapex: Currently it was a -2 from you. So i think that is preventing others to even look at it
20:35:50 <dmakogon> SlickNik: i thinks it should stay together for avoiding new bugs(maybe)
20:36:01 <datsun180b> i want to mention that a negative vote on a review from -core doesn't mean you can't look at something too
20:36:26 <kevinconway> datsun180b: but it hurts our karma to vote against them doesn't it?
20:36:31 <datsun180b> i know i've fallen way behind in reviews
20:36:53 <SlickNik> kevinconway: no it doesn't.
20:36:55 <esmute> datsun180b: i think that discourage devs to look at it. At least, if i see a -2, i wont use my time to look at it and rather look at other reviews
20:37:14 <kevinconway> oh… well then how do i lower my karma?
20:37:29 <dmakogon> datsun180b: i've got question
20:37:45 <dmakogon> datsun180b: about conductor heartbeat
20:37:57 <SlickNik> kevinconway: schedule meetings at 6 a.m. :)
20:38:05 <dmakogon> datsun180b: why does you hardcode mysql as service type ?
20:38:06 <datsun180b> is it already open discussion time?
20:38:08 <kevinconway> SlickNik: done!
20:38:17 <datsun180b> dmakogon: because i'd originally built a mysql guest agent
20:38:25 <datsun180b> please mention it in the reive
20:38:29 <datsun180b> review
20:38:31 <dmakogon> use CONF.service_type
20:38:40 <grapex> Yeah, -2's do make it so people skip past reviews and don't look at them, which isn't cool. If I -2 something though its because I spent awhile looking at it and have a serious concern- I don't do it lightly. Please just try to contact me directly if you've updated something I reviewed negatively and I'll try to get to it before I look at other stuff.
20:38:40 <datsun180b> okay
20:39:16 <dmakogon> datsun180b, but you've done great work
20:39:22 <dmakogon> datsun180b, <3
20:41:31 <grapex> Does anyone else have something they want to bring up?
20:42:07 <dmakogon> i suppose we could end
20:42:33 <vipul> good here
20:42:38 <SlickNik> good by me
20:42:44 <grapex> #endmeeting