14:00:26 <mattmceuen> #startmeeting airship 14:00:27 <openstack> Meeting started Tue Oct 29 14:00:26 2019 UTC and is due to finish in 60 minutes. The chair is mattmceuen. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:30 <openstack> The meeting name has been set to 'airship' 14:00:32 <mattmceuen> #topic Rollcall 14:00:40 <dwalt> o/ 14:00:43 <michael-beaver> o/ 14:00:46 <pramchan> o/ 14:00:59 <mattmceuen> https://etherpad.openstack.org/p/airship-meeting-2019-10-29 14:01:19 <alexanderhughes> o/ 14:01:21 <mattmceuen> please add anything to discuss to today's agenda^ -- we'll give it a minute or two 14:01:33 * ildikov is lurking 14:01:37 <nishantkr> o/ 14:01:45 <roman_g> o/ 14:01:50 <ian-pittwood> o/ 14:02:00 <kskels> o/ 14:02:15 <seaneagan> o/ 14:02:26 <mattmceuen> ok let's get started 14:02:30 <mattmceuen> #topic Enforcement of 2x CR +2 before allowing WF +1 14:02:49 <mattmceuen> roman_g - this one's yours, take it away 14:02:59 <dukov> o/ 14:03:13 <mattmceuen> GM / GE all :) 14:03:37 <roman_g> Ah. 14:03:40 <pramchan> Is anyone reviewing https://review.opendev.org/#/c/683165/27 to give +2 for this ? 14:03:56 <roman_g> Yes. So it's all written in etherpad. 14:04:05 <pramchan> thamks 14:04:16 <mattmceuen> pramchan: want to add that one to the Review Request part of the agenda 14:04:19 <roman_g> Do we want to enforce rule of 2x WF+2 from cores? 14:04:26 <mattmceuen> I have an opinion on this 14:04:50 <mattmceuen> I prefer documenting and communicating our convention about 2x WF+2 14:05:10 <kskels> I kind a feel that our current ways of working with "soft" enforcement/awareness has been working great 14:05:14 <mattmceuen> We haven't done a good job of documenting core responsibilities / role in general, so far we have mostly relied on "do it like openstack does it" 14:05:49 <roman_g> We have had changes being merged without this rule followed. 14:05:58 <mattmceuen> If we do a good job of documenting/communicating/following our "convention", then the ability to 1x WF+2 a patch -- in case of some emergency -- will come in handy occasionally 14:06:01 <mattmceuen> Agree roman_g 14:06:03 <pramchan> what does 2x WF_2 mean , you mean two 2_ fro code review for approval? 14:06:14 <mattmceuen> I followed up on that, and it was due to miscommunication / misunderstanding 14:06:20 <roman_g> pramchan yes, that's what I mean 14:06:32 <pramchan> ok thanks 14:06:32 <mattmceuen> Except in one case -- me :) -- where I fully documented they "why" of a single-+2 in the patchset 14:06:37 <ian-pittwood> Do we check if they're non-author +2's already as well? 14:07:05 <mattmceuen> That's definitely a convention ian-pittwood, I don't think it's enforced programmatically 14:07:08 <mattmceuen> afaik 14:07:39 <alexanderhughes> it's not but I think it's a convention that gets bent from time to time. especially on projects with low activity like spyglass/pegleg 14:08:08 <alexanderhughes> with only a handful of cores, when the stars align and 2 of them are out for a day a patchset just isn't going to move 14:08:14 <ian-pittwood> Yeah I know that 14:08:23 <ian-pittwood> I just don't like that we can or have to approve our own material 14:08:42 <mattmceuen> I definitely think that, if we document a convention and allow "break glass in case of emergency" exception to that rule, it should be required that the reviewer add in strong justification into the patchset 14:08:54 <alexanderhughes> +1 14:08:54 <portdirect> ++ 14:08:57 <mattmceuen> and that if the justification is missing, or anyone disagrees with it, we discuss it in the open 14:09:01 <ian-pittwood> Sure, that works 14:09:13 <portdirect> This is the way every openstack project has done it 14:09:16 <mattmceuen> roman_g: do you think that is sufficient? 14:09:19 <ian-pittwood> WF seems like it should definitely be non-author though 14:09:34 <portdirect> Wf with two plus two's can be author 14:09:37 <roman_g> OK. So we leave it as-is, and teach those who break rules w/o reason 14:09:59 <roman_g> mattmceuen, yes, sufficient 14:10:19 <mattmceuen> Yes. dukov shared the openstack-ansible core guidelines as a good example, I think we could start with those and enhance a bit -- dukov, can you please share them here? 14:10:24 <howell> this is probably not doable, but can Zuul post customized comments in response to things like this? 14:10:51 <mattmceuen> that's beyond my zuul brainpower howell :D good question 14:10:51 <portdirect> If we need to correct Elmore than once, we should ask if that person should be a core roman_g 14:10:54 <roman_g> howell Zuul? Which comments? 14:11:08 <portdirect> Elmore/more 14:11:16 <roman_g> portdirect yes, I think it wan not once 14:11:23 <mattmceuen> +1 portdirect. Cores must live with the consequences of their actions and take it seriously. 14:11:45 <portdirect> Precisely 14:11:58 <roman_g> *it was not once 14:11:58 <kskels> +1 14:12:17 <kskels> (also good to hear from you Pete!) 14:12:38 * portdirect waves at kskels 14:12:54 <mattmceuen> Alright, I think we have a consensus, speak now or forever hold your peace if not :) 14:12:59 <mattmceuen> Just two final thoughts from me: 14:13:27 <mattmceuen> Just to be clear: the norm, 99.99% of the time is, two non-author +2's and a WF is required to merge a patchset 14:13:46 <mattmceuen> And, we need to document some core reviewer guidelines very soon 14:13:59 <michael-beaver> +1, I definitely agree with the informal 2x +2, especially if we document it 14:14:05 <mattmceuen> thank you for bringing this up roman_g 14:14:07 <kskels> can a WF be done by the author? 14:14:11 <kskels> and only 2x +2 is needed? 14:14:21 <portdirect> In openstack, yes 14:14:32 <mattmceuen> I think that makes sense as well 14:14:32 <portdirect> I'd advise that path here 14:14:55 <portdirect> (Again ref cores responsibility) 14:15:52 <mattmceuen> ok - moving on! 14:16:01 <mattmceuen> #topic Collaboration between Edge Working Group and Airship at Ussuri PTG or KubeCon 14:16:11 <mattmceuen> dwalt this one is yours I believe 14:16:31 <dwalt> o/ ildikov! 14:16:40 <ildikov> the OpenStack Project Team Guide has a chapter on reviewing as well: https://docs.openstack.org/project-team-guide/review-the-openstack-way.html 14:16:53 <ildikov> sorry, just jumped off of my other meeting :) 14:16:57 <ildikov> hi :) 14:16:59 <dwalt> no worries :) 14:17:05 <dwalt> floor is yours, if you'd like to speak 14:17:38 <ildikov> so the OSF Edge Computing Group is having a full day on Friday at the PTG and we are looking into cross-project sessions 14:18:12 <ildikov> we have a few projects identified that people see relevant or are interested in, etc and Airship is one of these 14:18:30 <mattmceuen> oh awesome 14:18:50 <ildikov> I know that edge is not the primary target for the project, but it's still a relevant area so I wanted to ask if people who will be in Shanghai from the team would be interested in joint dicussions? 14:18:51 * mattmceuen thanks for sharing the openstack review guide as well ildikov :) 14:18:53 <pramchan> We have our PTG sessions for Airship on Thu + Friday, will see how we can co-ordinate 14:19:15 <ildikov> this is our PTG etherpad: https://etherpad.openstack.org/p/PVG-ECG-PTG 14:19:34 <dukov> mattmceuen: https://docs.openstack.org/openstack-ansible/latest/contributor/core-reviewers.html 14:19:35 <ildikov> a bit more chaotic than I would prefer, but cross-project sessions are harder to schedule :) 14:19:40 <pramchan> May be one of us can visit and speak on Airship as how it can be relevant to edge 14:19:51 <ildikov> mattmceuen: np :) 14:20:01 <pramchan> Same way you can come to Airship and speak how Aieship is relevant to edge 14:20:40 <mattmceuen> yeah agree w/ pramchan -- if one of our Airship cores who is present at the PTG can peel off to meet with the edge group (looks like it might be Friday afternoonish) that would be valuable 14:20:48 <ildikov> I'm more on the side at this point that it comes up in discussions or people ask what's the difference between Airship and StarlingX, etc 14:21:11 <ildikov> so I think it would be great to share some thoughts about it 14:21:17 <ildikov> Friday afternoon should work 14:21:41 <mattmceuen> For sure. Would you be able to come fetch someone from the AIrship PTG room when it's about time for that? 14:21:57 <pramchan> OK let me add my 15 minutes pitch on Friday to edge etherpad 14:22:34 <mattmceuen> The same folks will also be leading the PTG so I think someone would just step out to join the edge session, if that's possible 14:22:43 <ildikov> mattmceuen: I can pop by after lunch to coordinate. Would that work? 14:23:00 <pramchan> sure 14:23:19 <pramchan> matt let's do that 14:23:37 <mattmceuen> ildikov: that's perfect 14:23:45 <mattmceuen> thanks for making the connection 14:24:11 <ildikov> I will also be in San Diego for KubeCon and some of the working group members will also, so we could target your gathering there as well, but I know it's limited time and space so I thought the PTG in Shanghai might be better 14:24:28 <ildikov> mattmceuen: awesome, we have a plan! :) 14:24:52 <ildikov> sure, looking forward to our chats and working together 14:24:55 <mattmceuen> yeah, I think that makes sense. At KubeCon we're planning on "continuing" any needed discussions as well, so that's definitely an option for the Edge+Airship type discussion too 14:25:19 <ildikov> cool, I'll keep that in mind and share with the group 14:25:23 <mattmceuen> +1 14:25:26 <pramchan> Sure you are welcome to both and matt & me appear to be at both places for co-ordination 14:25:27 <mattmceuen> ty 14:25:29 <pramchan> +1 14:25:42 <mattmceuen> ok! moving on: 14:25:45 <mattmceuen> #topic Image overrides in versions.yaml 14:25:46 <shubham_kaushal> +1 14:26:06 <mattmceuen> howell, I think this one is yours, if I am properly distinguishing the shades of lavender in the etherpad :) 14:26:16 <mattmceuen> or kaspars? 14:26:22 <kskels> It's me! :) 14:26:27 <mattmceuen> lol 14:26:32 <openstackgerrit> Sean Eagan proposed airship/promenade master: Dynamic kubelet config support https://review.opendev.org/691867 14:27:04 <mattmceuen> https://review.opendev.org/#/c/691042/ 14:27:10 <mattmceuen> all yours kskels 14:27:21 <kskels> Hi everyone! I was the person once back removing image overrides in the `versions.yaml` to stick with defaults but lately due to various issues in the gating and image pulling speeds it's increasingly difficult to keep the pipelines stable, and while putting back versions adds extra work on syncing images with charts (potential improvements in the `updater.py`) ehre are the follwoing benefits 14:27:53 <kskels> 1) It is now fully capturing all the images and versions of airship in a single file that are now possible to override by internal mirrors/repos 14:28:17 <kskels> 2) this allows overrides for environments that doesn't have access to direct internet/proxy 14:28:47 <kskels> I think I had a few more benefits that I forgot now! :) 14:29:31 <mattmceuen> if we went that way, kaspars, would we also modify the image uplift script to take all those images into account? 14:29:42 <pramchan> Is this for Ariship 1.x? 14:29:47 <mattmceuen> yep 14:29:48 <kskels> yes, for airship 1 14:29:52 <roman_g> 3) people don't get surprised to see way more images and applications being running, than the number of images listed in versions.yaml 14:30:10 <kskels> we should.. I may not have time to do it before summit but something to put on the list for todo 14:30:51 <mattmceuen> Agree, time is short before the summit -- it will be a good enhancement but not "urgent" 14:30:59 <mattmceuen> I think that change makes sense Kaspars 14:31:21 <mattmceuen> treasuremap has evolved from a "bare bones reference" toward "real world reference" anyway 14:31:43 <kskels> yes, that is very much more and more true! 14:32:31 <mattmceuen> Ok, unless there's anything else on this one, we can move on 14:32:38 <kskels> thank you! 14:32:54 <mattmceuen> #topic Docker image users 14:33:01 <ian-pittwood> This is me 14:33:10 <openstackgerrit> Merged airship/porthole master: Pass extra build args to Docker image builds https://review.opendev.org/691496 14:34:26 <ian-pittwood> Sorry, kind of last minute thing for me. So currently some of our docker images for each project specify a user and some don't. For instance, promenade specifies "USER promenade" and pegleg does not specify a user at all. This is causing interoperability issues since pegleg is running and root and creating files that the promenade user does not have permissions to. 14:34:57 <ian-pittwood> So I wanted to ask everyone what their opinion would be on creating a common user such as "airship" or using root throughout every image? 14:35:21 <ian-pittwood> I'm not sure what the current justifications are for specifying a user on each project vs using root 14:35:42 <kskels> I've had issues with this in the deployment and had to do workarounds for this exact reason - I would also be for having a common user 14:35:49 <ian-pittwood> Examples: 14:35:49 <ian-pittwood> https://opendev.org/airship/promenade/src/branch/master/Dockerfile 14:35:49 <ian-pittwood> https://opendev.org/airship/pegleg/src/branch/master/images/pegleg/Dockerfile.ubuntu_xenial 14:36:09 <mattmceuen> I think pegleg is probably the exception to the rule (whatever the rule should be) since it outputs files for other things to consume 14:36:21 <alexanderhughes> not necessarily 14:36:27 <alexanderhughes> if we do common user "airship" in all projects 14:36:37 <alexanderhughes> we don't have to run anything as root and still avoid permissions issues between projects 14:37:17 <alexanderhughes> also gets rid of workarounds like generating files with pegleg then having to chown to promenade to consume 14:37:25 <mattmceuen> I think making an assumption of coordination of users -- i.e. that users are the same between containers -- introduces a level of coupling we may not need to have 14:37:29 <ian-pittwood> I think that the "airship" user would be a good solution so long as we don't need root perms at all. I think having a "promenade" user and a "deckhand" user is a little much unless we have reasons 14:39:01 <mattmceuen> I am also a fan of following the OSH convention of injecting the running-as user as declarative intent (i.e. operator-specific configuration) for situations where there doesn't need to be any special handling (root filesystem type stuff) 14:39:24 <mattmceuen> the majority of containers shouldn't know or care what users other containers are running as 14:40:34 <mattmceuen> There has definitely been a desire to make more of our running-as-root containers run as non-root 14:40:53 <mattmceuen> I propose we bring this to the design call, so we can see it from all angles 14:41:53 <alexanderhughes> sounds good 14:42:00 <mattmceuen> ok cool - I will add it to the agenda 14:42:01 <ian-pittwood> Ok 14:42:10 <kskels> that does sound good and in the meantime, perhaps this is something we could add in the treasuremap as workaround 14:42:16 <kskels> https://github.com/airshipit/treasuremap/blob/master/tools/airship#L121 14:42:20 <mattmceuen> personally I want to talk through the problem live, I don't think I get it 100% yet :) 14:42:27 <kskels> is what we use right now, but we could use "current" user 14:42:30 <kskels> anyway! thank you 14:42:47 <mattmceuen> great, ty for sharing that kaspars 14:43:03 <mattmceuen> ok, next up: 14:43:09 <mattmceuen> #topic Review Requests 14:43:14 <mattmceuen> We have a good list today folks 14:43:31 <mattmceuen> And I know that a number of people are heading out on a plane in the next couple days 14:43:51 <mattmceuen> So let's please get some focus on these today and tomorrow so we are in good shape for new discussions at Shanghai 14:43:55 <mattmceuen> https://review.opendev.org/686758 - adds testing expectations for airshipctl 14:43:56 <mattmceuen> https://review.opendev.org/689051 - updates airshipctl unit tests to use "testify" 14:43:56 <mattmceuen> https://review.opendev.org/#/c/691746/2 - Shipyard default network policies 14:43:56 <mattmceuen> https://review.opendev.org/#/c/675851 - airshipctl Add logic to isogen subcommand 14:44:50 <mattmceuen> weird, I'm not sure why pasting those kicked me out of IRC :) 14:45:11 <pramchan> Also can you add review from flight plan - https://etherpad.openstack.org/p/Airship_FlightPlan 14:45:32 <pramchan> These need review in community 14:45:49 <mattmceuen> CONFIG STUFF 14:45:49 <mattmceuen> https://review.opendev.org/689859 14:45:49 <mattmceuen> https://review.opendev.org/688914 14:46:19 <mattmceuen> yep - hopefully those came through ok, IRCCloud is behaving a little weird for me today 14:46:56 <mattmceuen> I've added them into the IRC agenda as well 14:47:06 <mattmceuen> We have a bit of a backlog of Airship 2.0 patches team 14:47:33 <mattmceuen> Will be really valuable, as well as a great way to get experience with go, and get started in Airship 2.0 dev, to give those some solid review 14:47:51 <pramchan> +1 14:48:10 <mattmceuen> #topic Roundtable 14:48:23 <mattmceuen> we have a few minutes left team - I have one more small item 14:48:43 <mattmceuen> A number of folks will be in Shanghai next week; shall we cancel next Tuesday's team meeting? 14:49:59 <mattmceuen> Usually we do, but I didn't want to unilaterally decide :) 14:50:05 <mattmceuen> do cancel, I mean 14:50:23 <dwalt> I am in favor, unless someone has pressing items 14:50:36 <kskels> Same, as I will be away 14:50:51 <pramchan> +1 14:50:55 <mattmceuen> ok, sounds good -- I will send a note out on the mailing list to make sure everyone knows 14:51:19 <mattmceuen> any other roundtable items? 14:51:33 <openstackgerrit> Jagan Mohan Kavva proposed airship/treasuremap master: Integrate compute utility container in airship/treasuremap https://review.opendev.org/691875 14:52:03 <mattmceuen> In that case, thanks all for a good meeting! 14:52:17 <mattmceuen> Have a great week, and for those in Shanghai, good luck and have fun! 14:52:26 <mattmceuen> let us know if you need anything :) 14:52:29 <mattmceuen> #endmeeting