19:01:25 #startmeeting infra 19:01:25 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:28 The meeting name has been set to 'infra' 19:01:32 o/ 19:01:46 howdy 19:02:12 #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting 19:02:24 #topic Announcements 19:02:52 clarkb & fungi are off doing important things 19:03:08 hence bumbling along with me 19:03:21 thanks ianw! 19:03:30 * fungi is not really here, but kinda here 19:03:44 * cmurphy squints at fungi 19:03:51 #topic Actions from last meeting 19:04:12 #link http://eavesdrop.openstack.org/meetings/infra/2018/infra.2018-07-03-19.01.html Minutes from last meeting 19:04:30 I don't think we had any particular action items to cover 19:05:01 #topic Specs approval 19:05:17 #link https://review.openstack.org/#/c/565550/ config mgmt and containers 19:06:19 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 anyway, i think still some things to discuss but have a look if interested 19:08:19 #link https://review.openstack.org/581214 Add anomaly detection in CI/CD jobs specification draft 19:08:45 was the other spec that came in, for perusal but is still marked as a draft 19:09:45 #topic Priority Efforts 19:10:17 if fungi is around, any particular storyboard updates? 19:10:27 none i know about 19:10:49 #link https://review.openstack.org/#/q/topic:puppet-4+status:open puppet 4 migration changes 19:11:04 cmurphy: ^ i've seen lots of patches flying, want to give us a summary? 19:11:15 sure 19:11:29 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 i don't really want to write tests for all of them so help prioritizing them would be good 19:12:50 otherwise we could start turning on the future parser for some nodes nowish if we want 19:14:22 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 that's about it 19:14:29 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 ianw: go for it 19:15:45 my only thought on priority would be the non-xenial things that have kind of stalled 19:16:36 as in prioritize getting those to xenial? 19:16:46 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 yes, i think that would be good, to at least try and finish that project 19:17:19 ++ 19:17:51 alright, well that sounds like something we can all work on, anything else? 19:18:03 not from me 19:18:34 #topic General topics 19:18:50 #link https://etherpad.openstack.org/p/winterscale-service-branding 19:18:58 #link http://lists.openstack.org/pipermail/openstack-infra/2018-July/006010.html 19:19:17 just calling out clarkb's note above 19:20:14 around ideas of what would be "generic" and what could be individually branded under the winterscale initiative 19:21:28 re packethost cloud from the agenda 19:21:59 we received confirmation a dodgy cable was replaced, and MTU's have been rejiggered (that's the technical term) 19:22:39 i'd still like to poke at the idea of running separate gerrits 19:23:11 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 what do you see as the pros? 19:25:24 no need for namespacing is the big one, in my opinion 19:25:40 separate theming is also a pro 19:25:50 there's similar discovery options to git hosting 19:26:48 like, you go to review.example.org and you see the proposed changes for the constituent repos of the example project 19:27:12 and, i know this is counter-intuitive, but in some ways, sysadmin may be easier 19:27:24 it's really easy to run a small gerrit. it's hard to run a big one. 19:27:26 makes sense. in a large and widely-shared instance the default dashboard is somewhat useless 19:27:51 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 much like a view of the most recent open pull requests across all of github would be somewhat silly 19:29:04 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 lot's of problems arise 19:29:34 i've always thought https://gerrit-dash-creator.readthedocs.io/en/latest/ was a little underrated 19:29:42 yeah, i feel like the ability to relocate projects from one gerrit to another is the biggest piece of the challenge 19:29:58 ianw: it's great. it's not how i want to introduce potential new contributors to zuul 19:32:20 are we going to need to handle different contributor agreement type things? 19:32:20 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 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 ianw: i say no, because we will handle no contributor agreement type things 19:33:45 my understanding is that the foundation is working to handle accounting of those things external to the code review system 19:33:58 beyond maybe the built-in option to reject pushes of commits with no dco signed-off-by footers 19:34:39 (the dco is a sort of agreement, but not enforced in the same way) 19:35:36 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 things could get unweildy fast 19:36:31 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 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 domains seem to be an issue. i resort to updating via the rax website as often as not 19:39:06 yeah. I need to write that up - sorry 19:39:32 well, for zuul-ci.org and whatever the winterscale domain ends up being, we can do domain modifications via git/gerrit 19:39:56 i feel like we can offer to support that for domains people want to delegate to our nameservers 19:40:22 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 what i don't want is for us to be responsible for renewing random domains with their registrars though 19:41:56 ya 19:42:13 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 that sounds promising 19:42:28 but that would need some testing 19:43:06 also that only solves the ssl cert problem for systems running web services, though maybe that's "good enough" 19:43:44 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 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 ianw: that's probably at odds with piping dns updates through code review 19:45:37 unless we turn on ddns support in the master or something, though that gets challenging to secure 19:46:36 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 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 mugsie: would that be compatible with keeping zonefiles in git? 19:49:48 unfortunately not :/ 19:49:55 ianw: sounds good to me 19:50:18 it creates and deletes records in a few seconds 19:50:42 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 mostly trying to figure out if and where we can find designates to use for that 19:51:34 federated designate would work. It does need a designate though - it is writen for designate 19:51:43 there is other DNS auth plugins 19:51:58 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 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 fungi: that is how designate works - we have a hidden python dns server used as a master 19:54:29 and then users can register their own slaves with the designate master? 19:54:55 or is it only possible for the cloud provider/operator to add slaves? 19:55:07 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 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 but thanks for the ideas, worth keeping in mind 19:56:43 fungi: indeed. but - since it's openstack, saying "here's how you can replicate this infrastructure on openstack" seems potentially fair ... 19:56:53 true 19:57:03 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 #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 fungi: fun derailing! 19:58:32 its my fault really :) 19:58:57 mugsie: well you just put yourself on the hook to be a consulting partner in all this :) 19:58:57 I saw DNS and ACME fly by in a window 19:59:12 yay? 19:59:15 anyway ... 19:59:20 #topic Project Renames 19:59:21 always appreciate your dns expertise, mugsie 19:59:41 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 so, let's do that 20:00:04 #topic Open Discussion 20:00:49 we're at time, but you can find people in #openstack-infra 20:00:57 thanks ianw! 20:01:17 #endmeeting