19:01:13 <clarkb> #startmeeting infra 19:01:14 <openstack> Meeting started Tue Jul 3 19:01:13 2018 UTC and is due to finish in 60 minutes. The chair is clarkb. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:17 <openstack> The meeting name has been set to 'infra' 19:01:30 <clarkb> #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting 19:01:43 <clarkb> #topic Announcements 19:01:51 <mordred> o/ 19:02:03 <clarkb> Tomorrow is a US holiday. I'll be afk all day and then doing followup holidaying on thursday as well. 19:02:29 <clarkb> Fungi and I are trveling next week as well 19:02:44 <fungi> i'll be around some tomorrow, but keeping an eye on the smoker will be my priority 19:03:05 <fungi> yeah, i'm travelling monday through friday next week 19:03:16 <fungi> and then i'm disappearing for a couple weeks starting the following wednesday 19:03:24 <clarkb> That means we will need a volunteer to run the infra meeting that isn't Fungi or myself. 19:03:37 <fungi> for my first actual vacation in i can't remember how long. a couple years anyway 19:04:36 <clarkb> #topic Actions from last meeting 19:04:47 <clarkb> #link http://eavesdrop.openstack.org/meetings/infra/2018/infra.2018-06-26-19.01.txt Minutes from last meeting 19:04:49 <ianw> i will also be on PTO a few days next week, including my wednesday when meeting is sorry 19:05:01 <clarkb> ianw: no worries 19:05:17 <clarkb> We had a collective action to review mordreds spec 19:05:24 <clarkb> why don't we just jump ahead to that 19:05:30 <clarkb> #topic Specs approval 19:05:39 <clarkb> #link https://review.openstack.org/#/c/565550/ config mgmt and containers 19:05:49 <cmurphy> o/ 19:05:52 * mordred wrote some words 19:05:56 <clarkb> I've reviewed it. I personally like the incremental approach it describes 19:06:19 <mordred> corvus: I updated it a little since last you reviewed/voted 19:06:40 <clarkb> have others had a chance to review it as well? and if so how do we feel about continuing to push on it? is it ready to be put up for approval? 19:06:43 <corvus> mordred: oh cool -- enough i should re-review? 19:06:44 <cmurphy> https://review.openstack.org/#/c/449933/ is still there though it's pretty close to done at this point 19:06:55 <mordred> corvus: it should be a quick re-review 19:07:02 <corvus> cool, will do today 19:07:58 <clarkb> mordred: if you spec doesn't have a "this is how to puppet 4" link in it yet (I don't recall) we should add one to ^ 19:08:10 <clarkb> and probably merge those together 19:08:15 <mordred> I *think* I copied in the relevant text from the puppet4 spec 19:08:51 <clarkb> ah ok so truly a merged/converged spec. cmurphy are you comfortable with tracking that work as part of the larger scope spec? 19:08:53 <mordred> it definitely has the work items - and cmurphy as a co-author 19:09:03 <cmurphy> oh sure, I will look at it 19:09:13 <mordred> I didn't change any of cmurphy's words 19:09:31 <mordred> or, at least not many 19:10:49 <clarkb> As a rough poll how many have managed to review it? I think corvus and myself and mordred is auther I know about so far. Do we need more time to review it? <- cmurphy fungi ianw. pabelanger this might be one you'd have some interest in looking at as well? 19:11:12 <fungi> i, er, did pull it up to start reading a couple days ago but... 19:11:18 <cmurphy> I haven't looked yet, will do so 19:11:54 <clarkb> ok I don't think we are ready to put it up for approval this week then. Considering the amount of travel and time off between now and next week do we want to aim for week after? that should give us plenty of time 19:11:57 <fungi> it's the most recent non-emergency review in my gertty stack 19:12:15 <mordred> wfm 19:12:20 <clarkb> July 17 19:12:30 <mordred> also - feel free to poke me with questions or whatnot 19:13:05 <Shrews> mordred: considering we have a zuul spec suggesting the use k8s, do we want to reconsider using docker for that (just for merging of brain space) 19:13:37 <clarkb> Shrews: the spec as is is largely a precursor to being able to use k8s 19:13:42 <clarkb> by getting the image management done first 19:14:13 <clarkb> (I think the zuul work is compatible with this spec given that) 19:14:52 <mordred> yes, this is true - there's also some words in the more recent version that talk about cri-o+k8s briefly and on docker as a temporary expedience 19:15:00 <Shrews> nod. not being familiar with k8s, wasn't sure if there was overlap 19:15:07 <corvus> mordred sometimes calls k8s a 'container orchestration engine (coe)' in the spec and suggests that we could potentially use that later after what clarkb says 19:15:34 <corvus> (so, sometimes it heps to read coe as k8s) 19:16:00 <corvus> (or openshift or...) 19:16:26 <fungi> shiftynetes 19:17:14 <clarkb> I'll send out an email to the infra list asking fo rreviews as well with a plan to put it up for approval on the 17th (two weeks from today) 19:17:41 <clarkb> any other questions or feedback for mordred before we move on? 19:18:00 <mordred> also - if anyone gets bored ... 19:18:35 <mordred> grab the openstack/pbrx repo and try the 'pbrx build-images' command out 19:19:08 <mordred> it currently would like some of the bindep depends marked with a 'build' tag (since install, build and test are all potentially different things) 19:19:09 <clarkb> mordred: do the repos need to be preconfigured to make that work? or should it work on any pbr using setup.py project? 19:19:20 <mordred> it should work for any pbr+bindep repo 19:19:50 <mordred> with some caveats about maybe some extra tags in bindep.txt - or we might want to consider what we're communicating via bindep ... 19:20:12 <mordred> but I'd love feedback from folks on that - so we can maybe write up some docs on how to use it , etc 19:20:24 <mordred> or that it's a stupid idea and we should do something completely different 19:20:45 <corvus> can we make zuul jobs that use it to build zuul images yet? 19:20:51 <mordred> sure 19:21:08 <corvus> cool, that might be fun to play with, and is a start on the spec work too 19:21:09 <mordred> I mean - those jobs would likely want to install it from source at the moment 19:21:11 <clarkb> semi related to that there is a bindep change up to add alpine support 19:21:28 <clarkb> swift is pushing on that, but could be useful in the combination of docker images + pbr + bindep 19:21:57 <mordred> cool. that would allow us to use the python:slim base image instead of the python base image 19:22:30 <clarkb> #link https://review.openstack.org/#/c/579056/ alpine support in bindep 19:22:38 <clarkb> I've reviewed an older patchset and should rereview it 19:22:58 <mordred> same here 19:23:09 <corvus> alpine's packages manager is called apk? that's not confusing at all. 19:23:14 <clarkb> corvus: yes and yes 19:23:25 <mordred> s/python:slim/python:alpine/ 19:23:26 <fungi> apk is going to be my new apt typo 19:23:46 <mordred> python:slim is also fine - and is debian based 19:23:51 <mordred> it's the default right now 19:24:04 <corvus> we don't have alpine images in nodepool do weL 19:24:05 <corvus> ? 19:24:12 <clarkb> corvus: correct 19:24:19 <mordred> not to my knowledge - but we don't need them if we make alpine container images :) 19:25:03 <clarkb> in any case reviewers should check that the version parsing in particular is correct (I'm not convinced yet and will focus on that myself) 19:25:11 <corvus> do we want to make landing that contingent on some kind of real testing? (i'm really asking: what is/should be/ our testing requirements for bindep platforms?) 19:25:27 <mordred> corvus: that's an excellent question 19:25:47 <clarkb> corvus: we've already accepted support for platforms like Arch without "real" testing 19:26:02 <clarkb> the unit test framework is fairly robust as long as you have the package manager output correct in the mocks 19:26:04 <corvus> otoh, i recall lots of gentoo effort going into real testing 19:26:12 <fungi> and macports or brew or something too, right? 19:26:16 <clarkb> fungi: yes 19:26:35 <clarkb> also we've switched to the distro library for identifying distros which means we have to worry less about that 19:26:35 <corvus> ok. so the policy is "get the mocks right". wfm. 19:27:00 <fungi> so strictly speaking we haven't insisted on automatable testing for every platform implemented, just the ones where we already had those platforms available in nodepool 19:27:16 <corvus> (i mean nodepool's policy is mostly "get the fakes right", with a few key things real-tested) 19:27:31 <fungi> certainly if we _did_ get alpine-based vm or container images, we'd want to add a bindep job 19:28:26 <clarkb> Last call for spec related items 19:28:36 <mordred> also - if we make a zuul job to build alpine-based zuul container images using pbrx - we could totaly run that job on bindep changes too :) 19:29:50 <clarkb> #topic Priority Efforts 19:30:27 <clarkb> The puppet 4 work is related to the previously mentioned spec and so will get added as a priority effort soon (I expect). Considering that it would be helpful if others can review topic:puppet-4 19:30:49 <clarkb> I'm happy to be the babysitter of those changes if we can get reviews. Feel free to ping me if you are +2 but can't watch it 19:31:47 <clarkb> fungi: Any storyboard items for today? 19:32:32 <clarkb> #link https://review.openstack.org/#/q/topic:puppet-4+status:open puppet 4 migration changes 19:32:43 <fungi> oh, yep, sorry a friend was just dropping off the pork belly for tomorrow 19:33:39 <fungi> looks like we ended up not having a sb meeting last week 19:34:10 <corvus> fungi: good friend 19:34:17 <clarkb> Now I want pork belly 19:34:36 <fungi> not much to report, no. fatema (our outreachy intern) could use some help with a sql migration according to channel scrollback 19:34:55 <fungi> i'm also still poking at the decoding issue with slashes in project names for the name-based project pages 19:35:04 <fungi> not having much luck debugging the api though 19:35:27 <fungi> and we had a few wishlist items crop up 19:35:31 <fungi> that's pretty much it 19:35:57 <clarkb> ok, thanks. Looks like dhellmann was trying to help with the sql migration (thank you!) 19:36:11 <clarkb> #topic General topics 19:37:03 <clarkb> As a followup to winterstack naming. I've been asked if the foundation can take a week or two to get the creative team's input on what we have on the ehterpad. 19:37:29 <clarkb> I expect that mid July will be whne we start to push on that again (all the things in mid july I guess) 19:37:46 <fungi> also starting to get internal questions from foundation staff on what sorts of things are going to have the option of being whitelabeled 19:38:37 <fungi> questions ultimately coming from other new pilot project communities via foundation staff liaisons (who are encouraging those communities to get in touch with the infra team more directly if they have actual questions) 19:39:27 <fungi> they've been getting pushed to e-mailing actual community infrastructure questions to the openstack-infra@l.o.o ml 19:39:39 <fungi> so i've been trying to get a little more diligent on watching the moderation queue 19:39:45 <clarkb> fungi: thanks. 19:39:54 <fungi> but if anyone else is interested in pitching in on that, please let me know 19:40:15 <clarkb> re whitelabeling maybe we should draft up a listing of services and provisional future naming state (I'm happy to put up a first draft list and we can refine from there) 19:40:28 <clarkb> will probably be useful for us as well as our usres to get a rough idea of what goes where 19:40:54 <corvus> yeah, and i think that's a relevant question for existing services/communities too. 19:40:54 <fungi> that sounds good, i expect most of those would be entries for future specs 19:41:27 <corvus> i'm very keen to talk more about what our gerrit offering looks like :) 19:41:54 <fungi> like, an example which came up earlier today, whitelabeled eavesdrop vhosts filtered to community-specific channel and meeting lists. probably doable but we'd want a spec for that and may also want to make it dependent on the irc bot refactor spec 19:42:05 <corvus> i'm just not sure we're quite at the point of having gerrit be a productive conversation yet 19:42:54 <fungi> and ideally, for some of these services communities want whitelabeled, they'd step forward with people to do the bulk of that work 19:43:10 <corvus> right. that, like gerrit, is also very difficult to talk about without knowing what winterscale looks like exactly -- do we still care about whitelabling so much if we have a better name? 19:43:26 <fungi> exactly 19:43:32 <corvus> (or do we not care so much about a better name because everything will be whitelabeled?) 19:43:34 <clarkb> in general I've been assuming we don't 19:43:34 <fungi> a more timely example might be mailman3 19:44:29 <fungi> it looks like it has built-in support for whitelabelling the listserv (mailman3) itself and the archiver (hyperkitty), but not for the management webui (postorius). it may be that non-whitelabeled postorius is just fine on a neutral domain name 19:44:30 <clarkb> in part because I'm selfish and it is less work but also because people seem ok with servies like bitbucket and github operating in a similar manner 19:46:19 <mordred> yah - mailing lists seem to be where I'd expect more people to have whitelabel interest 19:46:20 <clarkb> I'll try to work up a rough draft maybe that we could declare as an ideal with the caveat reality may force changes 19:46:23 <mordred> once we have a name 19:46:40 <fungi> thanks clarkb! 19:47:05 <clarkb> As an update on packethost we've been told that bad cables have been replaced. John is working to get the MTU situation sorted out as well before we turn it back on again 19:47:17 <clarkb> Hopefully we can run jobs there soon 19:47:30 <fungi> and vexxhost is back in the pool again, right? 19:47:46 <clarkb> yes vexxhost ipv6 issues got sorted out and I turned it back on again late yesterday 19:47:55 <fungi> excellent 19:48:30 <clarkb> #topic project renames 19:49:38 <clarkb> Really quickly before we run out of time we have had a couple project renames floated by us. I'm in no position to drive that for a while (just with travel and other commitments). For some reason I'm not finding our release calendar 19:50:02 <clarkb> there it is , https://releases.openstack.org/rocky/schedule.html 19:50:05 <corvus> https://releases.openstack.org/rocky/schedule.html 19:50:37 <clarkb> End of this month seems like a possibility 19:51:14 <corvus> aw can't we do it mid-july like everything else? :) 19:51:21 <clarkb> boo :P 19:51:37 <clarkb> lets see where we are at on the 17th and maybe we can do it end of july? 19:52:13 <fungi> that would be cool 19:52:24 <fungi> i know the api sig has been waiting a little while 19:52:55 <clarkb> #topic Open Discussion 19:52:56 <fungi> and i think tripleo-ci is the only remaining non-infra-team repo in the openstack-infra namespace once release-tools retirement completes 19:53:10 <clarkb> #undo 19:53:11 <openstack> Removing item from minutes: #topic Open Discussion 19:53:13 <clarkb> Sorry 19:53:22 <fungi> that was all i had. no worries 19:53:33 <clarkb> fungi: also tripleo-ci bumps the renames up to >1 which makes it less painful 19:53:39 <fungi> yep 19:53:47 <clarkb> Anyways lets talk about it once we get past the first half of this month 19:53:55 <clarkb> #topic Open Discussion 19:53:59 <clarkb> Any now, anything else 19:54:26 <fungi> i need to go start soaking a bunch of applewood for tomorrow morning 19:55:09 <clarkb> I've got to clean out my smoker 19:55:32 <fungi> brisket? 19:55:36 <clarkb> ribs 19:55:40 <clarkb> also going to grill burgers 19:55:42 <fungi> yessss 19:55:51 <fungi> i should do some ribs soonish 19:56:58 <clarkb> seems like that may be it. Enjoy the holiday if it is a holiday in your part of the world. Thanks everyone 19:57:00 <clarkb> #endmeeting