18:00:20 #startmeeting trove 18:00:21 Meeting started Wed Jul 6 18:00:20 2016 UTC and is due to finish in 60 minutes. The chair is amrith. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:22 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:24 The meeting name has been set to 'trove' 18:01:10 anyone here for the trove meeting ... 18:01:45 ./ 18:01:50 hi matt 18:01:55 o/ 18:02:44 😁/ 18:02:54 hi petr, simon 18:03:06 haven't heard from mariam today; peter is traveling 18:03:16 o/ 18:03:19 right; peter is traveling correct? 18:03:23 hi trevormc 18:03:24 yes 18:03:40 #agenda https://wiki.openstack.org/wiki/Meetings/TroveMeeting 18:03:50 I heard him mention his wife putting a quota on his work time while on vacation. 18:04:08 quite a list of things here ... 18:04:23 #topic Action items from last week's meeting 18:04:34 - none that I can recall (we didn't have a meeting) 18:04:41 #topic Trove pulse update 18:04:48 #link http://bit.ly/1VQyg00 18:05:05 #link https://gist.github.com/amrith/c76d4af85922728d5fdebcdbe77e3559 18:05:15 the reviews last week were a bit lower than previous weeks 18:05:24 may have had something to do with the holiday 18:06:08 there are a fair number of changes that need attention from the submitter 18:06:11 everyone was getting in on the canada day celebrations 18:06:34 mvandijk, isn't that next week? 18:06:38 canada day that is? 18:07:28 so please take a look at open reviews and if there are any of your changes in merge conflict, please update them 18:07:52 anyone have anything else to add? 18:08:17 #topic Call for topics for mid-cycle 18:08:24 it will be a virtual midcycle 18:08:32 etherpad is at https://etherpad.openstack.org/p/newton-trove-midcycle 18:08:34 #link https://etherpad.openstack.org/p/newton-trove-midcycle 18:08:43 please propose topics that you would like discussed there 18:08:56 Date and Time: 4hours each day, July 26, 27 and 28; 1300-1700 EDT 18:08:57 (1200 - 1600 CDT, 1000 to 1400 PDT, 1700 to 2100 UTC) 18:08:57 Location: Virtual midcycle, [likely] Google Hangouts with audio dial in(telephone) 18:09:27 Not much else to add about that; mid-cycle is just over 3 weeks away 18:09:40 #topic Announcements 18:09:44 A couple of quick ones 18:09:51 Next week is the N-2 milestone 18:10:00 All specs for Newton must be approved by the end of the week 18:10:08 I will be cutting beta release for Trove on master and mitaka branches (I don't think anything significant went into liberty branch) 18:10:18 There are some specs that I'd like to review as the next item on the agenda 18:10:45 #topic Specs that are up for review 18:10:54 The following three specs appear ready to merge. If there are no objections, I will approve these three by midweek next week. 18:10:54 332885 Quota Update 18:10:54 329510 Scheduled Backup Specification 18:10:54 327355 Add configuration group management for DB2 18:11:06 Anyone have concerns or questions about these? 18:11:45 For Scheduled Backups, it's failing due to the py27 check complaining about a line that is too long, but it needs to be that long. 18:13:15 for the purposes of the spec can you line wrap it? 18:13:19 the spec won't merge that way 18:13:38 or abbreviate the line and just put in "..." and explain it? 18:14:24 It's not text - it's showing what's in a mistral script. I can just take the whole script out, I guess. 18:14:24 sorry amrith for joining late (had some trouble joining the channel) 18:14:37 #action vgnbkr to figure some way of updating the spec to get the check/gate jobs to pass; maybe simplify the script 18:14:40 hi johnma 18:14:53 Hi Amrith 18:15:04 even if it is merely to wrap lines and make an explanation about it somewhere 18:15:28 OK, I'll just take it out. 18:15:35 ok 18:15:43 also some minor whitespace issues in the spec 18:15:55 hopefully you can have it up soon. I'm taking the code out for a spin 18:15:58 to see how it works out 18:16:01 mistral and all that 18:16:18 will you be updating redstack to install mistral? 18:17:10 vgnbkr ^^ 18:17:41 johnma, some comments on the db2 configuraiton group spec 18:17:46 https://review.openstack.org/#/c/327355 18:17:52 It should already be done - just ENABLE_MISTRAL=true when you run 'redstack install" 18:18:06 ok, will try that out vgnbkr 18:18:30 o/ sorry running late this morning 18:18:33 yes Amrith, I need to update that. I have that almost cleaned up on my dev env. Will complete it and post one for review by today 18:18:37 hi SlickNik 18:18:43 thanks johnma 18:18:50 SlickNik, thanks for all the reviews last night 18:19:03 you were up quite late; or should I say early? 18:19:17 unfortunately it looks like some specs won't make it in time for newton 18:19:30 superconductor, api versioning, ... 18:19:41 I'm going to try and get the existing trove-image-builder thing done 18:19:48 but redstack is a beast 18:20:02 that's all I have on that topic; anyone else have something to add ... 18:20:10 ++ 18:20:41 ok, moving along ... 18:20:47 #topic Proposals for review 18:20:59 I'd like to quickly dispose of (one way or the other) some of these 18:21:06 #link https://review.openstack.org/#/c/334813/ 18:21:26 the submitter abandoned the change. I don't feel strongly about it. if anyone thinks the change is worthwhile, let's take it. 18:21:37 #link https://review.openstack.org/#/c/338091/ 18:21:47 needs a gracious core reviewer to kick this over the line 18:21:58 trevormc suggested a change and I've made that change 18:22:01 should be good to go 18:22:19 * amrith hopes no one will -1 it because of the typo in the commit message 18:22:33 that is ironic 18:22:33 #link https://review.openstack.org/#/c/338030/ 18:23:18 I'm not sure about this one. While the change appears to be a good idea, what we have is a specific case of a much broader change; I would rather we treat this change as such and identify how we can improve validation of a number of different types like config files, host names, IP's ... 18:23:23 or should we just take this as is 18:23:27 please post comments in the spec 18:23:31 sorry, in the review 18:23:49 #link https://review.openstack.org/#/c/214056/ 18:23:56 again, wanted to get feedback from the team. 18:24:01 this is an old change 18:24:24 in days of yore, sushilkm and dmakogon felt strongly against it. 18:24:45 I'm not sure the present incarnation of the change addresses their old concerns. 18:24:53 if anyone has thoughts about these please post in the review 18:25:17 trevormc, where are you with https://review.openstack.org/#/c/337914? 18:25:38 Looked at the change, but don't feel strongly about it one way or another. Will update the review with my comments. Thanks! 18:25:46 thx SlickNik 18:25:52 trevormc, there were some suggestions on how to proceed, do those make sense? 18:26:16 amrith, I have considered the suggestions and replied to the comments. 18:26:55 I tried using the item_type option before but it still uses cfg.ListOpt __call__ for enforcing the type. 18:27:10 who did you speak with in oslo? 18:27:16 doug hellmann 18:27:31 ok, was it irc? approx when, what channel? 18:28:18 irc in #openstack-oslo yesterday, but I don't remember the time exactly, approx 4pm CST 18:28:25 that's good enough 18:28:30 thanks, will go read the scrollback 18:28:50 finally, I have a question on what to do about isotime deprecation. 18:28:55 #link https://review.openstack.org/326655 18:29:01 I'm sure that SlickNik remembers this 18:29:07 (mess) 18:29:47 unfortunately there wasn't enough buy in to get the proposal adopted in oslo; keystone came the closest but they need one specific thing that makes it a pain to accomplish 18:29:55 the change as proposed is fine for Trove 18:30:07 and slightly better than just copying the deprecated function into Trove 18:30:35 so, comments in the review would be most appreciated so we can get them moving along 18:30:49 * amrith pauses to take a breath and see what others have to say ... 18:32:12 * SlickNik refreshes his memory 18:32:39 * amrith hears SlickNik howl in pain ... those were bad memories :) 18:34:18 I slightly prefer the updated timeutils — but let me go over the review after the meeting. 18:34:25 relevant: https://www.youtube.com/watch?v=-5wpm-gesOY 18:35:08 will watch it later 18:35:20 Yes, definitely for later. 18:35:32 seems longer than I'd want to watch now :) 18:35:45 so that's about all the regularly scheduled programming 18:35:49 unless someone has something for 18:35:54 #topic Open Discussion 18:35:59 😶/ 18:36:11 #action watch https://www.youtube.com/watch?v=-5wpm-gesOY 18:36:12 Scenario tests. 18:36:12 They have been running pretty well, but we still sometimes see an intermittent failure (in MySQL grant/revoke access) when the guests does not respond to the message. 18:36:12 This is unfortunatelly pretty difficult to debug as we don't have guest logs. I was wondering if restoring https://review.openstack.org/#/c/237710/ could help. 18:36:12 Not sure if it still works though... 18:36:13 Also, we will probably want to flip them (at least Redis) to voting at some point. 18:36:17 It may be worth considering adding some more as non-voting as well. 18:36:19 MariaDB (or PXC) would be good candidates. They should pass like MySQL and also test galera clustering which MySQL does not. 18:36:22 Postgresql should be stable as well (i.e. it fails only on the known issue related to [MySQL] API extensions). Cassandra is the same (but would potentially require more resources). 18:36:25 MongoDB not sure how it goes there, would need to run and see (the default required cluster size would likely be too large for the gate)... 18:36:28 Any ideas? 😋 18:36:44 so https://review.openstack.org/#/c/237710/ still works 18:36:54 (in principle) 18:37:12 would be straightforward to just rebase it and kick it up and depend on it 18:37:25 if you don't have much of a conflict, the merge should be automagic 18:37:59 re: flipping it to voting, let's put that on for discussion next week 18:38:12 the last time I spoke with peterstac about this he wasn't quite there ... 18:38:23 also about the cluster testing 18:38:29 which requires a bunch of resources 18:38:35 he was thinking of some way to do that 18:38:40 not sure how far he got 18:40:01 amrith I think you (the owner) would need to restore the patch set (237710) . 18:41:01 The cluster tests will always require some. We can help it a bit by starting with just a single-node cluster and growing it to 2 nodes then shrinking back to 1. We will however need to watch to make sure we never end up with too many instances... 18:41:04 #action amrith to review logstash to see how the redis scenario tests perform 18:41:11 pmalik, I've restored the review 18:41:19 amrith thanks 18:41:33 but things like pxc and mongodb need >> 2 nodes to work 18:41:41 pxc ~ 3, mongodb ~ 5 18:42:08 pmalik, the change is in merge conflict now; needs manual tlc 18:42:26 will you take care of it? I could do it later this evening 18:42:28 Yeah, I think that in case of PXC we can change it is configurable. Mongo has it hardcoded (3) though... 18:42:29 or tomorrow 18:42:33 maybe not before that 18:42:58 also we should come up with some way to handle this better in the future 18:43:04 like maybe merge the code with the setting disabled? 18:43:17 SlickNik, johnma what say? https://review.openstack.org/#/c/237710/ 18:43:38 #action revisit https://review.openstack.org/#/c/237710/ and figure out some way to get the code merged even if it is disabled but available for debugging? 18:44:27 pmalik, mongo is 3 data nodes, 1 config server, 1 query router so 5. 18:45:01 or should I say mongo is >=3 data nodes, >=1 config server, >=1 query router so >=5. 18:45:12 amrith + I believe it can be only grown by 3 or something... 18:45:35 oh? 18:45:40 did not know that ... 18:45:49 amrith I am not 100% sure here 18:46:09 well, you are likely right (history says) 18:46:27 I will take a look at that patchset after the meeting. 18:47:17 anyway, one way or the other you should be able to get the logs up and dbeug the failure. the code itself was pretty small (70 lines all told) so the merge can't be hard. likely the conflict is cfg.py :( 18:47:38 amrith it may be good if we could somehow figure out what kind of machines (flavor) we get for the gate and if it is possible to get some extra horsepower. 18:48:10 I believe we can specify the kind(s) of machines we get 18:48:16 but we can get assigned to different clouds 18:48:31 and different clouds have somewhat different horses 18:48:44 some are good horses, others are very good horses ... 18:48:59 will take a look and see what we currently have 18:49:12 because we can create like 4 MySQL (~750MB) instances at the same time, but say Cassandra requires 2GB for each... 18:49:18 #action review what kind(s) of machines we get in the gate and see if we can get some more beefy horses ... 18:49:52 yes, will look 18:50:01 thanks 18:50:02 amrith: If I recall correctly, at some point there was talk of merging https://review.openstack.org/#/c/237710/ and then removing it during the final milestone release. Another option is to default that option (guest_logs_to_host) to false, but then have our devstack (or devstack-gate) installs override that to true so it's easier to debug gate failures. 18:50:16 That sounds reasonable to me. 18:50:43 SlickNik, I'll push up a change that would put the code disabled (by default) and only have the gate flip it on 18:51:22 ++ Sounds good. Thanks! 18:51:22 not sure why I abandoned the change; maybe because we got to the root of whatever was failing and then the change seemed unnecesary 18:51:28 which is of course till something breaks again :) 18:53:16 ok, on that cheerful note ... 18:53:21 anything else? 18:54:32 for those of you who are interested, I attended a trainign with the TC last week in Ann Arbor. some details about that here http://openstack.markmail.org/thread/y43cfwdazrooml3y, here http://www.tesora.com/openstack-tc-will-not-opening-deli/ and here https://review.openstack.org/#/c/337895/ 18:55:20 that's all I've got. lots of action items, so I'll send out meeting notes right after 18:55:41 pmalik, unless you've already finished it, I'll rebase 237710 and resubmit. 18:55:57 going once ... 18:55:59 amrith ok, np. 18:56:03 thanks Amrith. 18:56:14 going twice ... 18:56:29 thanks all for attending. 18:56:32 #endmeeting