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