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