19:01:25 <ianw> #startmeeting infra
19:01:25 <openstack> Meeting started Tue Jul 10 19:01:25 2018 UTC and is due to finish in 60 minutes.  The chair is ianw. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:28 <openstack> The meeting name has been set to 'infra'
19:01:32 <cmurphy> o/
19:01:46 <corvus> howdy
19:02:12 <ianw> #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting
19:02:24 <ianw> #topic Announcements
19:02:52 <ianw> clarkb & fungi are off doing important things
19:03:08 <ianw> hence bumbling along with me
19:03:21 <fungi> thanks ianw!
19:03:30 * fungi is not really here, but kinda here
19:03:44 * cmurphy squints at fungi
19:03:51 <ianw> #topic Actions from last meeting
19:04:12 <ianw> #link http://eavesdrop.openstack.org/meetings/infra/2018/infra.2018-07-03-19.01.html Minutes from last meeting
19:04:30 <ianw> I don't think we had any particular action items to cover
19:05:01 <ianw> #topic Specs approval
19:05:17 <ianw> #link https://review.openstack.org/#/c/565550/ config mgmt and containers
19:06:19 <ianw> this has been a pretty big focus, and there's been patches flying for various container related things like pbrx, bindep support, and mirror support
19:07:46 <ianw> anyway, i think still some things to discuss but have a look if interested
19:08:19 <ianw> #link https://review.openstack.org/581214 Add anomaly detection in CI/CD jobs specification draft
19:08:45 <ianw> was the other spec that came in, for perusal but is still marked as a draft
19:09:45 <ianw> #topic Priority Efforts
19:10:17 <ianw> if fungi is around, any particular storyboard updates?
19:10:27 <fungi> none i know about
19:10:49 <ianw> #link https://review.openstack.org/#/q/topic:puppet-4+status:open puppet 4 migration changes
19:11:04 <ianw> cmurphy: ^ i've seen lots of patches flying, want to give us a summary?
19:11:15 <cmurphy> sure
19:11:29 <cmurphy> i'm working through this list to try to get some more testing https://etherpad.openstack.org/p/infra-puppet-modules-to-test
19:12:28 <cmurphy> i don't really want to write tests for all of them so help prioritizing them would be good
19:12:50 <cmurphy> otherwise we could start turning on the future parser for some nodes nowish if we want
19:14:22 <cmurphy> i'll probably put up a review to do that for one of the dev sites next week ish and ask infra-root to work through it
19:14:24 <cmurphy> that's about it
19:14:29 <ianw> i guess you don't mind us updating that page?  i had an ethercalc rspec test somewhere
19:14:33 * mordred waves
19:14:40 <cmurphy> ianw: go for it
19:15:45 <ianw> my only thought on priority would be the non-xenial things that have kind of stalled
19:16:36 <cmurphy> as in prioritize getting those to xenial?
19:16:46 <ianw> honestly i can't even quite remember what was still to be done, but i can go back over it, and maybe update that page
19:17:07 <ianw> yes, i think that would be good, to at least try and finish that project
19:17:19 <cmurphy> ++
19:17:51 <ianw> alright, well that sounds like something we can all work on, anything else?
19:18:03 <cmurphy> not from me
19:18:34 <ianw> #topic General topics
19:18:50 <ianw> #link https://etherpad.openstack.org/p/winterscale-service-branding
19:18:58 <ianw> #link http://lists.openstack.org/pipermail/openstack-infra/2018-July/006010.html
19:19:17 <ianw> just calling out clarkb's note above
19:20:14 <ianw> around ideas of what would be "generic" and what could be individually branded under the winterscale initiative
19:21:28 <ianw> re packethost cloud from the agenda
19:21:59 <ianw> we received confirmation a dodgy cable was replaced, and MTU's have been rejiggered (that's the technical term)
19:22:39 <corvus> i'd still like to poke at the idea of running separate gerrits
19:23:11 <corvus> i think there's a significant discussion to be had about that in particular; there are a lot of pros and cons
19:25:08 <ianw> what do you see as the pros?
19:25:24 <fungi> no need for namespacing is the big one, in my opinion
19:25:40 <fungi> separate theming is also a pro
19:25:50 <corvus> there's similar discovery options to git hosting
19:26:48 <corvus> like, you go to review.example.org and you see the proposed changes for the constituent repos of the example project
19:27:12 <corvus> and, i know this is counter-intuitive, but in some ways, sysadmin may be easier
19:27:24 <corvus> it's really easy to run a small gerrit.  it's hard to run a big one.
19:27:26 <fungi> makes sense. in a large and widely-shared instance the default dashboard is somewhat useless
19:27:51 <corvus> if we can make it easy to run *lots* of small gerrits, it may be a net win.  we may be able to avoid the really sophisticated engineering it takes to run a massive gerrit.
19:28:08 <fungi> much like a view of the most recent open pull requests across all of github would be somewhat silly
19:29:04 <corvus> of course, it's valuable to have a place for projects without domains to be.  so -- does winterscale have a winterscale branded gerrit, and also other branded gerrits?  do projects move between them?
19:29:29 <corvus> lot's of problems arise
19:29:34 <ianw> i've always thought https://gerrit-dash-creator.readthedocs.io/en/latest/ was a little underrated
19:29:42 <fungi> yeah, i feel like the ability to relocate projects from one gerrit to another is the biggest piece of the challenge
19:29:58 <corvus> ianw: it's great.  it's not how i want to introduce potential new contributors to zuul
19:32:20 <ianw> are we going to need to handle different contributor agreement type things?
19:32:20 <corvus> anyway, even if we elect to have a single gerrit, it may get so large we need to start adding custom components that work around issues like that
19:32:26 <fungi> we've struggled enough in the past with projects simply wanting to rename between namespaces on a single gerrit, to the point where we put the kibosh on tying namespaces to governance. porting them from one gerrit to another while preserving review history (and contributor accounts?) is significantly harder
19:33:13 <corvus> ianw: i say no, because we will handle no contributor agreement type things
19:33:45 <corvus> my understanding is that the foundation is working to handle accounting of those things external to the code review system
19:33:58 <fungi> beyond maybe the built-in option to reject pushes of commits with no dco signed-off-by footers
19:34:39 <fungi> (the dco is a sort of agreement, but not enforced in the same way)
19:35:36 <corvus> another thing to maybe talk about is -- since we're talking about having lots of whitelabled stuff -- how do we manage domains and ssl certs, etc
19:35:43 <corvus> things could get unweildy fast
19:36:31 <ianw> that's good info, i mean the con to me seems to be having X different logins, but if it's going to be clearly centrally defined that's helpful
19:38:43 <fungi> that was a takeaway mordred had from a hallway discussion in sydney, i think? to write up how we'd do federated/centralized authentication
19:38:44 <ianw> domains seem to be an issue.  i resort to updating via the rax website as often as not
19:39:06 <mordred> yeah. I need to write that up - sorry
19:39:32 <fungi> well, for zuul-ci.org and whatever the winterscale domain ends up being, we can do domain modifications via git/gerrit
19:39:56 <fungi> i feel like we can offer to support that for domains people want to delegate to our nameservers
19:40:22 <fungi> and for people who don't want to delegate their domains to our nameservers, maybe we let the onus be on them to make dns updates?
19:41:04 <fungi> what i don't want is for us to be responsible for renewing random domains with their registrars though
19:41:56 <corvus> ya
19:42:13 <fungi> as for ssl certs, if we do letsencrypt i think maybe we can get by with our configuration management bootstrapping systems by substituting snakeoil certs at the same path until le negotiates
19:42:27 <corvus> that sounds promising
19:42:28 <fungi> but that would need some testing
19:43:06 <fungi> also that only solves the ssl cert problem for systems running web services, though maybe that's "good enough"
19:43:44 <fungi> there was recent news about similar le automation for smtp start-ssl integration though, i haven't dug into detail there yet
19:44:39 <ianw> fungi: if we're also doing your domain's dns, we may be able to work something with dns record based LE approvals?
19:45:10 <fungi> ianw: that's probably at odds with piping dns updates through code review
19:45:37 <fungi> unless we turn on ddns support in the master or something, though that gets challenging to secure
19:46:36 <fungi> problem with the acme dns method, from what i gather, is that the acme client needs the ability to directly insert dns records to perform the negotiation
19:48:54 * mugsie coughs - https://pypi.org/project/certbot-dns-openstack/
19:48:54 <ianw> fungi: i'm interested in this, but need to do some research.  should we carry an action item to come up with something a little more concrete, even just for a POC LE integration for just web to start with?
19:49:33 <fungi> mugsie: would that be compatible with keeping zonefiles in git?
19:49:48 <mugsie> unfortunately not :/
19:49:55 <fungi> ianw: sounds good to me
19:50:18 <mugsie> it creates and deletes records in a few seconds
19:50:42 <fungi> mugsie: other challenge, can it be done without access to a designate service? and how would you recommend splitting the implementation across different cloud providers? federated designate?
19:51:22 <fungi> mostly trying to figure out if and where we can find designates to use for that
19:51:34 <mugsie> federated designate would work. It does need a designate though - it is writen for designate
19:51:43 <mugsie> there is other DNS auth plugins
19:51:58 <fungi> i suppose some separate automation to inject designate api calls to multiple designates in different providers based on updates to a zone file in a git repository
19:53:08 <fungi> or can we slave nameservers we run to a designate-based silent master? then we could put the slaves in separate providers
19:53:29 * fungi is unfortunately not familiar enough with how designate is implemented
19:53:58 <mugsie> fungi: that is how designate works - we have a hidden python dns server used as a master
19:54:29 <fungi> and then users can register their own slaves with the designate master?
19:54:55 <fungi> or is it only possible for the cloud provider/operator to add slaves?
19:55:07 <mugsie> no - that is a admin thing. But admins can create server pools - so depending on how friendly you are wiht your provider, it may be OK
19:55:55 <fungi> reliance on personal relationships is probably not a great cornerstone for designing an infrastructure that random other communities can also replicate if they want
19:56:14 <fungi> but thanks for the ideas, worth keeping in mind
19:56:43 <mordred> fungi: indeed. but - since it's openstack, saying "here's how you can replicate this infrastructure on openstack" seems potentially fair ...
19:56:53 <fungi> true
19:57:03 <mordred> fungi: and in our specific case, being only on public openstack clouds, just getting one or two of them to be friendly might not be too high of a bar
19:57:40 <ianw> #action ianw fungi begin planning for an initial POC for letsencrypt integration
19:57:58 * fungi didn't mean to derail that discussion quite so much, sorry!
19:58:07 <mordred> fungi: fun derailing!
19:58:32 <mugsie> its my fault really :)
19:58:57 <ianw> mugsie: well you just put yourself on the hook to be a consulting partner in all this :)
19:58:57 <mugsie> I saw DNS and ACME fly by in a window
19:59:12 <mugsie> yay?
19:59:15 <ianw> anyway ...
19:59:20 <ianw> #topic Project Renames
19:59:21 <fungi> always appreciate your dns expertise, mugsie
19:59:41 <ianw> last week i think it was decided to not do anything about renames until later in the month
19:59:47 * mordred hands mugsie a fluffy bunny rabbit
19:59:52 <ianw> so, let's do that
20:00:04 <ianw> #topic Open Discussion
20:00:49 <ianw> we're at time, but you can find people in #openstack-infra
20:00:57 <fungi> thanks ianw!
20:01:17 <ianw> #endmeeting