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