14:00:54 <dwalt> #startmeeting airship
14:00:55 <openstack> Meeting started Tue Sep 24 14:00:54 2019 UTC and is due to finish in 60 minutes.  The chair is dwalt. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:58 <dwalt> #topic rollcall
14:00:59 <openstack> The meeting name has been set to 'airship'
14:01:01 <dwalt> hey everyone! o/
14:01:04 <lamt> o/
14:01:05 <nishantkr> o/
14:01:07 <alexanderhughes> o/
14:01:15 <dwalt> We'll give it five for everyone to filter in and add some agenda items
14:01:16 <roman_g> \o
14:01:21 <dwalt> https://etherpad.openstack.org/p/airship-meeting-2019-09-24
14:01:52 <howell> o/
14:01:57 <kskels> o/
14:03:54 <openstackgerrit> Kaspars Skels proposed airship/treasuremap master: Use MAAS VIP as DNS server for Seaworthy site  https://review.opendev.org/678652
14:03:56 <sthussey> here
14:05:25 <dwalt> Great! Let's get started
14:05:31 <dwalt> #topic New project proposal:  airship/apis
14:06:17 <dwalt> A new project has been proposed from the Airship design discussions to store golang interfaces that can be used to generate Airship CRDs.
14:06:53 <dwalt> The idea is that it will include interfaces for various APIs like Armada charts, manifests, etc, that will be consumed by various Kubernetes operators.
14:07:08 <sthussey> Why would you have a go module that is nothing but interfaces?
14:07:39 <sthussey> Rather than bundling those interfaces into the code that understands the contents of the CRD?
14:08:29 <roman_g> Same question from me. But I'm not a Golang expert at all.
14:08:51 <openstackgerrit> Ian Pittwood proposed airship/pegleg master: [WIP] Change verbose option to granular verbosity  https://review.opendev.org/684349
14:09:17 <kskels> this is similar concern that I had - I believe the interfaces that are implemented by someone - should be next to the code
14:09:19 <sthussey> It doesn't seem specific to Go. I would ask the same question if the proposal was a repo of protobuf definitions
14:09:35 <dwalt> I was out of office for the initial discussion, but it's my understanding that the two ways mentioned above are the ways the community are tackling this
14:10:03 <dwalt> I believe one of the benefits of moving this code into its own repository was being able to control the tooling from one repository
14:11:43 <sthussey> I was just curious of rationale. Airship is well past the point of coherent repo structure, so adding more is likely no concern.
14:11:46 <howell> I don't think that the intention was to store interface - I think what we discussed was a repo to store concrete types
14:12:00 <howell> following the patterns of other community projects
14:12:05 <howell> eg https://github.com/kubernetes/api
14:13:04 <dwalt> Can you elaborate on that a bit more, howell?
14:13:20 <itxaka> but that is still synced from https://github.com/kubernetes/kubernetes/tree/master/staging/src/k8s.io/api so the development happens in a diffrent place?
14:13:21 <sthussey> Is the expectation then that the provider of this API is a monolith as in Kubernetes?
14:13:49 <howell> I think the idea was to allow us to version our types
14:14:28 <sthussey> So the Airship API is a single product with a single version?
14:14:57 <howell> I believe so
14:15:31 <roman_g> > Airship is a collection of loosely coupled but interoperable open source tools...
14:15:46 <sthussey> is^H^H was
14:16:14 <roman_g> ¯\_(ツ)_/¯
14:16:15 <sthussey> From a Kubernetes community perspective, this seems like it may align
14:16:30 <sthussey> From go dev, I don't see this pattern often
14:16:37 <sthussey> So I guess pick your community
14:17:49 <sthussey> Anyway, I was more curious. I have no particular issue with the people doing the work building the repos that make sense for them.
14:19:23 <sthussey> @itxaka's comment is pertinent though
14:19:44 <sthussey> As it seems like there may be some magic happening in the community that isn't apparent from this side of the curtain
14:20:44 <itxaka> tbh I dont really understand this as the example given seems to be a sync to have a single repo with the api part only, but is basically a soft link to the real repo
14:21:01 <itxaka> seems to have nothing to do with the management of the api itself, as thios happens somewhere else
14:21:55 <itxaka> or is the proposal doing the other way, having the api in repo X alone, develop there and then sync to repo Y where its needed?
14:23:39 <dwalt> There are some good points here that I feel unqualified to speak on, having been out for the meeting. Is anyone opposed to revisiting these concerns at the beginning of the next open design discussion?
14:24:03 <roman_g> I'm for it.
14:24:28 <itxaka> :+1
14:24:34 <howell> I agree, I don't have enough background on the desicion
14:24:47 <dwalt> Great. Thanks team
14:24:53 <dwalt> #topic roundtable
14:25:06 <dwalt> With that, we've exhausted the agenda. Any other items?
14:26:25 <dwalt> That sounds like a no
14:26:27 <dwalt> #topic reviews
14:26:43 <dwalt> Looking for some extra eyes on this patch today. Thanks evgenyl!
14:26:48 <sthussey> This actually reminded me of a question from @roman_G
14:26:51 <dwalt> #link https://review.opendev.org/#/q/status:open+project:%255Eairship.%252B+branch:master+topic:netpol
14:26:56 <dwalt> go for it sthussey
14:27:20 <sthussey> Currently there is some agreement, though not documented as far as I know, that merges only happen with two non-author code approvals
14:27:42 <sthussey> However, this policy isn't actually enforced by zuul/gerrit
14:28:30 <dwalt> That sounds right. This is the only blurb on it that I know of: https://airship-treasuremap.readthedocs.io/en/latest/development_guide.html#merging-code
14:28:31 <sthussey> It seems like 1) this should be formalized in governance and 2) if formalized, should be actually enforced
14:29:05 <kskels> the only corner case I've used for merging automated uplifts in treasuremap if all tests pass
14:29:16 <kskels> but I think those merges are simply enough to get people reviewing
14:29:39 <sthussey> this is more a maturity topic than anything else
14:29:57 <sthussey> if Airship wants to mature, these grey areas likely need to be resolved
14:30:24 <dwalt> That's a good point. I'd like to see this get addressed as well by one of our committees
14:30:50 <sthussey> seems reasonable
14:31:06 <roman_g> Here is a link to a Gerrit prolog submit rule similar to what we want: https://gerrit-review.googlesource.com/Documentation/prolog-cookbook.html#NonAuthorCodeReview
14:31:10 <dwalt> It sounds like this may be a better item for the TC. Any thoughts?
14:31:18 <roman_g> >> Make change submittable only if Code-Review+2 is given by a non author
14:31:26 <roman_g> We need same, but 2x +2
14:31:32 <roman_g> non-authors
14:31:47 <kskels> +1
14:32:11 <sthussey> TC is fine
14:32:25 <sthussey> May want to consider the nuances of things like what Kaspar said
14:32:40 <sthussey> So that carve outs are formalized and objective
14:33:31 <dwalt> #action dwalt Add TC meeting agenda item for enforcing code review/merging standards
14:33:49 <roman_g> Yes. I was searching who is TC member :)
14:34:02 <dwalt> It is not I, but I think anyone can add :)
14:34:21 <dwalt> I'll make sure to note that on the agenda. Thanks sthussey
14:34:23 <seaneagan> have we already ruled out 1 non-author +2 as an option?
14:34:36 <sthussey> @alexanderhughes is a member
14:34:41 <seaneagan> if not, maybe something to add to TC discussion
14:34:54 <sthussey> I think it seems reasonable
14:35:10 <alexanderhughes> I'll add this as an agenda item for TC meeting 26-Sep
14:35:24 <dwalt> alexanderhuges: thanks!
14:35:31 <dwalt> alexanderhughes*
14:35:33 <sthussey> I'm not sure what the governance around cores and approvers even is at this point
14:35:43 <sthussey> Seems like it is mostly ad hoc as new repos are created
14:36:07 <dwalt> #link https://opendev.org/airship/governance#core-reviewer
14:36:46 <dwalt> We've been seeding active contributors as initial cores for new repositories, and the existing process governs additional cores thereafter
14:37:09 <sthussey> So it looks like that ^ doesn't follow governance
14:37:17 <sthussey> And the TC should be building the core list for new projects
14:37:20 <roman_g> seaneagan: no, I think. It's not enforced. I've seen in e.g. x/stackalitycs repo on opnedev author CR+2 and WF+1 themselves. And in openstack/[xxx] repos documentation translation updates patches get merged with 1x CR+2 & WF+1
14:39:00 <sthussey> Anyway, again just some comments around maturity as a project/community
14:39:07 <roman_g> > the nominee must be approved by the existing Core Reviewers for that project
14:39:27 <roman_g> Usually we don't get enough responses in mailing list when voting for new Cores
14:39:44 <roman_g> I admit.
14:41:09 <dwalt> I interpreted the last statement as being for new repositories, but it's vague. I think it's reasonable to bring this to the TC as well
14:41:42 <dwalt> thanks for bringing these items forward
14:42:44 <dwalt> anything else today, team?
14:43:33 <alexanderhughes> nothing from me.  TC agenda is updated to include both code reviews, and core nominations
14:43:58 <dwalt> alexanderhughes: thanks! much appreciated
14:44:22 <dwalt> I think we're good to close. Have a great day everyone!
14:44:25 <dwalt> #endmeeting