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