08:01:12 <shadower> #startmeeting tripleo
08:01:13 <openstack> Meeting started Wed Oct 15 08:01:12 2014 UTC and is due to finish in 60 minutes.  The chair is shadower. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:01:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:01:17 <openstack> The meeting name has been set to 'tripleo'
08:01:47 <marios_> ο/
08:01:59 * shadower waits a bit to make sure it's not just d0ugal and marios_
08:02:19 <d0ugal> heh, that would make for a quick meeting
08:02:27 <StevenK> o/
08:02:29 <shadower> yup
08:02:36 <tchaypo> \o
08:02:38 <tchaypo> An hour ago it was just StevenK and I
08:02:58 <shadower> everyone else knew thi right time :-)
08:03:00 <GheRivero> o/
08:03:28 <shadower> looks like we have a couple of one-off items
08:03:34 <d0ugal> tchaypo: and me!
08:03:36 <shadower> #topic one-off agenda items
08:03:36 <shadower> * CI x86 (current) or move to x86_64?
08:03:36 <shadower> * Need for OSLO liason? (SpamapS)
08:03:55 <StevenK> shadower: Australia did a DST change
08:04:02 <StevenK> Well, parts of it did
08:04:08 <shadower> lol
08:04:14 <GheRivero> hah
08:04:14 <shadower> DST should die
08:04:18 <d0ugal> +1
08:04:19 <GheRivero> +1
08:04:23 <shadower> anyway
08:04:40 <tchaypo> +1
08:04:47 <shadower> I don't know who proposed the CI x86 vs. 64 item
08:04:55 <shadower> are you here?
08:05:21 <tchaypo> it was not i
08:06:08 <shadower> derekh doesn't seem to be here either
08:06:21 <shadower> he might have knownn about it, let's just skip it then
08:06:30 <shadower> haha
08:06:57 <shadower> derekh: do you know anything about the "CI x86 (current) or move to x86_64?" one-off agenda item someone put on the wiki?
08:07:26 <derekh> shadower: ahh, I put that there a few weeks ago, will remove it, we've discussed it
08:07:37 <shadower> oh okay
08:08:02 <shadower> moving on, then
08:08:05 <shadower> Need for OSLO liason? (SpamapS)
08:08:31 * shadower worries this may be in the same boat as this is not a god time for SpamapS
08:08:35 <shadower> good even
08:08:45 <GheRivero> this is going to be a quick meeting
08:09:12 <StevenK> GheRivero: Best kind!
08:09:32 <GheRivero> do we have any volunteer to be the liaison?
08:09:33 <d0ugal> :)
08:09:42 <shadower> do we even need one?
08:09:47 <tchaypo> I did talk to him about this last week
08:09:55 <tchaypo> That's exactly what I said
08:09:57 <GheRivero> we should
08:10:15 <GheRivero> there are some oslo dependencies, few, but some
08:10:44 <derekh> isn't bnemec an oslo core?
08:10:45 <d0ugal> The Tuskar code has a bunch too
08:11:28 <StevenK> derekh: Yup
08:11:40 <GheRivero> I'm the liaison for Ironic, son I can take care of it, know the procedure
08:11:57 <GheRivero> or bnemec :)
08:12:06 <shadower> GheRivero: will you talk to SpamapS and bnemec then please?
08:12:19 <GheRivero> sure, no problem
08:12:40 <tchaypo> This feels like it needs a hash-action to record it
08:13:24 <shadower> #info GheRivero to talk to SpamapS about the oslo liaison
08:13:33 <GheRivero> also, QA and doc teams are looking for liaisons....
08:14:20 <GheRivero> should be added to the agenda for tne next meeting
08:14:28 <tchaypo> Has there been a thread that I missed?
08:15:31 <GheRivero> tchaypo: if thread is a single mail, yes
08:15:39 <shadower> haha
08:15:49 <shadower> maybe we could do that on the ML? We'll be able to reach the entire team that way
08:16:22 <GheRivero> http://osdir.com/ml/openstack-dev/2014-10/msg00842.html
08:17:23 <shadower> we're 17 minutes in, let's move onto our regular agenda
08:17:26 <GheRivero> bnemec appears as a TripleO liaison, maybe he just appointed herself as that ( \o/)
08:17:26 <shadower> #topic agenda
08:17:26 <shadower> * bugs
08:17:26 <shadower> * reviews
08:17:26 <shadower> * Projects needing releases
08:17:26 <shadower> * CD Cloud status
08:17:28 <shadower> * CI
08:17:31 <shadower> * Tuskar
08:17:33 <shadower> * Specs
08:17:36 <shadower> * open discussion
08:17:40 <shadower> #topic bugs
08:18:12 <shadower> #link https://bugs.launchpad.net/tripleo/
08:18:12 <shadower> #link https://bugs.launchpad.net/diskimage-builder/
08:18:12 <shadower> #link https://bugs.launchpad.net/os-refresh-config
08:18:12 <shadower> #link https://bugs.launchpad.net/os-apply-config
08:18:12 <shadower> #link https://bugs.launchpad.net/os-collect-config
08:18:15 <shadower> #link https://bugs.launchpad.net/os-cloud-config
08:18:17 <shadower> #link https://bugs.launchpad.net/tuskar
08:18:20 <shadower> #link https://bugs.launchpad.net/python-tuskarclient
08:18:28 <shadower> we have one critical bug
08:18:35 <shadower> #link https://bugs.launchpad.net/tripleo/+bug/1374626
08:18:37 <uvirtbot> Launchpad bug 1374626 in tripleo "UIDs of data-owning users might change between deployed images" [Critical,Triaged]
08:18:54 <tchaypo> I thought spamaps was working on that
08:18:54 <shadower> it was discussed last week and on the mailing list. SpamapS is assigned to it
08:19:23 <shadower> #topic reviews
08:19:33 <shadower> #link http://russellbryant.net/openstack-stats/tripleo-openreviews.html
08:19:36 <shadower> #link http://russellbryant.net/openstack-stats/tripleo-reviewers-30.txt
08:19:39 <shadower> #link http://russellbryant.net/openstack-stats/tripleo-reviewers-90.txt
08:21:55 <shadower> anyone wants to add anything?
08:22:09 <marios_> looks like its better no?
08:22:15 <marios_> (time wise)
08:22:31 <shadower> where's the part we're looking at again?
08:23:09 <marios_> 3rd qrtile w/out -1/-2 i believe
08:23:13 <marios_> sec
08:23:58 <tchaypo> Queue growth in the last 30 days: 24
08:24:00 <tchaypo> Is what I've been paying attention to
08:24:09 <marios_> 19:18:11 <tchaypo> 3rd quartile wait time: 19 days, 7 hours, 13 minutes (last week)
08:25:37 <marios_> perhaps worth noting that a few core reviewers have slipped (myself including) below the 60/month average we expect of core
08:25:54 <marios_> (included)
08:26:03 <tchaypo> Down to just 8 days for the 3rd quartile stat now
08:27:09 <shadower> #topic Projects needing releases
08:27:21 <shadower> jdob asked me to volunteer him
08:27:30 <shadower> #info jdob will release the world
08:27:44 <marios_> shadower: cool, can i bring up sthing here about releases?
08:27:52 <shadower> marios_: go ahead
08:28:16 <marios_> shadower: when doing a release, I have always incremented the .patch... for some projects we are reaching double numbers (like 33)
08:28:48 <marios_> shadower: my thought process is 'whoever has a vested interest/leading that project should let me know when/if they need something different to happen
08:28:51 <marios_> '
08:29:08 <tchaypo> Is this a written part of the process?
08:29:10 <marios_> shadower: i thought it may be worth bringing up, do people agree? should we make it a thing. somehow
08:29:14 <tchaypo> Do others do the same?
08:29:19 <marios_> sec
08:29:29 <marios_> https://wiki.openstack.org/wiki/TripleO/ReleaseManagement
08:29:45 <marios_> (Versioning Scheme)
08:29:48 <shadower> well we're following semver (a bit stricter since we're usually on 0.x.x where anything goes as far as semver is concerned)
08:30:05 <shadower> so if we've extended the API, we increase the minor versiosn
08:30:10 <shadower> otherwise it's a patch increase
08:30:21 <marios_> tchaypo: afaik /have seen, yes this is what people do for a release
08:30:45 <marios_> shadower: my point wasn't so much to have a discussion about why/when we increment minor
08:30:54 <shadower> ok sorry
08:31:09 <marios_> shadower: my question was 'who is responsible for letting release_person know that they need minor or even major bumped'
08:31:26 <shadower> marios_: the release person should go through  the commits and figure it out
08:31:33 <shadower> at least that's what I've been doing
08:32:09 <marios_> shadower: yeah. so this places quite a burden on the release person (like 10 projects now). also, it's not always so clear.
08:32:20 <shadower> right
08:32:25 <tchaypo> For any projects above 1.0 the person would need to figure out the backwards-compatibility
08:32:44 <shadower> and a correction from what I said earlier, we increase the minor version only when we break back compatibility
08:32:47 <StevenK> Well, once we move to pbr's semver, it should become very easy
08:33:05 <StevenK> Since the commit messages themselves tell how the version should change
08:33:30 <shadower> StevenK: how does that work?
08:33:35 <tchaypo> Is that something we can start doing already?
08:34:27 <StevenK> shadower: lifeless gave a talk about it -- there are comments you put in the commit message, think things like 'DocImpact' except its like 'ApiBreak'
08:34:42 <StevenK> And then semver knows what they each correlate too
08:34:48 <shadower> right
08:35:10 <tchaypo> If this makes it automatable it sounds like it should be easy for humans too?
08:35:19 <tchaypo> Well, helpful at least
08:35:29 <shadower> yeah
08:35:44 <shadower> anyone want to bring that up on the ml?
08:35:55 <marios_> StevenK: that sounds perfect
08:37:00 <shadower> on the few occasions we have had a backwards-incompatible change, it was usually noted in the commit msg but it'd be good to formalise that process
08:37:27 <StevenK> Right. I'm looking forward to the pbr's changes being ready, since then it just happens for us
08:37:51 <StevenK> And it moves the onus onto the people in the trenches writing the code and the reviewers
08:38:09 <marios_> shadower: sure. so i'm happy the discussion was had. i don't really expect full consensus etc. i thought the point was just worth making as it occurs to me whenever i release
08:38:17 <marios_> and i keep forgetting to bring it up
08:39:15 <shadower> marios_: right. It would be good to bring to everyone's attention
08:39:47 <shadower> marios_: when we move to a 1. release, the number of patch versions will prolly go down (and the number of minor will skyrocket)
08:40:01 <shadower> if we stick to weekly releases
08:40:05 <shadower> moving on?
08:40:13 <marios_> +1
08:40:18 <StevenK> Yeah, +1
08:40:20 <shadower> #topic CD Cloud status
08:40:31 <lsmola> o/
08:41:14 <shadower> tchaypo?
08:41:18 <shadower> derekh?
08:41:21 <tchaypo> I'm busy trying to get correct mac addresses doe 80 of the machines in hp2
08:41:47 <tchaypo> I've discovered the list I had was wrong, hence they don't pxe
08:41:55 <tchaypo> So I expect much progress ro report next week
08:42:07 <derekh> rh1 == ok
08:42:17 <derekh> hp1 waiting to be added back https://review.openstack.org/#/c/126513/
08:42:42 <shadower> cool, thanks
08:43:03 <shadower> #topic CI
08:43:21 <derekh> Things have been quite on the CI front for the last week,
08:44:19 <shadower> cool
08:44:37 <shadower> #topic Tuskar
08:44:45 <shadower> d0ugal?
08:45:02 <d0ugal> Not much to report.
08:45:19 <d0ugal> We are basically sorting out loose ends for Juno at this point.
08:45:38 <shadower> great
08:45:45 <shadower> #topic Specs
08:46:26 <marios_> how do we feel about landing reviews when the spec is not yet merged?
08:46:42 <marios_> (may be offtopic, feel free to bump to open-discussion shadower )
08:47:11 <StevenK> marios_: Bring it up on the list
08:47:19 <tchaypo> Some things are useful even if the spec doesn't land
08:47:26 <shadower> yea
08:47:34 <GheRivero> depends the reason why it hasn't landed: minor tweaks or deep discussions
08:47:38 <StevenK> Right
08:47:41 <shadower> yep
08:47:52 <marios_> so the reason i ask is because in neutron, that's how it's done (bug report or spec linked to code review,or it doesn't land)
08:48:13 <marios_> and i came across an image-elements change where this is the case
08:48:27 <marios_> (spec  still in review but code could well land before spec merges).
08:48:31 <shadower> so that's something which needs the team's concensus -> ML
08:48:37 <shadower> but I don't think we need to be that strict
08:49:15 <shadower> fyi I've dusted off the old "remove merge.py" spec https://review.openstack.org/#/c/97939/ and we now have template patches in gerrit
08:49:37 <shadower> #topic open discussion
08:49:48 <tchaypo> Woo
08:51:48 * marios_ all off-topic discussioned out
08:52:36 <shadower> okay
08:52:39 <shadower> #endmeeting