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