18:01:33 #startmeeting trove 18:01:34 ha 18:01:34 Meeting started Wed Feb 25 18:01:33 2015 UTC and is due to finish in 60 minutes. The chair is SlickNik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:35 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:38 The meeting name has been set to 'trove' 18:01:39 o/ 18:01:41 ./ 18:01:46 o/ 18:01:46 Hopefully, I have the right channel this time :) 18:01:54 o/ 18:01:54 o/ 18:01:55 o/ 18:01:59 o/ 18:02:05 (H) 18:02:14 o/ 18:02:16 Agenda for the meeting at: 18:02:25 #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting#Agenda_for_February_25_2015 18:02:50 #topic Trove pulse update: 18:03:00 #link https://etherpad.openstack.org/p/trove-pulse-update 18:03:25 Thanks to folks for the reviews. 18:03:59 This week's overall numbers look a lot like last week's. 18:04:19 it seems that all have now picked up the pace at reviews, which is like awesome 18:04:32 o/ 18:04:50 george is late. he buys drinks for all next week. 18:05:13 Still around ~125 reviews a week. 18:05:26 o/ 18:05:28 I've been away this last couple of days, sorry about it 18:05:47 Not meant to point any fingers. 18:05:59 next round on /me 18:06:03 not at all :) 18:06:44 its a good incentive for me! 18:07:04 On average, we've got ~2 changes come in a day, but only ~1 merge per day on average, so we're still in the build phase. 18:07:47 i.e. the number of changes to reviews will have an upward trend. 18:08:05 Don't want to spend too much time on this — we've got a packed agenda. 18:08:17 So I'm going to keep moving unless there are specific questions. 18:08:44 #topic Need reviewers for 157140 18:08:58 #link https://review.openstack.org/#/c/157140/ 18:08:58 goal: to clearly identify stable, and experimental strategies and guest agents (also technical preview for guest agents) 18:08:59 outstanding issues with this review. 18:09:08 should "stable" be called out explicitly. 18:09:12 two points of view 18:09:16 stable should be implicit 18:09:20 stable should be explicit 18:09:24 there's no right answer 18:09:27 let's pick one and roll. 18:09:35 i say make it explicit 18:09:38 I don't see any other major comment on the review. 18:09:45 I agree with the make it explicit theme 18:09:53 we have "explicit" naming for things like OS releases 18:09:58 "Generally Available" 18:09:58 I'm in the first camp for two reasons: 18:10:15 also in the future when something goes stable, we want to be explicit about it 18:10:19 not just "drop experimental" 18:10:32 1. It's implicit in all of the rest of the codebase — trove.taskmanager is not trove.stable.taskmanager 18:10:57 we don't have a notion of a task manager other than stable. 18:11:00 so it is not implicit 18:11:05 it is the only option. 18:11:14 implicit or explicit can only make sense if there is a choice 18:11:18 which there isn't for taskmanager 18:11:37 How about extensions? 18:11:49 Same argument 18:11:52 happy to make those stable and experimental as well 18:12:02 the scope of the blueprint is still open for discussion 18:12:07 happy to add extensions as well 18:12:08 Also another reason: 2. It would help with backwards compatibility, so that the module nomenclature of the stable pieces of the code do not have to change. 18:12:11 if that's the suggestion. 18:12:29 No, the suggestion is to leave things that are stable the way they're currently named. 18:12:35 so, as best as I can tell there is no change that anyone has to make 18:12:44 if they use the default trove config (common/cfg.py) 18:12:48 then it is all taken care of 18:13:06 It kinds of reminds me of something in beta vs not. When you release software you just remove the beta (experimental) off the name 18:13:22 not true edmondk ... You call it "Generally Available" 18:13:46 ? gmail no longer has the name beta next to its name 18:13:53 as an example 18:13:59 it doesn't say Stable Gmail 18:14:13 Trove guest confs would need to changs since the module of the same datastore manager is now different though — "trove.guestagent.datastore.mysql" would change to be "trove.guestagent.datastore.stable.mysql" in that case. 18:14:15 what of operating systems? 18:14:19 alpha, beta, GA? 18:14:39 there is Windows 8 RC, then after that it is just Windows 8 18:14:40 SlickNik, not unless you have a non-default config file 18:15:08 amrith: no I know who deploys trove use a default config file in production. 18:15:12 if you don't use stable then nothing has to change with mysql 18:15:59 A system is created to be stable .... and any experimental work needs to be expilicitly specified that it is experimental ... but a system is just named as a system and not as stable system 18:16:39 so let's decide. 18:16:50 you aren't going to convince me that dropping the name is a better option 18:17:07 I'd say we should assume things not marked as unstable are stable 18:17:49 [vkmc] +1 and thats what we assume today with trove 18:17:55 why not the other way around? things not marked stable are experimental? 18:17:56 whatever we have is stable 18:18:02 after all, we'd like more things to be stable, right? 18:18:13 +1 vote for not using stable 18:18:15 forewarned is forearmed 18:18:48 amrith: Because we're trying to signal what's untested, and not what's tested. 18:19:03 SlickNik, +1 18:19:06 (besides the other couple of reasons above) 18:19:21 so would you like me to move percona and mariadb to experimental? 18:19:37 and thats what we decided at meet that we need to come up with a proposal to make someone understand what is not stable with trove 18:19:42 +1 slicknik 18:19:45 amrith: We don't have a percona / mariadb datastore. 18:19:49 (as yet) 18:19:57 I do in my sandbox 18:20:03 they just import the mysql one 18:20:09 but they sit in an experimental directory 18:20:26 You can mark your sandbox any way you'd like :) 18:20:43 my question was whether you want that change sent for review 18:21:40 we should stick to what is in the code base right now and make new changes go through an experimental period 18:21:44 well, IMO 18:22:55 amrith: Unless that (maria/percona) was added as a separate BP, and we had a test job testing it — I don't think we need to change anything there. 18:23:22 ok, in the interest of time, could I have a decision 18:23:25 drop stable 18:23:26 OK 18:23:28 what else? 18:24:02 Was there anything else you wanted to discuss as part of this topic? 18:24:25 so what is the decision? 18:25:07 what I'm reading is to drop stable, keep experimental, correct? 18:25:16 and technical preview 18:25:30 right 18:25:44 Drop the stable nomenclature, and keep experimental and tech preview — correct. 18:25:48 cool 18:25:51 ok thx 18:25:57 ok, done 18:26:02 #topic Discuss 147908 18:26:24 #link https://review.openstack.org/#/c/147908/ 18:26:34 i believe that is mine? 18:26:57 dougshelley66: yes, go for it 18:27:18 Disclaimer - if we discussed this at mid-cycle and I forgot the discussion, I pre-apologize :) 18:27:36 so you will notice a small novel that I wrote in the review as the last comment 18:27:47 i'm just looking for some guidance on how we want to proceed 18:28:25 i belive my proposal is to allow for a guest to re-render a config.template and have a running guest determine its datadir by querying a db specific conf file or option 18:31:24 i'm trying to avoid going off and doing all the coding only to find out the chosen impl isn't acceptable 18:32:07 * SlickNik thinks about this a bit. 18:32:29 So currently we have a value in the trove-guest.conf that drives the datastore location, right? 18:32:38 not really 18:32:55 it is in multiple placed depending on the datastore 18:33:10 so there is the mount_point - which is supposed to be configurable but really isn't 18:33:27 some datastores (e.g. mysql) have the datadir hardcoded in config.template 18:33:57 so if you change the mount_point you would be in trouble if you didn't change the template 18:34:20 mongodb has a mount_point conf option but overrides it with a hardcoded value 18:34:22 I wonder if it makes more sense to drive the datastore conf based on the guestagent.conf instead of the other way around. 18:36:01 that could make sense - what about the config template? 18:36:06 do the 2 phase rendering? 18:38:11 I'm wondering if that's the only way to achieve this. 18:38:39 We might have to do that if needed. 18:38:52 Not sure I understand the alternatives to this approach though. 18:39:12 we still may have an issue with different guest OS i think 18:39:41 that was my postgresql example 18:40:25 hm, its a tricky one 18:41:15 dougshelley66: Good point. I don't think this is something that we will be able to decide at this meeting. Can we take this offline, discuss the solution, and come up with a proposal to move forward? I can work with you on this one. 18:41:29 sounds good -thx 18:41:38 Thanks dougshelley66! 18:41:53 #topic Discuss 136918 18:42:02 ok ... 18:42:05 #link https://review.openstack.org/#/c/147908/ 18:42:11 SlickNik, in https://review.openstack.org/#/c/136918/, there's a discussion under point #3 of the Guest Agent section. Can you elaborate your comment? See also amrith's comment after yours. 18:42:20 #undo 18:42:20 Removing item from minutes: 18:42:27 I think the whole point of this guest agent separation initiative is to cut the ties between the guest agent and trove core. 18:42:32 #link https://review.openstack.org/#/c/136918/ 18:43:35 And I believe we need to duplicate some trove core code into the guestagent in order to achieve this outcome. 18:43:49 schang: I thought we discussed at the mid-cycle that we didn't want to cut ties and move the guest to a separate repo. 18:44:16 Yes I remember that. 18:44:29 right not a separate repo but a separate module 18:44:37 unless we now don't think that is worth the effort 18:44:44 I think we're just not separating the guest to it's own repo. 18:44:57 schang: One of the purposes was to be able to build the guestagents independently of the rest of the trove server components. 18:45:37 So the common code (common to the guest and the server components) will live in trove/common 18:46:10 when we build the server components, the modules included will be trove.common, trove.taskmanager, trove.conductor, etc. 18:46:37 for the guestagents, the package would look like trove.common, trove.guestagent.* 18:47:28 trove.common might have some libs that are server specific, or guest-specific, and that's okay. 18:47:50 SlickNik, i think that sounds right 18:48:26 That saves us from going down the path of having a troveguest/common and a (potentially) troveserver/common 18:49:06 right that is the copying code thing which we should try to avoid 18:49:47 actually strike my last comment 18:49:55 except the "right" part 18:50:46 #link https://review.openstack.org/#/c/119425/12/troveguest/datastore/mongodb/manager.py,cm 18:51:24 SlickNik, so are you saying we shouldn't turn trove.guestagent into troveguest? 18:51:41 No, we should definitely do that. 18:51:56 is this what's being proposed: 18:52:04 wouldn't we then want to move common to common 18:52:09 up a directory 18:52:12 yes 18:52:31 i assume "from common import operating_system" 18:52:41 or from trovecommon.... 18:52:55 edmondk / dougshelley66: yes 18:53:10 I'd prefer the former — that's what we have today. 18:53:19 so at the top level it would be: 18:53:20 i.e. "from common import operating_system" 18:53:22 common 18:53:23 trove 18:53:25 troveguest 18:53:29 is that correct? 18:53:40 yes. 18:53:43 yes that's what I would assume 18:54:08 ok simon does this make sense 18:54:23 this patch will probably touch almost every file I am guessing 18:54:25 Can we clarify this further offline — there's still a couple of items, and we should move on in the interest of time. 18:54:27 if you move common 18:54:45 edmondk: yes, probably 18:54:56 wondering if there is any way to tackle it besides one giant patch 18:54:58 maybe it could help to set up an etherpad and clarify the structure 18:55:02 possibly not 18:55:06 Just want to make sure wr're on the same page ... 18:55:12 #link https://review.openstack.org/#/c/136918/5/specs/kilo/moving-trove-guestagent.rst 18:55:29 You're talking about the structure I mentioned on the third comment right? 18:55:39 yes 18:56:12 needs to say we will move trove.common up a directory to a stand alone directory common 18:56:13 I also made a comment on the thread ... the last one. 18:56:45 I looked at other projects briefly, and I don;t think I've seen such "common" directory structure. 18:57:21 schang: Let's continue to talk about this after the meeting. 18:57:38 SlickNik: ok 18:57:47 move on to at least touch upon the other topics for now. 18:57:52 #topic Trove Liberty Mid Cycle Sprint -- Initial planning 18:58:04 #link http://doodle.com/candscrt36hg38a7 18:58:14 I requested that SlickNik 18:58:20 was wondering when we could close the poll 18:58:48 amrith wanted to have at least a good majority of folks voting on the poll before I close it. 18:58:54 not a lot of people have voted yet ... 18:59:37 maybe everyone here could do it now? 18:59:39 So folks, please vote on which week in Aug works best for the Trove Liberty Mid-Cycle sprint 19:00:12 peterstac: +1 that or soon after the meeting. 19:00:14 so, I would like to plan some things around that date 19:00:26 and would like to know when you feel that we can close the poll 19:01:16 Hoping to close it by next week, so that I can follow up on location as well. 19:01:26 ok, thanks 19:01:28 let's move on 19:01:45 #topic Needed reviewers for Vertica work 19:01:56 Thats mine 19:02:15 I just wanted to request everyone to review the vertica work 19:02:16 :) 19:03:02 so if someone wanted actually run this code to review, is that possible 19:03:18 and are there instructions showing how to do that 19:03:51 Okay, sushilkm but in general I'd prefer not to add agenda items for just reviews — it makes sense if there's a discussion regarding the reviews that needs visibility. 19:04:13 * SlickNik is afraid that meetings will turn into "please review patch X" 19:04:31 SlickNik, +1 19:04:44 point taken ... 19:05:04 We're running overtime — let's take any discussion in progress to #openstack-trove. 19:05:11 All, I've pushed a new patchset with no 'stable' qualifier. Please review https://review.openstack.org/#/c/157140/ 19:05:12 #endmeeting