19:03:08 <fungi> #startmeeting infra
19:03:09 <openstack> Meeting started Tue Jun  6 19:03:08 2017 UTC and is due to finish in 60 minutes.  The chair is fungi. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:03:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:03:13 <openstack> The meeting name has been set to 'infra'
19:03:16 <fungi> #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting
19:03:18 <fungi> #topic Announcements
19:03:22 <fungi> i don't think i have anything super important to announce this week
19:03:25 <fungi> as always, feel free to hit me up with announcements you want included in future meetings
19:03:28 <bkero> o/
19:03:32 <fungi> #topic Actions from last meeting
19:03:38 <fungi> #link http://eavesdrop.openstack.org/meetings/infra/2017/infra.2017-05-30-19.03.html Minutes from last meeting
19:03:41 <fungi> fungi propose a help-wanted section to our specs index for unassigned specs
19:03:48 <fungi> done, i'll cover it under the next topic, which is...
19:03:54 <fungi> #topic Specs approval - ADMIN: Add a help-wanted section (fungi)
19:04:02 <fungi> #link https://review.openstack.org/471149 Add a help-wanted section
19:04:08 <fungi> basically just wanted to try and get some consensus in meeting that this is an okay implementation of the idea
19:04:16 <fungi> i don't personally think it merits a lengthy council rollcall since it's just reorganizing the index a little
19:04:59 <jeblair> ++
19:05:04 <fungi> basically i scoured all our open specs, and any which didn't list an actual human assignee got moved into this section of the index
19:05:41 <fungi> TristanC picked up one yesterday, so i updated the change to no longer move that one (the nodepool drivers spec)
19:06:06 <clarkb> I voted +1 +1 on the change already
19:06:20 <fungi> i saw, much appreciated!
19:06:44 <fungi> anyway, hearing no dissent, i'll approve it now in the meeting. we can always undo this if it turns out to be more trouble than it's worth i guess
19:07:37 <fungi> #topic Priority Efforts - Ansible Puppet Apply: Done? (fungi)
19:07:42 <fungi> #link http://specs.openstack.org/openstack-infra/infra-specs/specs/ansible_puppet_apply.html Ansible Puppet Apply
19:07:47 <fungi> the story linked from this had only one task and it's marked as merged
19:07:52 <fungi> puppetdb reporting mentioned as part of the proposed change hasn't been completed yet
19:07:59 <fungi> but we've gone another direction and abandoned puppetdb/puppetboard anyway so i assert that this spec is implemented and we can move on
19:08:26 <fungi> anybody feel strongly that we should keep it open/active until that's solved?
19:08:51 <cmurphy> i think it'll be easier to fix that part if we upgrade puppet
19:08:59 <fungi> yes ;)
19:09:07 <jeblair> feels done to me
19:09:22 <fungi> cmurphy: i would like to get your puppet 4 spec up for council vote soon. do you think next week is too soon?
19:09:51 <fungi> or is it still getting hashed out in review?
19:10:21 <cmurphy> fungi: the proposal is finished but i'm having concerns about getting participation on reviews
19:10:50 <cmurphy> and if there's a new spec to move some things over to pure ansible then this seems less urgent
19:11:28 <clarkb> the proposal on the ansible side is only for new things. So I think addressing existing puppet is worthwhile unless we want to morph ansible proposal to be all the things
19:12:08 <dirk> cmurphy: fwiw the spec is in merge conflict
19:12:30 <fungi> probably because of the change i just merged
19:12:40 <jeblair> i'm assuming ansible for new things would be a first step toward ansible for all things.  so deciding on where we want to end up would be useful.
19:12:44 <cmurphy> this one? https://review.openstack.org/#/c/449933
19:12:45 <mordred> I agree
19:13:05 <fungi> the help-wanted change likely generated a fair number of merge conflicts over the specs index
19:13:37 <mordred> I think it's worthwhile for us all to mull whether or not we'll get the coders and reviewers for either puppet4 or ansible work as we think about what the overall plan should be
19:14:05 <fungi> #agreed ansible_puppet_apply spec can be marked implemented
19:14:13 <cmurphy> right now all of the beaker tests are broken, they are hard to fix, and no one (including me) really wants to put the effort into fixing them
19:14:18 <mordred> cmurphy: yah
19:14:28 <cmurphy> so yes i agree that moving toward something that people want to work on is worthwhile
19:14:42 <mordred> ++
19:15:25 <fungi> conversely, we need to be able to continue managing what we have until whatever else comes along to replace it is ready
19:15:28 <mordred> fungi: ++
19:15:30 <mordred> that too
19:15:56 <fungi> so if that means we need to fix our current testing somehow, we should still be thinking about what ways we have to accomplish that
19:16:56 <fungi> is (was) the beaker-based testing catching bugs we were missing in our apply tests?
19:16:58 <ianw> why are they hard to fix?  just a lot of dependencies?
19:17:06 <ianw> or something deeper?
19:17:26 <clarkb> fungi: yes, they were able to catch a class of bug only found when actually applying puppet not in noop mode
19:17:28 <cmurphy> fungi: i think there's been a few times they caught real bugs, though hard to say lately
19:17:55 <clarkb> idempotency being one
19:18:31 <fungi> clarkb: cmurphy: thanks. i mean i know in theory they test more deeply than we can with apply jobs, just didn't know if the effort we've been putting into maintaining them was offset by the benefits we were getting
19:18:36 <cmurphy> ianw: well for example since we let them lapse the puppet-jenkins module started needing a lot of work to get it back to working https://review.openstack.org/#/c/462048/
19:19:43 <fungi> did most of this creep up on us simply because we only spot issues when someone proposes a new change to a module and most of our modules are very low-churn?
19:20:04 <dirk> cmurphy: yes (sorry, was afk)
19:20:05 <cmurphy> fungi: it crept up on us because we left them nonvoting
19:20:31 <fungi> they were voting on at least some modules i thought
19:20:38 <pabelanger> o/
19:20:44 <ianw> cmurphy: ahh, yeah ... a lot of churn to cover
19:21:48 <fungi> am i misremembering, or did something cause us to switch them back to nonvoting across the board?
19:22:04 <cmurphy> i think puppet-cgit has voting centos beaker jobs
19:22:10 <cmurphy> i don't remember if there are others
19:23:47 <cmurphy> didn't mean to derail the spec approval topic, we can come back to this later
19:24:02 <fungi> well, it's a very important topic. i'm just wondering whether we should be hashing these various parallel concerns out on the infra ml. i'm worried that this meeting isn't going to be sufficient to get to whatever sort of consensus we need on such a complex situation
19:24:35 <fungi> i can try to summarize the various points raised in a starter message and see where the discussion goes
19:25:16 <cmurphy> sounds good
19:25:19 <fungi> #action fungi start an infra ml thread about puppet 4, beaker jobs and the future of infra configuration management
19:25:46 <fungi> thanks cmurphy! i hadn't realized things were in quite the state they are on this
19:26:04 <fungi> #topic Priority Efforts - A Task Tracker for OpenStack: Assignees? (fungi)
19:26:09 <fungi> #link http://specs.openstack.org/openstack-infra/infra-specs/specs/task-tracker.html A Task Tracker for OpenStack
19:26:15 <fungi> diablo_rojo has been the defacto phase 1 coordinator/facilitator on this for a while now
19:26:22 <fungi> diablo_rojo: if you're around, mind updating the task-tracker spec to list yourself as the assignee and move it from the help wanted section back into the approved section?
19:27:26 <fungi> #action fungi get up with diablo_rojo about task-tracker spec assignment
19:27:48 <zara_the_lemur__> :)
19:28:18 <fungi> i'm noticing we actually have it double-listed since it's also in the priority efforts section, so i guess we can just take it out of the help wanted section once it has an actual assignee noted
19:28:41 <zara_the_lemur__> *nod*
19:28:45 <fungi> #topic Priority Efforts - Gerrit 2.13 Upgrade: Stalled? (fungi)
19:28:52 <fungi> #link http://specs.openstack.org/openstack-infra/infra-specs/specs/gerrit-2.13.html Gerrit 2.13 Upgrade
19:28:57 <fungi> zaro is listed as the assignee on this (and did some awesome preliminary testing, thanks!)
19:29:02 <fungi> but his employment situation has left him with limited time to help on it lately
19:29:07 <fungi> clarkb has prodded at it a bit more recently too
19:29:14 <fungi> also gerrit 2.14 has been out for a couple months now, looks like so maybe we should be evaluating that?
19:29:22 <fungi> i'm mostly just trying to get a feel for whether this has the momentum and volunteers to keep it in the priority efforts set, realistically
19:29:58 <clarkb> the summit and prep for summit let out all the steam I had on this
19:30:04 <clarkb> I should pick it back up again, its just hard because gerrit :)
19:30:35 <fungi> yeah. we seem to end up in a perpetual cycle of taking longer to evaluate a new version of gerrit than it takes them to release new versions
19:30:50 <jeblair> if we wanted to reduce the scope of this to omit fixing up 'zuul-dev' and just rely on local testing, i'd be fine with that
19:30:52 <clarkb> we do have a build of a 2.13.x war that we can apply to review-dev built. What we need to do is run through the actual upgrade process on review-dev because we can't do it with online indexing
19:31:08 <jeblair> though *some* amount of testing with zuul should be done.  especially if we move to newer gerrit
19:31:19 <clarkb> so mostly just want to be sure we have a process and its tested and measured before we go to production
19:31:34 <jeblair> i've seen some gerrit-compatability patches for zuul recently but haven't really kept track of what versions were involved
19:31:35 <mordred> jeblair: luckily tobiash already found us one zuul+newer-gerrit bug :)
19:31:37 <clarkb> jeblair: agreed, I think we can just run noop jobs out of a virtualenv to start though
19:32:13 <clarkb> of course maybe we want to go to 2.14 instead of 2.13 and get a new war up?
19:32:32 <clarkb> its probably not a bad idea otherwise our next upgrade will be even further behind
19:32:37 <fungi> i'm tempted to say stick with 2.13 rather than losing what progress we've potentially made by starting all over
19:32:37 <mordred> 2.14 requires java 8 - do we have that?
19:32:46 <clarkb> mordred: oh on xenial we do
19:32:51 <clarkb> so maybe we stick with 2.13 then
19:32:59 <mordred> yah. otherwise it's a host change too
19:33:18 <jeblair> i can help out with the zuul testing part if needed
19:33:22 <clarkb> given that my preference is definitely 2.13 to reduce complexity
19:33:25 <fungi> well, or a somewhat distasteful in-place distro upgrade like we did/are doing for lists.o.o
19:33:43 <fungi> (to avoid a host replacement)
19:33:55 <clarkb> why don't I finish writing up an upgrade doc (I started but never actually put real content in there), we can review it, apply it to review-dev then resync on testing
19:34:01 <jeblair> in place wasn't too bad :)
19:35:05 <fungi> all things considered, debian (and by extension ubuntu) does manage to make in-place upgrading not too painful, agreed
19:35:28 <fungi> clarkb: sounds good to me
19:35:53 <fungi> #action clarkb finish writing up an upgrade doc for gerrit 2.11 to 2.13
19:35:57 <fungi> thanks!
19:36:01 <mordred> fwiw, 2.14 includes polygerrit - and I also see things in the rest api docs about "robot comments"
19:36:43 <fungi> i for one welcome our new robot overlords (as long as they adhere to the three laws)
19:36:50 <mordred> fungi: ++
19:36:57 <mordred> fungi: is one of the three laws "don't break any of the laws"
19:37:33 <fungi> that's sort of the zeroth law, but...
19:37:37 <fungi> #topic Specs Cleanup (fungi)
19:37:44 <fungi> #link http://specs.openstack.org/openstack-infra/infra-specs/ OpenStack Project Infrastructure Design Specifications
19:37:51 <fungi> since nobody else proposed any topics this week, i thought this was a good opportunity to try and identify some approved specs which we've missed moving to implemented or abandoned
19:37:57 <fungi> i've picked a few which look promising and we can see how many we get through
19:38:04 <fungi> #link http://specs.openstack.org/openstack-infra/infra-specs/specs/complete-reviewable-release-automation.html Complete Reviewable Release Automation Work
19:38:09 <fungi> dhellmann: i'm pretty sure we can consider this one implemented, right?
19:39:03 <fungi> #action fungi get up with dhellmann about complete-reviewable-release-automation spec
19:39:14 <fungi> #link http://specs.openstack.org/openstack-infra/infra-specs/specs/deploy-stackviz.html Stackviz Deployment
19:39:20 <fungi> austin81: timothyb89: this has been working for a while, i think? should we mark it implemented now?
19:39:52 <clarkb> and we just simplified the installation in d-g too (thanks pabelanger)
19:39:54 <fungi> (or anyone else who happens to know)
19:40:16 <fungi> yeah, i figure that makes it plenty done if we're already refactoring the install mechanism
19:40:22 <pabelanger> indeed!
19:40:28 <clarkb> we didn't implment the central browser service
19:40:43 <clarkb> which is part of that spec, though I wonder how much interest there is in making that happen?
19:40:54 <fungi> might be we revisit the scope there
19:40:57 <fungi> #action fungi get up with austin81 and timothyb89 about deploy-stackviz spec
19:41:05 <fungi> #link http://specs.openstack.org/openstack-infra/infra-specs/specs/ethercalc.html Ethercalc
19:41:08 <fungi> clarkb: we have one of these
19:41:13 <fungi> #link http://ethercalc.openstack.org/
19:41:16 <fungi> i've even used it. implemented, yeah?
19:41:20 <clarkb> yes implemented
19:41:36 <fungi> #agreed ethercalc spec is implemented now
19:41:50 <fungi> #link http://specs.openstack.org/openstack-infra/infra-specs/specs/neutral-governance-website.html Neutral governance website
19:41:54 <fungi> ttx is travelling today, but as far as i can tell this is done. anyone disagree?
19:42:08 <clarkb> +1 to done
19:42:31 <fungi> was pretty much just about moving the tc-specific content into the tc subtree and setting up teh necessary redirects, then letting the uc publish to governance.o.o as well
19:42:47 <fungi> i'll double-check with ttx too when he's around
19:42:50 <fungi> #action fungi get up with ttx about neutral-governance-website spec
19:42:59 <fungi> #link http://specs.openstack.org/openstack-infra/infra-specs/specs/pholio.html Pholio Service Installation
19:43:02 <fungi> it's been up and running for a while, though the ux team sort of dissolved shortly after
19:43:08 <fungi> #link https://pholio.openstack.org/pholio/ pholio service
19:43:40 <fungi> we may want to consider figuring out if anyone in the community has a use for it and take it back down if not, i guess
19:44:01 <clarkb> ++
19:44:19 <fungi> the only outstanding concern i heard (i think from mordred?) was about making sure teh links to the other phab subcomponents were properly disabled/redirected
19:45:26 <mordred> yah. that was my main concern
19:46:22 <mordred> also - we're not exactly over-staffed with humans, so running a service that isn't important to our users seems like extra effort that it's hard to justify
19:47:09 <clarkb> I think this is what the openstack shelve feature is for :)
19:47:29 <mordred> clarkb: ah! finally, a use for it ;)
19:47:45 <mordred> clarkb: you know, we could pause it, snapshot it, then download the image and store it somewhere
19:48:19 <fungi> yeah, looks like nobody has created any mocks under it
19:48:34 <fungi> and i agree it looks like at least maniphest is allowing me to create a new bug report
19:48:46 <fungi> so there's still work to do to lock this down
19:49:31 <mordred> fungi: if nobody has created mocks, I'd vote for spinning it down
19:49:38 <ianw> i spent some time on it before, i can send out a note about it, and start deprecation if required
19:49:44 <ianw> otherwise look at locking it down
19:49:46 <mordred> ianw: ++
19:50:10 <fungi> since nobody is using it (and it was never officially announced because the ux team dissolved while we were waiting for them to get back to us about if it was working the way they wanted) it may not need any announcement
19:51:30 <ianw> i can word it so it's not a question :)
19:52:27 <fungi> ianw: sounds great! you want to take on deleting the server and moving the spec to abandoned too?
19:52:48 <ianw> yep, will do over the next week
19:53:11 <fungi> #action abandon pholio spec and send announcement about discontinuing the (unused) service
19:53:15 <fungi> #undo
19:53:16 <openstack> Removing item from minutes: #action abandon pholio spec and send announcement about discontinuing the (unused) service
19:53:20 <fungi> #action ianw abandon pholio spec and send announcement about discontinuing the (unused) service
19:53:32 <fungi> thanks!
19:53:43 <fungi> #link http://specs.openstack.org/openstack-infra/infra-specs/specs/publish-election-repo.html Publish election repository
19:53:45 <fungi> this is super done, yep?
19:54:21 <clarkb> https://governance.openstack.org/election/ says yes
19:54:38 <fungi> yeah, hard to dispute reality
19:54:58 <fungi> #agreed publish-election-repo is implemented
19:55:29 <fungi> #link http://specs.openstack.org/openstack-infra/infra-specs/specs/releases-openstack-org.html Move docs.openstack.org/releases to releases.openstack.org
19:55:33 <clarkb> you can always reject reality and substitute one in
19:55:45 <Shrews> that's called alcohol
19:55:46 <fungi> i consider that my day job
19:55:55 <clarkb> https://releases.openstack.org/ says this one is done too
19:56:16 <fungi> #link https://releases.openstack.org/
19:56:38 <fungi> yep. there may be more they want that site to have, but it exists insofar as the spec requires
19:56:53 <fungi> #agreed releases-openstack-org spec is implemented
19:57:17 <fungi> #link http://specs.openstack.org/openstack-infra/infra-specs/specs/shade.html shade: A library that understands clouds
19:57:40 <fungi> mordred: ^ i vote that the infra spec is implemented, and future shade specs are handled by its new team
19:57:45 <mordred> fungi: agree
19:57:49 <clarkb> ++
19:58:01 <clarkb> also the listed work items are done I think
19:58:16 <fungi> yeah, seems that way
19:58:18 <fungi> #agreed shade spec is implemented
19:58:51 <fungi> i'll hit the sb team up about possibly implemented specs in their meeting tomorrow
19:58:59 <fungi> oh, here's one more probably easy:
19:59:16 <fungi> #link http://specs.openstack.org/openstack-infra/infra-specs/specs/unified_mirrors.html Unified Mirrors
19:59:26 <pabelanger> :)
19:59:29 <fungi> we're done there, right?
19:59:40 <pabelanger> I'd say yes
19:59:49 <clarkb> its also evolved a bit from there too
19:59:50 <pabelanger> all regions have them
19:59:51 <fungi> some parts of it ended up agandoned
19:59:54 <fungi> abandoned
20:00:08 <fungi> but yeah, implemented enough
20:00:09 <pabelanger> ya, ruby for example
20:00:32 <fungi> we're out of time, but i could use a volunteer to fix up that spec to remove the bits we didn't do
20:00:40 <fungi> get up with me in #openstack-infra
20:00:43 <fungi> thanks everyone!
20:00:47 <fungi> #endmeeting