07:00:54 <tchaypo> #startmeeting tripleo
07:00:56 <openstack> Meeting started Wed Aug 20 07:00:54 2014 UTC and is due to finish in 60 minutes.  The chair is tchaypo. Information about MeetBot at http://wiki.debian.org/MeetBot.
07:00:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
07:00:59 <openstack> The meeting name has been set to 'tripleo'
07:01:04 <tchaypo> Greetings!
07:01:15 <tchaypo> #topic agenda
07:01:16 <tchaypo> * bugs
07:01:18 <tchaypo> * reviews
07:01:20 <tchaypo> * Projects needing releases
07:01:22 <tchaypo> * CD Cloud status
07:01:24 <tchaypo> * CI
07:01:26 <tchaypo> * Tuskar
07:01:28 <tchaypo> * Specs
07:01:30 <tchaypo> * open discussion
07:01:32 <tchaypo> Remember that anyone can use the link and info commands, not just the moderator - if you have something worth noting in the meeting minutes feel free to tag it
07:01:34 <tchaypo> #topic bugs
07:01:46 <tchaypo> #link https://bugs.launchpad.net/tripleo/
07:01:48 <tchaypo> #link https://bugs.launchpad.net/diskimage-builder/
07:01:50 <tchaypo> #link https://bugs.launchpad.net/os-refresh-config
07:01:52 <tchaypo> #link https://bugs.launchpad.net/os-apply-config
07:01:54 <tchaypo> #link https://bugs.launchpad.net/os-collect-config
07:01:56 <tchaypo> #link https://bugs.launchpad.net/os-cloud-config
07:01:58 <tchaypo> #link https://bugs.launchpad.net/tuskar
07:02:00 <tchaypo> #link https://bugs.launchpad.net/python-tuskarclient
07:02:02 <tchaypo> tripleo has been pretty red the last few weeks
07:02:43 <tchaypo> this week we're down to only 4 criticals, all assigned
07:03:01 <tchaypo> GheRivero: Are you around to talk about 1316985 ?
07:03:18 <GheRivero> hi there
07:03:23 <GheRivero> https://review.openstack.org/#/c/104115/
07:03:30 <GheRivero> just waiting for it to land
07:04:00 <tchaypo> #info GheRivero has https://review.openstack.org/#/c/104115/ waiting to land to solve https://bugs.launchpad.net/tripleo/+bug/1316985
07:04:03 <uvirtbot> Launchpad bug 1316985 in tripleo "set -eu may spuriously break dkms module" [Critical,In progress]
07:04:50 <tchaypo> gfidente and rpodoliaka don't seem to be around
07:06:15 <tchaypo> #info Looks like 248 total open bugs for tripleo - I wonder how that changes over time
07:06:35 <tchaypo> I don't know michael kerrin's nick so I'm not sure if he's around
07:07:12 <tchaypo> the only other critical on the other projects that I'm seeing is https://bugs.launchpad.net/tuskar/+bug/1357525 - but that's fix-committed
07:07:13 <uvirtbot> Launchpad bug 1357525 in tuskar "tuskar-api fails with "no such option: config_file"" [Critical,Fix committed]
07:07:26 <tchaypo> So unless anyone else has something to add I'm going to move on
07:07:36 <lxsli> MK's not on hipchat
07:07:54 <tchaypo> thanks lxsli
07:08:24 <tchaypo> #topic reviews
07:08:27 <tchaypo> #info There's a new dashboard linked from https://wiki.openstack.org/wiki/TripleO#Review_team - look for "TripleO Inbox Dashboard"
07:08:29 <tchaypo> #link http://russellbryant.net/openstack-stats/tripleo-openreviews.html
07:08:31 <tchaypo> #link http://russellbryant.net/openstack-stats/tripleo-reviewers-30.txt
07:08:33 <tchaypo> #link http://russellbryant.net/openstack-stats/tripleo-reviewers-90.txt
07:08:54 <tchaypo> Stats since the last revision without -1 or -2 :
07:08:56 <tchaypo> Average wait time: 11 days, 20 hours, 50 minutes
07:08:58 <tchaypo> 1st quartile wait time: 3 days, 15 hours, 20 minutes
07:09:00 <tchaypo> Median wait time: 7 days, 9 hours, 26 minutes
07:09:02 <tchaypo> 3rd quartile wait time: 20 days, 4 hours, 15 minutes
07:10:24 <lsmola2> o/
07:10:32 <tchaypo> lo lsmola2
07:11:16 <tchaypo> average and median are about the same as last week, 1st and 3rd quartiles are about 2 days higher each.
07:11:46 <tchaypo> Last week there was a bunch of talk that maybe we're measuring the wrong thing; I kicked off a mailing list thread but we haven't had much there
07:12:21 <tchaypo> #link http://lists.openstack.org/pipermail/openstack-dev/2014-August/042960.html
07:15:17 <tchaypo> Does anyone have any reviews they'd like to talk about?
07:15:40 <d0ugal> Reviews to help this land would be awesome :) https://review.openstack.org/#/c/104548/
07:15:46 <lxsli> https://review.openstack.org/#/c/86316/
07:16:08 <tchaypo> Could you mention them with the info or link hashtags so they hit the meeting log?
07:16:28 <lxsli> #link https://review.openstack.org/#/c/86316
07:16:57 <lxsli> I've had a lot of feedback that it should do what's necessary to obtain the software it's meant to install
07:16:59 <StevenK> #link https://review.openstack.org/108689
07:17:06 <d0ugal> #link https://review.openstack.org/#/c/104548/
07:17:30 <lxsli> Whereas AFAIC it's the job of tripleo-incubator (or an operator's replacement thereof) to provide appropriate package repos
07:17:44 <StevenK> lxsli: What? It so isn't
07:17:55 <lxsli> I'd appreciate your illustrious opinions :)
07:18:00 <lxsli> StevenK: to which statement?
07:18:03 * tchaypo gets popcorn
07:18:14 <StevenK> "to provide appropriate package repositories"
07:18:47 <StevenK> It is not required at all. It's highly recommended, but by default -incubator and elements will happy reach out to the Internet to pull things down
07:19:15 <lxsli> WHat I mean is, the dpkg + apt-sources elements can do this, so if t-i wants to include elasticsearch it can configure those elements to provide a repo
07:19:32 <lxsli> Yeah that didn't work out so well with the PErcona tarball imo
07:19:57 <StevenK> The Percona stuff has been working fine for a while?
07:20:13 <StevenK> Keep in mind cloud images are also downloaded from the internet
07:20:34 <StevenK> And the default behavior is to download all requirements from pypi directly
07:22:16 <lxsli> OK message received. So should we just remove the support from dpkg + apt-sources since we're not allowed to use it?
07:22:43 <StevenK> You are allowed to use it.
07:23:07 <StevenK> I quite liked greghaynes's suggestion of DIB_REPOLOCATION_elasticsearch if you use source-repositories
07:23:36 <lxsli> I need to read up about that
07:24:00 <lxsli> I've probably consumed my share of meeting time now, thanks
07:24:16 <StevenK> Okay, so my patch is pretty special
07:24:25 * tchaypo already has popcorn
07:24:45 <StevenK> It's os-cloud-config, and it's +450 lines, but it's been up since the 22nd of July and in that time it's had one +1
07:25:03 <StevenK> Well, 2. Since Jenkins likes it
07:25:09 <tchaypo> StevenK: any chance you can break it into something smaller?
07:25:15 <StevenK> tchaypo: Not easily
07:25:41 <StevenK> It adds support for setup-neutron to os-cloud-config
07:26:11 <lxsli> the lack of even a project description at https://github.com/openstack/os-cloud-config isn't helping
07:26:32 <lsmola2> StevenK, cool, I will look on that
07:26:48 <StevenK> lxsli: Blah, I keep meaning to fix that
07:27:18 <lxsli> StevenK: sweet :)
07:27:35 <tchaypo> StevenK: I'll try to take a look as well
07:28:06 <tchaypo> d0ugal: did you want to say anyhting about https://review.openstack.org/#/c/104548/ ?
07:28:08 <StevenK> lxsli: See #tripleo, I've pushed up a very WIP branch for that
07:28:27 <lxsli> Great will do
07:28:30 <d0ugal> tchaypo: nothing specific - I'm just looking for reviewers as I keep needing to rebase since it touches a bunch of files
07:28:50 <tchaypo> d0ugal: yeah, that's massive
07:29:02 <StevenK> lxsli: But since it will keep staring at me in the face when I look at my dashboard, I'll probably finish it off soon
07:29:11 <lxsli> #link https://review.openstack.org/115523
07:29:16 <tchaypo> is tuskar-knowledge required to be useful reviewing that?
07:29:22 <d0ugal> tchaypo: Indeed, mostly deletes thankfully but hard to break up.
07:29:31 <d0ugal> tchaypo: not really, oslo.db knowledge is probably the most useful
07:31:14 <tchaypo> Anything else before we move on?
07:31:47 <tchaypo> #topic Projects needing releases
07:32:10 <tchaypo> Do we have a victimeer this week?
07:32:18 <lifeless> hi, sorry for awolness.
07:34:01 <tchaypo> hrm. this is a problem.
07:34:17 <tchaypo> StevenK: were you still looking for a chance to do a release?
07:34:22 <StevenK> I can not
07:34:39 <lifeless> I can do a release
07:34:51 <StevenK> It requires membership in the tripleo-ptl group
07:35:01 <tchaypo> #info lifeless to do this weeks' round of releases
07:35:09 <tchaypo> #topic CD Cloud status
07:36:03 <derekh> hp1 is up and running again
07:36:07 <tchaypo> #info hp2 is making progress, slowed down by me doing a bunch of learning as I go
07:36:12 <derekh> ci tests arn't yet passing at a rate thats high enough, currently investigating
07:36:21 <tchaypo> I'm going to tentatively say hp2 might perhaps be ready for some testing early next week
07:37:19 <tchaypo> #info derekh reports that hp1 is up and running, but has a higher-than-acceptable error rate - investigations are continuing
07:37:45 <StevenK> tchaypo: That probably refers to both hp1 and the redhat ci cloud
07:38:04 <tchaypo> #undo
07:38:05 <openstack> Removing item from minutes: <ircmeeting.items.Info object at 0x294c9d0>
07:38:27 <tchaypo> #info derekh reports hp1 is up and running.
07:38:35 <derekh> StevenK: no rh1 is ok
07:38:46 <tchaypo> #info derekh further reports that he's investigating why ci tests aren't passing at a high enough rate in hp1
07:39:17 <StevenK> Ah, right
07:39:40 <derekh> tchaypo: #info is correct
07:40:19 <tchaypo> Anything else?
07:41:11 <derekh> nothing from me
07:41:17 <tchaypo> #topic ci
07:41:35 <derekh> tripleo ci was reporting incorrect results since friday, iirc that's fixed now but anything thats passed since then can't be trusted
07:42:04 <tchaypo> derekh: could you hashtag-info that?
07:42:24 <tchaypo> also, are we doing anythign systematic to find bad commits and revert/fix, or are we just reacting as we find breakage?
07:42:39 <tchaypo> also, could you @link anywhere we can find out more about root-cause/remediation?
07:42:50 <derekh> #info tripleo ci tests that have passed since friday last can't be trusted, lots of false positives
07:43:55 <lifeless> well
07:43:58 <derekh> tchaypo: looks like the commits that were breaking ci are now reverted
07:43:59 <lifeless> if CI is passing right now
07:44:02 <lifeless> its fine
07:44:19 <derekh> lifeless: it is
07:44:50 <derekh> anybody know if there was there a bug for it
07:44:58 <tchaypo> so... the things that passed since friday... can be trusted, on account of being tested since we fixed CI?
07:45:15 <lifeless> yes
07:45:22 <lifeless> just don't deploy from within that window:)
07:45:41 <derekh> tchaypo: can -> can't
07:45:58 <lifeless> ah
07:46:17 <lifeless> derekh means 'unmerged stuff with a CI run from before today-after-fixing cannot be +A'd'
07:46:41 <tchaypo> #info lifeless> derekh means 'unmerged stuff with a CI run from before today-after-fixing cannot be +A'd'
07:46:42 <lifeless> tchaypo means 'is trunk ok'
07:47:03 <tchaypo> indeed
07:47:12 <derekh> lifeless: yup,
07:47:43 <tchaypo> okay. ready to move on?
07:47:57 <tchaypo> #topic Tuskar
07:48:01 <derekh> Here is a bug I noticed on monday https://bugs.launchpad.net/tripleo/+bug/1358397 , would be great if somebody had the time to take a peak
07:48:02 <uvirtbot> Launchpad bug 1358397 in tripleo "overcloud stack-create takes > 30 minutes" [High,Triaged]
07:48:16 <tchaypo> We already had a review from d0ugal that needs to be looked at
07:48:29 <derekh> basically overcloud test is taking about 30 minutes longer then it should
07:48:56 <derekh> I've filed whats there but havn't poked into it at all, so no other info
07:49:34 <tchaypo> I'm going to start rushing along since we're running out of time
07:49:56 <tchaypo> #topic one-off items
07:50:01 <tchaypo> #info thoughts about separate CI jobs to test BLOCKSTORAGESCALE and SWIFTSTORAGESCALE? (gfidente)
07:50:32 * tchaypo pokes gfidente
07:50:59 <gfidente> doh, sorry, was late, thanks tchaypo
07:51:17 <tchaypo> gfidente: I just mentioned your item, can you expand on it?
07:51:59 <gfidente> yeah I just wanted to see if other people was interested in having jobs testing the block storage and swift storage scaling
07:52:21 <gfidente> as that part of code is not tested by the jobs I saw in derekh'l spreadsheet
07:53:05 <jp_at_hp> it makes sense to me, if there will e capacity to do so.
07:53:08 <derekh> gfidente: they sound to me like its something worth testing, if it was acceptable we could them to 2 of the existing jobs (1 each)
07:53:30 <lsmola> gfidente: +1, that part was often broken AFAIK, we should test it
07:53:41 <tchaypo> gfidente: you have an answer, make it so!
07:53:43 * tchaypo rushes forward
07:53:55 <tchaypo> #topic specs
07:53:57 <derekh> gfidente: we could try it at least, if thats not going to work we could try an extra job
07:54:20 <gfidente> derekh, I see what you mean, agreed
07:54:24 <tchaypo> We've had some discussion on the mailing list about specs/approval, I propose we continue the discussion there
07:54:34 <tchaypo> which leaves us 5 minutes...
07:54:37 <tchaypo> #topic open discussion
07:54:55 <lsmola> so what is the number of spec reviews we should do per week?
07:54:56 <tchaypo> My question is: Are these alternate-time meetings useful?
07:55:12 <StevenK> tchaypo: Yes
07:55:19 <d0ugal> tchaypo: yes!
07:55:23 <tchaypo> lsmola: I believe the numbers being suggested at the mid-cycle were around 1/2 per week
07:55:44 <d0ugal> tchaypo: (I can rarely make the other meeting time)
07:55:46 <lsmola> tchaypo: yes
07:55:54 <lsmola> tchaypo: ok, thanks
07:55:58 <tchaypo> You don't find that the smaller number of attendees here makes it less useful?
07:56:15 <d0ugal> less useful, sure, but better than nothing for me :)
07:56:18 <tchaypo> (it sounds like the answer is "but the smaller number includes me, which makes it awesome!")
07:56:23 <d0ugal> ha
07:56:46 <d0ugal> tchaypo: I guess the question is, how many people do we get at this meeting that otherwise can't make the other one?
07:56:49 <StevenK> tchaypo: I'd much rather be sleeping at 0500 rather than meeting, which means this meeting is excellent
07:56:58 <d0ugal> That's the real purpose of an alternative time IIUC
07:57:16 <lsmola> tchaypo: hehe
07:58:09 <tchaypo> okay, I'm going to bring this meeting to an end a few minutes early so I can run to my german class.
07:58:27 <gfidente> too bad
07:58:48 * gfidente joking
07:58:51 <derekh> both meeting are equally outside of my working day, this one is an hour befor I usually start and the other 2 hours after I leave so ... meh
07:59:08 <lxsli> same
07:59:19 <d0ugal> same
07:59:25 <d0ugal> but I have more plans after work than before work :)
07:59:27 <gfidente> tchaypo, but overall I think the problem raised by tchaypo is real
07:59:38 <jp_at_hp> which is fine till winter kicks in and its 2 hours before work :-(
07:59:44 <gfidente> maybe we can try to find a different timeframe for a single meeting time?
07:59:44 <tchaypo> gfidente: which problem is that?
07:59:52 <gfidente> (not many people)
07:59:57 <StevenK> We effectively cover the world
08:00:04 <StevenK> Which means one meeting time is *hard*
08:00:07 <tchaypo> ah right.
08:00:08 <derekh> jp_at_hp: ahhh, I hadn't thought of that
08:00:45 <tchaypo> One of the reasons for this time was to enable people in eastern APAC to join, but it seems like most people are actually from western europe (ie, the areas where it's an hour or so before their normal workday)
08:00:58 <d0ugal> jp_at_hp: +1, moving this meeting a little later before the time change would be handy.
08:01:11 <tchaypo> maybe moving it an hour later would be useful? And almost certainly we need ot adjust once DST flips over
08:01:32 <StevenK> I'm happy with 1700AEST. I'm less happy with 1800AEST
08:01:34 <tchaypo> d0ugal/jp_at_hp/gfidente/derekh - could you suggest this on the list?
08:01:57 <derekh> tchaypo: can do
08:02:00 <tchaypo> thanks
08:02:07 <tchaypo> #endmeeting