19:03:08 #startmeeting infra 19:03:09 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:03:13 The meeting name has been set to 'infra' 19:03:16 #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting 19:03:18 #topic Announcements 19:03:22 i don't think i have anything super important to announce this week 19:03:25 as always, feel free to hit me up with announcements you want included in future meetings 19:03:28 o/ 19:03:32 #topic Actions from last meeting 19:03:38 #link http://eavesdrop.openstack.org/meetings/infra/2017/infra.2017-05-30-19.03.html Minutes from last meeting 19:03:41 fungi propose a help-wanted section to our specs index for unassigned specs 19:03:48 done, i'll cover it under the next topic, which is... 19:03:54 #topic Specs approval - ADMIN: Add a help-wanted section (fungi) 19:04:02 #link https://review.openstack.org/471149 Add a help-wanted section 19:04:08 basically just wanted to try and get some consensus in meeting that this is an okay implementation of the idea 19:04:16 i don't personally think it merits a lengthy council rollcall since it's just reorganizing the index a little 19:04:59 ++ 19:05:04 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 TristanC picked up one yesterday, so i updated the change to no longer move that one (the nodepool drivers spec) 19:06:06 I voted +1 +1 on the change already 19:06:20 i saw, much appreciated! 19:06:44 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 #topic Priority Efforts - Ansible Puppet Apply: Done? (fungi) 19:07:42 #link http://specs.openstack.org/openstack-infra/infra-specs/specs/ansible_puppet_apply.html Ansible Puppet Apply 19:07:47 the story linked from this had only one task and it's marked as merged 19:07:52 puppetdb reporting mentioned as part of the proposed change hasn't been completed yet 19:07:59 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 anybody feel strongly that we should keep it open/active until that's solved? 19:08:51 i think it'll be easier to fix that part if we upgrade puppet 19:08:59 yes ;) 19:09:07 feels done to me 19:09:22 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 or is it still getting hashed out in review? 19:10:21 fungi: the proposal is finished but i'm having concerns about getting participation on reviews 19:10:50 and if there's a new spec to move some things over to pure ansible then this seems less urgent 19:11:28 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 cmurphy: fwiw the spec is in merge conflict 19:12:30 probably because of the change i just merged 19:12:40 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 this one? https://review.openstack.org/#/c/449933 19:12:45 I agree 19:13:05 the help-wanted change likely generated a fair number of merge conflicts over the specs index 19:13:37 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 #agreed ansible_puppet_apply spec can be marked implemented 19:14:13 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 cmurphy: yah 19:14:28 so yes i agree that moving toward something that people want to work on is worthwhile 19:14:42 ++ 19:15:25 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 fungi: ++ 19:15:30 that too 19:15:56 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 is (was) the beaker-based testing catching bugs we were missing in our apply tests? 19:16:58 why are they hard to fix? just a lot of dependencies? 19:17:06 or something deeper? 19:17:26 fungi: yes, they were able to catch a class of bug only found when actually applying puppet not in noop mode 19:17:28 fungi: i think there's been a few times they caught real bugs, though hard to say lately 19:17:55 idempotency being one 19:18:31 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 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 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 cmurphy: yes (sorry, was afk) 19:20:05 fungi: it crept up on us because we left them nonvoting 19:20:31 they were voting on at least some modules i thought 19:20:38 o/ 19:20:44 cmurphy: ahh, yeah ... a lot of churn to cover 19:21:48 am i misremembering, or did something cause us to switch them back to nonvoting across the board? 19:22:04 i think puppet-cgit has voting centos beaker jobs 19:22:10 i don't remember if there are others 19:23:47 didn't mean to derail the spec approval topic, we can come back to this later 19:24:02 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 i can try to summarize the various points raised in a starter message and see where the discussion goes 19:25:16 sounds good 19:25:19 #action fungi start an infra ml thread about puppet 4, beaker jobs and the future of infra configuration management 19:25:46 thanks cmurphy! i hadn't realized things were in quite the state they are on this 19:26:04 #topic Priority Efforts - A Task Tracker for OpenStack: Assignees? (fungi) 19:26:09 #link http://specs.openstack.org/openstack-infra/infra-specs/specs/task-tracker.html A Task Tracker for OpenStack 19:26:15 diablo_rojo has been the defacto phase 1 coordinator/facilitator on this for a while now 19:26:22 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 #action fungi get up with diablo_rojo about task-tracker spec assignment 19:27:48 :) 19:28:18 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 *nod* 19:28:45 #topic Priority Efforts - Gerrit 2.13 Upgrade: Stalled? (fungi) 19:28:52 #link http://specs.openstack.org/openstack-infra/infra-specs/specs/gerrit-2.13.html Gerrit 2.13 Upgrade 19:28:57 zaro is listed as the assignee on this (and did some awesome preliminary testing, thanks!) 19:29:02 but his employment situation has left him with limited time to help on it lately 19:29:07 clarkb has prodded at it a bit more recently too 19:29:14 also gerrit 2.14 has been out for a couple months now, looks like so maybe we should be evaluating that? 19:29:22 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 the summit and prep for summit let out all the steam I had on this 19:30:04 I should pick it back up again, its just hard because gerrit :) 19:30:35 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 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 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 though *some* amount of testing with zuul should be done. especially if we move to newer gerrit 19:31:19 so mostly just want to be sure we have a process and its tested and measured before we go to production 19:31:34 i've seen some gerrit-compatability patches for zuul recently but haven't really kept track of what versions were involved 19:31:35 jeblair: luckily tobiash already found us one zuul+newer-gerrit bug :) 19:31:37 jeblair: agreed, I think we can just run noop jobs out of a virtualenv to start though 19:32:13 of course maybe we want to go to 2.14 instead of 2.13 and get a new war up? 19:32:32 its probably not a bad idea otherwise our next upgrade will be even further behind 19:32:37 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 2.14 requires java 8 - do we have that? 19:32:46 mordred: oh on xenial we do 19:32:51 so maybe we stick with 2.13 then 19:32:59 yah. otherwise it's a host change too 19:33:18 i can help out with the zuul testing part if needed 19:33:22 given that my preference is definitely 2.13 to reduce complexity 19:33:25 well, or a somewhat distasteful in-place distro upgrade like we did/are doing for lists.o.o 19:33:43 (to avoid a host replacement) 19:33:55 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 in place wasn't too bad :) 19:35:05 all things considered, debian (and by extension ubuntu) does manage to make in-place upgrading not too painful, agreed 19:35:28 clarkb: sounds good to me 19:35:53 #action clarkb finish writing up an upgrade doc for gerrit 2.11 to 2.13 19:35:57 thanks! 19:36:01 fwiw, 2.14 includes polygerrit - and I also see things in the rest api docs about "robot comments" 19:36:43 i for one welcome our new robot overlords (as long as they adhere to the three laws) 19:36:50 fungi: ++ 19:36:57 fungi: is one of the three laws "don't break any of the laws" 19:37:33 that's sort of the zeroth law, but... 19:37:37 #topic Specs Cleanup (fungi) 19:37:44 #link http://specs.openstack.org/openstack-infra/infra-specs/ OpenStack Project Infrastructure Design Specifications 19:37:51 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 i've picked a few which look promising and we can see how many we get through 19:38:04 #link http://specs.openstack.org/openstack-infra/infra-specs/specs/complete-reviewable-release-automation.html Complete Reviewable Release Automation Work 19:38:09 dhellmann: i'm pretty sure we can consider this one implemented, right? 19:39:03 #action fungi get up with dhellmann about complete-reviewable-release-automation spec 19:39:14 #link http://specs.openstack.org/openstack-infra/infra-specs/specs/deploy-stackviz.html Stackviz Deployment 19:39:20 austin81: timothyb89: this has been working for a while, i think? should we mark it implemented now? 19:39:52 and we just simplified the installation in d-g too (thanks pabelanger) 19:39:54 (or anyone else who happens to know) 19:40:16 yeah, i figure that makes it plenty done if we're already refactoring the install mechanism 19:40:22 indeed! 19:40:28 we didn't implment the central browser service 19:40:43 which is part of that spec, though I wonder how much interest there is in making that happen? 19:40:54 might be we revisit the scope there 19:40:57 #action fungi get up with austin81 and timothyb89 about deploy-stackviz spec 19:41:05 #link http://specs.openstack.org/openstack-infra/infra-specs/specs/ethercalc.html Ethercalc 19:41:08 clarkb: we have one of these 19:41:13 #link http://ethercalc.openstack.org/ 19:41:16 i've even used it. implemented, yeah? 19:41:20 yes implemented 19:41:36 #agreed ethercalc spec is implemented now 19:41:50 #link http://specs.openstack.org/openstack-infra/infra-specs/specs/neutral-governance-website.html Neutral governance website 19:41:54 ttx is travelling today, but as far as i can tell this is done. anyone disagree? 19:42:08 +1 to done 19:42:31 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 i'll double-check with ttx too when he's around 19:42:50 #action fungi get up with ttx about neutral-governance-website spec 19:42:59 #link http://specs.openstack.org/openstack-infra/infra-specs/specs/pholio.html Pholio Service Installation 19:43:02 it's been up and running for a while, though the ux team sort of dissolved shortly after 19:43:08 #link https://pholio.openstack.org/pholio/ pholio service 19:43:40 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 ++ 19:44:19 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 yah. that was my main concern 19:46:22 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 I think this is what the openstack shelve feature is for :) 19:47:29 clarkb: ah! finally, a use for it ;) 19:47:45 clarkb: you know, we could pause it, snapshot it, then download the image and store it somewhere 19:48:19 yeah, looks like nobody has created any mocks under it 19:48:34 and i agree it looks like at least maniphest is allowing me to create a new bug report 19:48:46 so there's still work to do to lock this down 19:49:31 fungi: if nobody has created mocks, I'd vote for spinning it down 19:49:38 i spent some time on it before, i can send out a note about it, and start deprecation if required 19:49:44 otherwise look at locking it down 19:49:46 ianw: ++ 19:50:10 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 i can word it so it's not a question :) 19:52:27 ianw: sounds great! you want to take on deleting the server and moving the spec to abandoned too? 19:52:48 yep, will do over the next week 19:53:11 #action abandon pholio spec and send announcement about discontinuing the (unused) service 19:53:15 #undo 19:53:16 Removing item from minutes: #action abandon pholio spec and send announcement about discontinuing the (unused) service 19:53:20 #action ianw abandon pholio spec and send announcement about discontinuing the (unused) service 19:53:32 thanks! 19:53:43 #link http://specs.openstack.org/openstack-infra/infra-specs/specs/publish-election-repo.html Publish election repository 19:53:45 this is super done, yep? 19:54:21 https://governance.openstack.org/election/ says yes 19:54:38 yeah, hard to dispute reality 19:54:58 #agreed publish-election-repo is implemented 19:55:29 #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 you can always reject reality and substitute one in 19:55:45 that's called alcohol 19:55:46 i consider that my day job 19:55:55 https://releases.openstack.org/ says this one is done too 19:56:16 #link https://releases.openstack.org/ 19:56:38 yep. there may be more they want that site to have, but it exists insofar as the spec requires 19:56:53 #agreed releases-openstack-org spec is implemented 19:57:17 #link http://specs.openstack.org/openstack-infra/infra-specs/specs/shade.html shade: A library that understands clouds 19:57:40 mordred: ^ i vote that the infra spec is implemented, and future shade specs are handled by its new team 19:57:45 fungi: agree 19:57:49 ++ 19:58:01 also the listed work items are done I think 19:58:16 yeah, seems that way 19:58:18 #agreed shade spec is implemented 19:58:51 i'll hit the sb team up about possibly implemented specs in their meeting tomorrow 19:58:59 oh, here's one more probably easy: 19:59:16 #link http://specs.openstack.org/openstack-infra/infra-specs/specs/unified_mirrors.html Unified Mirrors 19:59:26 :) 19:59:29 we're done there, right? 19:59:40 I'd say yes 19:59:49 its also evolved a bit from there too 19:59:50 all regions have them 19:59:51 some parts of it ended up agandoned 19:59:54 abandoned 20:00:08 but yeah, implemented enough 20:00:09 ya, ruby for example 20:00:32 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 get up with me in #openstack-infra 20:00:43 thanks everyone! 20:00:47 #endmeeting