18:00:50 <cp16net> #startmeeting trove
18:00:51 <openstack> Meeting started Wed Dec  9 18:00:50 2015 UTC and is due to finish in 60 minutes.  The chair is cp16net. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:54 <openstack> The meeting name has been set to 'trove'
18:01:15 <cp16net> #topic roll call
18:01:49 <vkmc> o/
18:01:54 <tellesnobrega> o/
18:02:03 <bhaskarduvvuri> o/
18:02:18 <imandhan> o/
18:02:58 <vgnbkr> o/
18:04:56 <cp16net> alright lets get this party started
18:05:19 <cp16net> #topic pulse update
18:05:24 <cp16net> #link https://etherpad.openstack.org/p/trove-pulse-update
18:05:32 <cp16net> #link http://bit.ly/1VQyg00
18:05:52 <cp16net> maybe i shouldnt include the etherpad if we are not using it any more
18:07:51 <cp16net> i added another table with 2 more charts because i was interested in seeing the reviewers stats and how many patches were waiting
18:08:46 <cp16net> overall i see we got more reviews than last week
18:08:54 <cp16net> more stuff merged which was great
18:10:24 <cp16net> any other comments on the pulse
18:11:11 <cp16net> alright moving along...
18:11:21 <cp16net> #topic past action items
18:12:01 <cp16net> I pushed out the final reno patches but it looks like there is an issue with the liberty branch patch
18:12:05 <cp16net> i'll need to update that
18:13:06 <cp16net> i looked over the client changes for kilo and liberty and they look fine for now
18:13:10 <pmalik> ./
18:14:29 <cp16net> tellesnobrega: after getting more info on the removing downgrades i think it was a good idea to move forward with that unless there are other opinions about that
18:15:18 <tellesnobrega> cp16net, i dicussed a bit with flavio percoco, he suggested marking with deprecation and removing it in N
18:15:44 <tellesnobrega> kinda following a deprecation protocol
18:15:52 <tellesnobrega> but it is up to us to decide here
18:15:57 <tellesnobrega> cp16net, what do you think?
18:16:10 <cp16net> ahh yeah thats probably a good idea
18:16:34 <cp16net> making a note that it will be depricated soon
18:17:01 <tellesnobrega> great, so I can move with that if its ok with everyone
18:17:55 <cp16net> looks like its a plan!
18:18:24 <cp16net> ok so moving on to the next topic
18:18:38 <cp16net> #topic spec approvals by end of week
18:18:55 <cp16net> #link https://review.openstack.org/#/q/status:open+project:openstack/trove-specs,n,z
18:19:04 <cp16net> there are 3 specs up for review
18:19:42 <cp16net> i thought vkmc mentioned another others that needed to be added
18:20:20 <vkmc> yes
18:20:33 <vkmc> I just come from a couple of holidays, will catch up with those soon
18:20:53 <cp16net> last week i mentioned that it would be great to get the specs approved by Dec 11th
18:21:13 <vkmc> I remember yes
18:21:30 <tellesnobrega> we are working to have it up asap
18:21:33 <cp16net> vkmc: no worries just want to remind everyone
18:21:38 <vkmc> +1
18:22:34 <cp16net> if everyone could look them over so we can get them approved and updated by the end of the week that would be great
18:23:01 <cp16net> i'll follow up with saurabh on the floating ip patch
18:23:18 <cp16net> make sure he knows
18:23:27 <atomic77> it's great that we're down to only three. just this PXC spec makes me wonder though...
18:23:36 <atomic77> ;) j/k
18:23:42 <imandhan> lol
18:23:46 <cp16net> atomic77: you're so funny
18:23:51 <cp16net> :-P
18:24:00 <atomic77> hehe well a true leader stays till the end - it's honorable
18:24:08 <amrith> ./
18:24:12 <cp16net> :)
18:25:32 <cp16net> alright moving along then
18:25:33 <atomic77> seriously though, i think we're in fairly good shape as long as the remaining specs get pushed up soon
18:26:02 <cp16net> atomic77: i agree thanks to everyone for helping with these!
18:26:07 <amrith> vkmc, what are the new specs about?
18:26:53 <vkmc> amrith, mariadb10 gtid replication strategy, galera cluster impl and ceph backups strategy
18:27:27 <cp16net> vkmc: so galera with community mysql?
18:27:44 <dougshelley66> cp16net i assume mariadb
18:27:56 <cp16net> or mariadb?
18:27:59 <vkmc> cp16net, mariadb
18:28:14 <cp16net> gotcha
18:28:18 <vkmc> +1
18:28:38 <cp16net> sounds great
18:28:59 <cp16net> ok thanks let move to the next topic
18:29:03 <cp16net> #topic define experimental datastores
18:29:39 <cp16net> so i had a discussion with a few members of the team in the trove channel late last week
18:29:56 <cp16net> and want to bring this up to the rest of the community and get more input on it
18:30:24 <cp16net> so we have a ton of datastores
18:30:36 <cp16net> but only mysql is "stable"
18:30:43 <cp16net> everything else is in experimental
18:31:15 <cp16net> the reason they are experimental is that they are not fully ci tested
18:31:52 <cp16net> with the new testing framework there is progress coming along here that is awesome
18:32:41 <cp16net> but there are other factors that play into how we treat experimental datastores
18:33:43 <cp16net> i know some of these experimental datastores are used and have been used in environments for quite sometime
18:34:16 <amrith> so maybe it is time to upgrade them to 'technical preview'.
18:34:17 <amrith> https://github.com/openstack/trove-specs/blob/master/specs/kilo/experimental-datastores.rst
18:35:10 <cp16net> amrith: i think i must have missed that spec...
18:35:31 <amrith> it was in kilo ... maybe you weren't working on trove at that time ;)
18:35:59 <cp16net> thats possible
18:36:10 <amrith> newbie ...
18:36:17 <cp16net> but scanning over this spec i still see something missing
18:37:06 <cp16net> do we treat experimental/techincal preview datastores differently than stable ones wrt securty issues that are found
18:37:23 <cp16net> i've heard 2 sides to this arguement
18:37:52 <cp16net> side 1 says they are experimental and should be treated as such with risk taken
18:38:27 <cp16net> side 2 says any code that is shipped should be treated the same
18:39:53 <cp16net> talking with some others mentioned that input from the trove community would be great
18:40:07 <amrith> so, our rationale behind the matrix was more to reflect the level of testing.
18:40:11 <dougshelley66> i'm not completely clear those 2 sides are mutually exclusive
18:40:28 <amrith> therefore, I think it would really come down to the impact of the issue at hand.
18:40:53 <amrith> if it is something that is egregious and impacts the use by someone, we should at least consider it for fixing in an experimental release.
18:41:05 <amrith> and whether we do it or not would likely be on a case-by-case basis.
18:41:13 <amrith> I wouldn't be opposed to such a fix.
18:41:26 <amrith> but I'm unclear what the question is that you are asking cp16net
18:41:35 <vgnbkr> Then what about egregious issues that aren't security issues?  Should they be backported as well?
18:41:49 <amrith> are you asking whether we should be considering fixing security issues in experimental datastores
18:41:58 <amrith> or is the issue about backporting that vgnbkr just mentioned?
18:41:59 <atomic77> i'd agree with amrith: stable -- fixes released, the rest -- case-by-case
18:42:47 <atomic77> vgnbkr, i think the answer there should be: upgrade
18:43:04 <cp16net> if a security issue for an experimental datastore should we follow the openstack security patch flow
18:43:09 <amrith> Let me be more prescriptive; I think we should triage each bug (security or otherwise) identically and irrespective of whether or not the datastore is experimental or not.
18:43:18 <vgnbkr> atomic77, I believe we're talking about backporting fixes to the previous release - there's nothing to upgrade to.
18:43:18 <amrith> cp16net, I think so, YES.
18:43:25 <amrith> categorically and emphatically so.
18:43:28 <cp16net> and then should they be backported as well
18:44:12 <amrith> Yes, absolutely.
18:44:33 <vgnbkr> But without ci, don't we take the risk of backporting a fix and then breaking code that was otherwise working?
18:44:34 <amrith> it is not our intention (I believe) to imply support or lack thereof from the community.
18:44:45 <amrith> merely to reflect our indication of whether something had a full CI or not.
18:44:59 <cp16net> i'm in agreement amrith. i think its better to be on the safe side when dealing with issues
18:45:00 <amrith> vgnbkr, we run that risk even without backporting.
18:45:14 <amrith> in the current release, fixing something without a full CI could mean we break something.
18:45:29 <amrith> I would submit to you that we should treat backporting and fixing in two independent conversations.
18:45:42 <amrith> however, I believe that in either case, I would advocate the same behavior.
18:45:48 <amrith> the risks are largely identical.
18:45:56 <cp16net> ok we can move backporting to the next topic then
18:45:58 <amrith> sorry, largely identical is stupid. Largely similar.
18:46:06 <vgnbkr> amrith, how?  What I'm suggesting is that a user would have implemented a datastore, it worked for them, we tell them to apply a patch, then it breaks.
18:46:46 <amrith> I would assume vgnbkr that if one implemented a fix, one would implement some unit testing and the community (including potentially the original person who implemented the datastore) would review the change.
18:47:08 <amrith> the situation is identical even IF we had a full CI, you are describing a test escape.
18:47:19 <amrith> we don't imply that 'stable' means 'zero test escapes'.
18:47:28 <amrith> it merely means 'more testing than 0'
18:47:41 <amrith> actually, 'more testing than ~0'
18:48:16 <cp16net> yeah i mean we fix an issue and others are found down the road thats normal
18:48:48 <amrith> cp16net, yes. While we would like to take steps to prevent it, regressions are a fact of life. Like the flu ...
18:49:49 <cp16net> but i feel that since the code is there its better to make sure we are diligent with patching any issues for stable releases
18:50:16 <cp16net> amrith: yea that is true
18:50:42 <cp16net> i rhymed :-P
18:51:16 <cp16net> anyone else have a thought about this?
18:51:32 <dougshelley66> cp16net - do you have a specific proposal?
18:51:44 <amrith> cp16net, vgnbkr, you and I seem to be the only ones talking. So may I suggest that you tell us what the specific proposal is (and then we say yes and move on ;))
18:51:51 <amrith> or not ...
18:52:04 <atomic77> the rest of us backed off already ;)
18:52:18 <amrith> I'm guessing you have thought about this and have a promising solution
18:52:21 <cp16net> So the proposal that i see makes the most sense is
18:53:10 <cp16net> the side 2 where we shipped code stable/preview/experimental and we treat them all the same for security related issues that are found
18:54:00 <atomic77> perhaps it makes sense to put this to a vote next week or at some point in the future?
18:54:24 <cp16net> i was just thinking about doing that now...
18:54:39 <cp16net> trying to figure out the startvote context
18:54:52 <atomic77> i thought that at least we could have a bit of time to present arguments for each side
18:55:28 <cp16net> #startvote Should we vote now? Yes, No, Maybe
18:55:28 <openstack> Begin voting on: Should we vote now? Valid vote options are Yes, No, Maybe.
18:55:29 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:55:43 <atomic77> #vote Maybe
18:55:57 <vkmc> #vote yes
18:56:05 * amrith thinks ... looking for additional input
18:56:05 <cp16net> #vote yes
18:56:06 <amrith> 1 second
18:56:58 <cp16net> #showvote
18:56:59 <openstack> Maybe (1): atomic77
18:57:00 <openstack> Yes (2): vkmc, cp16net
18:57:18 <dougshelley66> what is "Maybe"
18:57:24 <cp16net> well its getting close to the end of the meeting
18:57:28 * atomic77 sees a crisis of democracy
18:57:33 <dougshelley66> #vote yes
18:58:13 * amrith thinks
18:58:29 <amrith> #vote yes
18:58:32 <cp16net> #endvote
18:58:32 <amrith> #endvote
18:58:33 <openstack> Voted on "Should we vote now?" Results are
18:58:34 <openstack> Maybe (1): atomic77
18:58:35 <openstack> Yes (4): amrith, dougshelley66, vkmc, cp16net
18:58:53 <atomic77> #vote yes
18:59:01 <atomic77> too late i guess :)
18:59:18 <cp16net> #startvote should we security issues the same across all datastore? Yes, No, Maybe
18:59:19 <openstack> Begin voting on: should we security issues the same across all datastore? Valid vote options are Yes, No, Maybe.
18:59:20 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
19:00:10 * amrith explains what happened
19:00:21 <amrith> the vote we just had was to decide whether we should vote now or not.
19:00:30 <amrith> by a margin of 5 to 0 we decided to vote now.
19:00:35 <amrith> Now we vote on the real question.
19:00:45 <dougshelley66> but i l already used my 1 yes vote
19:00:47 <amrith> Robert's Rules, Motion to move the question passed 5-0
19:00:53 <amrith> now we move the question.
19:00:57 <amrith> and vote
19:01:01 * amrith ends explanation
19:01:04 <amrith> #vote yes
19:01:08 <cp16net> #vote yes
19:01:10 <amrith> #showvote
19:01:10 <openstack> Yes (2): amrith, cp16net
19:01:13 <atomic77> #vote yes
19:01:26 <mvandijk> #vote yes
19:01:32 <pmalik> #vote yes
19:01:56 <cp16net> closing votes in a min
19:02:04 <vkmc> #yes
19:02:15 <cp16net> vkmc: use #vote yes
19:02:17 <vkmc> ouch
19:02:17 <vkmc> #vote yes
19:02:36 <cp16net> closing....
19:02:48 <cp16net> #endvote
19:02:48 <openstack> Voted on "should we security issues the same across all datastore?" Results are
19:02:49 <openstack> Yes (6): pmalik, vkmc, amrith, atomic77, cp16net, mvandijk
19:03:01 <cp16net> ok thanks everyone for your input
19:03:08 <cp16net> #endmeeting