15:00:54 <mattmceuen> #startmeeting airship
15:00:55 <openstack> Meeting started Tue Mar  3 15:00:54 2020 UTC and is due to finish in 60 minutes.  The chair is mattmceuen. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:58 <openstack> The meeting name has been set to 'airship'
15:01:02 <mattmceuen> #topic Rollcall
15:01:04 <Connoreika> o/
15:01:08 <aaronsheffield> o/
15:01:09 <howell> o/
15:01:09 <mattmceuen> o/ everyone and good morning/evening!
15:01:11 <seaneagan> o/
15:01:14 <nishantkr> o/
15:01:17 <michael-beaver> o/
15:01:18 <mattmceuen> Here's our agenda: https://etherpad.openstack.org/p/airship-meeting-2020-03-03
15:01:26 <dwalt> o/
15:01:39 <alexanderhughes> o/
15:01:54 <jamesgu> o/
15:02:15 <airshipbot> <alex.bailey.1> o/
15:02:29 <mattmceuen> Ok, let's get started:
15:02:33 <mattmceuen> #topic KubeCon update
15:02:46 <mattmceuen> First, a follow-up to kubecon discussion last week
15:03:11 <mattmceuen> Unfortunately, AT&T yesterday announced a hold on all international travel, so it joins Ericsson in that boat
15:03:13 <jemangs> o/
15:03:23 <mattmceuen> And others will probably follow suit
15:03:32 <Connoreika> %(
15:03:36 <roman_g> o/
15:03:48 <mattmceuen> So we will be forgoing the in-person meeting at KubeCon, sadly
15:03:53 <Connoreika> We dont follow.
15:04:19 <mattmceuen> We were planning on having an Airship Meetup in KubeCon during the summit
15:04:29 <mattmceuen> to hash through some design topics etc face to face
15:04:31 <Connoreika> i saw that
15:04:42 <mattmceuen> ok cool :)
15:05:03 <mattmceuen> We do still plan to have a strong PTG session at the open infra / PTG conference in Vancouver
15:05:40 <mattmceuen> In addition, we'd like to set up a "virtual meetup" for Airship around the same time as KubeCon, so we can have the same discussion we would have had, over telepresense
15:05:56 <mattmceuen> so please stay tuned for more info on that!
15:05:59 <Connoreika> Thats cool!
15:06:09 <mattmceuen> Yeah agree :)
15:06:09 <Connoreika> Zoom?
15:06:45 <mattmceuen> good question; zoom or webex or something similar
15:06:46 <roman_g> Zoom, WebEx, whatever.
15:06:58 <Connoreika> Cool
15:07:20 <mattmceuen> Anything else on this one before moving on?
15:07:28 <pramchan63> link #https://etherpad.openstack.org/p/airship-kubecon-amsterdam
15:07:38 <mattmceuen> let's deprecate that link please
15:07:40 <Connoreika> So we are not going on kubecon?
15:07:49 <pramchan63> OK
15:07:50 <mattmceuen> since airship will not be at kubecon in amsterdam
15:08:28 <mattmceuen> Connoreika:  AT&T and E/// will not be, but I can't speak for all corporations -- last I heard the conference is still going to happen
15:08:43 <Connoreika> Vancouver is much more expensive than Amsterdam %)
15:09:30 <mattmceuen> I was looking forward to seeing amsterdam too, never been there.  Oh well, can't complain given the global situation
15:09:38 <Connoreika> Ok, sorry that interrupted, lets move on.
15:09:43 <mattmceuen> Ok, next topic:
15:09:46 <mattmceuen> no worries :)
15:09:51 <mattmceuen> #topic Slack<-> IRC sync'ing
15:09:59 <mattmceuen> Another follow up from last week
15:10:13 <Connoreika> Why do we need it to be synced?
15:10:57 <mattmceuen> There are some folks who are interested in joining through slack instead of the IRC client, and slack is the norm in the CNCF world
15:11:04 <mattmceuen> on the other hand, IRC has a lot of benefits too
15:11:18 <mattmceuen> so I was going to look into ways to use both and mirror the conversation
15:11:45 <mattmceuen> I put together a rough helm chart for one of them and am currently running it off my laptop
15:11:48 <mattmceuen> o/ airshipbot
15:12:03 <roman_g> We have had Slack previously, it didn't work out. Conversation sync could help, though.
15:12:08 <mattmceuen> My scrum master has joined from slack world as well
15:12:29 <airshipbot> <aw442m> I exist in both worlds
15:12:41 <mattmceuen> Yeah, I think the reason it didn't work out was that it was run kind of ad-hoc; that's why I wanted to have dependable k8s orchestration of it
15:12:43 <pramchan63> which workspace in slack with which github - the sync?
15:12:44 <airshipbot> <aw442m> this is dwalt btw
15:12:49 <howell> which slack channel is that?
15:13:13 <mattmceuen> pramchan63:  it's the "airshipproject" workspace in slack
15:13:30 <mattmceuen> I haven't made a push to invite everyone because I'm waiting to get it running somewhere besides my laptop :)
15:13:40 <mattmceuen> as it is not open 24 hours a day
15:14:38 <mattmceuen> Once we have a lab up and running (there are a couple in progress) then we can home the bot there permanently, otherwise I'll plan get it running on my home machine as a stopgap
15:15:17 <mattmceuen> Here's the chart, which links to the tool itself:  https://github.com/mattmceuen/slack-irc-chart
15:15:28 <mattmceuen> That's all I had on this one.  Any questions?
15:15:55 <roman_g> Nope. Thanks, Matt.
15:15:58 <Connoreika> Dont like slack. I like discord and telegram %)
15:16:03 <mattmceuen> That's fair
15:16:03 <dwalt> Thanks for working on this Matt
15:16:09 <Connoreika> :)
15:16:29 <mattmceuen> If you'd like to integrate with those tools as well, that would be great Connoreika :)  the more bots the merrier
15:17:04 <mattmceuen> #topic airshipctl non-descriptive variables
15:17:13 <Connoreika> Im too stupid to write asuch a bot :)
15:17:14 <mattmceuen> (ie: https://opendev.org/airship/airshipctl/src/branch/master/pkg/config/cmds.go#L26) use of single letter, or two letter variables
15:17:30 <mattmceuen> it may already exist, who knows!
15:17:47 <mattmceuen> alexanderhughes:  I think this one is yours!
15:18:55 <alexanderhughes> just a gentle suggestion, we have more and more developers joining the project daily.  as they try to get up to speed making code easy to read I think is valuable.  when we are initializing variables as things like "o" or "fo" it makes code more difficult to read, resulting in more frequent tracebacks to where the variable was initialized and what it is supposed to mean
15:19:25 <howell> so this is something that's pretty typical in go code
15:19:39 <howell> the rule in general is that the longer a variable is in use, the longer its name should be
15:19:41 <howell> but,
15:19:45 <mattmceuen> I mean the language is called "go" ;-)
15:19:53 <howell> I agree that it could get confusing
15:19:58 <mattmceuen> that's only one g better than o
15:20:31 <mattmceuen> that's - an interesting convention - I'd never heard it before, and kinda like the philosophy
15:20:38 <howell> I have no issue with disregarding the above rule. It's a bit weird anyway
15:21:08 <mattmceuen> yeah, "options" wouldn't be that many more keystrokes
15:21:10 <howell> mattmceuen: it makes sense at first
15:21:12 <alexanderhughes> there's no line limit length in go, so extra characters to make things clear would be helpful - especially for things we're passing in like func RunGetAuthInfo(o *AuthInfoOptions, out io.Writer, airconfig *Config) error {
15:21:12 <alexanderhughes> o here, to me should be something like authOptions
15:21:50 <alexanderhughes> throw away variables like when looping for i:=0, but things that are important to the function would be nice to be more legible
15:22:13 <mattmceuen> I think that's a very fair public service announcement, and a good thing to keep in mind as developers
15:22:20 <howell> ^This makes a lot of sense to me
15:22:27 <howell> specifically for function parameters
15:22:34 <howell> that will appear in documentation
15:22:36 <mattmceuen> ++
15:22:52 <Connoreika> + with Alexander
15:23:16 <alexanderhughes> in any case that's my rant, I want to make things as easy as they can get for code reviewers, and for onboarding new developers.  you may see a patchset from me here soon acting on that rant if the community is okay with more verbose variables
15:23:27 <mattmceuen> lol
15:23:46 <mattmceuen> no objections here, as long as we don't go to the other extreme
15:23:56 <howell> I think we can be a bit lax with variables declared within a functoin, but certainly any variable that is exposed should be more descriptive
15:24:01 * mattmceuen shudders and remembers iphone programming APIs
15:24:09 <alexanderhughes> yeah I'm not implementing authInfoOptionsForFunctionXonLineNumberTwentySevenUsedOnlyOneTime
15:24:28 <howell> lol or java. Get yourself a JavaBeanFactoryFactory
15:24:31 <alexanderhughes> but I think just a few more chars on most of these vars would be helpful
15:24:44 <roman_g> alexanderhughes: would you submit a patch to coding conventions in docs repo? Then we can add devs who do Go development work to +2/+1 it and collect feedback.
15:24:57 <alexanderhughes> roman_g:
15:25:00 <alexanderhughes> yeah I can take this action
15:25:11 <mattmceuen> only thing I'd caution is, I'd suggest we call it a guideline instead of a rule
15:25:19 <roman_g> alexanderhughes: that would be very good. Thank you.
15:25:22 <mattmceuen> as I'm sure there are exceptions
15:25:40 <mattmceuen> yeah, thanks for bringing up alexanderhughes, good discussion
15:25:57 <mattmceuen> next topic:
15:26:04 <mattmceuen> #topic gate enhancement idea (alexanderhughes)
15:26:13 <mattmceuen> "make update-golden" to ensure tests are updated with test modifying changeset before code merges
15:26:13 <mattmceuen> https://review.opendev.org/#/c/710085/ for example does not modify config cmd "set-context" but when running make update-golden for new test addition unused test was removed
15:26:27 <roman_g> mattmceuen: Yes, coding guidelines, of course. Native exceptions are i,j,k,n,x,y,z in cycles, for an example.
15:26:45 <mattmceuen> roman_g: yep exactly
15:27:57 <alexanderhughes> so this was me as well.  in our python projects such as Pegleg we implemented YAPF as a gate.  basically ensuring that the code being submitted matched the formatting we expected with YAPF.  I think a gate that did something similar ensuring that the test cases present in patch match what make update-golden would do (which updates the golden test data for each test)
15:28:31 <alexanderhughes> so that we don't have missing, or inaccurate tests for a future patchset.  our tests are only valuable if they are up to date and accurate
15:28:37 <howell> I'm not sure I understand
15:28:39 <mattmceuen> alexanderhughes:  we should be wary of things that use codebase to generate the expected output of the current codebase -- do we avoid a "the code does what the code does" scenario?
15:28:48 <howell> golden files are just the "expected" output from unit tests
15:29:18 <dwalt> Shouldn't the unit tests fail if the golden files are not updated?
15:29:28 <dwalt> In this case, it just appeared that we had an extra one
15:29:30 <alexanderhughes> so from the example patch here, https://review.opendev.org/#/c/710085/ there was no change to config command "set-context" but I did update a new unit test.  when I ran make update-golden it modified set-context
15:29:43 <mattmceuen> Agree, I think golden output changes need to be intentional, to guard against output changes that are accidental (bugs)
15:29:44 <alexanderhughes> this should have happened in a previous patchset
15:29:45 <howell> the above PS is unique in that it is the first time that we have /removed/ a golden file
15:29:49 <pramchan63> Does removal of kubectl impact CI in Zuul? for testing
15:30:06 <howell> we should implement something to make sure there are no unused files
15:30:30 <alexanderhughes> I don't want to automatically update our codebase using zuul, I want to ensure that the tools we have to update are being run locally by devs and match expected results before merging
15:31:06 <dwalt> I think that's what howell is suggesting. Adding that check to the unit tests command
15:31:38 <alexanderhughes> that's fair, as the unit tests command is present in the gates
15:33:31 <alexanderhughes> any other opinions on this?
15:33:38 <Connoreika> nope
15:33:45 <howell> any idea on how to implement?
15:34:30 <howell> that's a detail, we can take that offline
15:34:46 <pramchan63> May be bring it to design call?
15:34:53 <alexanderhughes> at a high level sounds like we run make unit-tests to ensure current code matches test cases, then make update-golden to see if anything gets deleted after the tests have passed.  if there is a deletion fail the make command and advise user to run make update-golden
15:35:14 <jtwill98> Unit test can be used to expose abandoned files in a report, but the team should take action to remove them with a PR.
15:35:41 <howell> alexanderhughes: that sounds like it should work
15:35:59 <mattmceuen> alexanderhughes:  agree with that
15:36:07 <dwalt> that's a good idea
15:36:14 <dwalt> but then we need to add gate logic, right?
15:36:28 <dwalt> Since someone could unknowingly push without the updated golden files
15:36:38 <mattmceuen> pramchan63:  sure, feel free to add to the design call agenda
15:36:40 <alexanderhughes> yes, the gate would have to run the logic above
15:36:46 <howell> dwalt: we could probably cram it all into the `unit-tests` target
15:36:48 <mattmceuen> but I think we can hash through it here (hopefully)
15:37:09 <dwalt> gotcha. So if some golden files get deleted, it just fails the test command?
15:37:22 <howell> that's what I would think
15:37:34 <alexanderhughes> we could move this into a new make command: test-and-update or similar.  runs make unit-tests, runs make update-golden, searches for deletions, if present alert.  update gate to use the new make target
15:37:42 <dwalt> Ok. That may be confusing to someone running locally, but it's better than having extra files.
15:38:15 <dwalt> Oh I like the new target idea alexanderhughes
15:38:36 <dwalt> That one gets run in the gate; dev can run make tests locally
15:38:53 <alexanderhughes> yes, gives granularity locally but achieves same end goal at the gate
15:39:10 <dwalt> awesome. Good idea
15:39:57 <alexanderhughes> +/- votes on implementation?  would like to get an issue created to summarize our thoughts and track the work
15:40:03 <dwalt> +1
15:40:05 <mattmceuen> +1
15:40:13 <Connoreika> +
15:40:38 <alexanderhughes> great thanks all, I'll get an issue created shortly
15:40:48 <pramchan63> +1
15:41:07 <mattmceuen> awesome - ty alex
15:41:07 <alexanderhughes> if there's more discussion needed on this we can followup @ flight plan call tomorrow
15:41:09 <pramchan63> so I don't need this to be brought to design call?
15:41:23 <pramchan63> Ok
15:41:28 <mattmceuen> I think we reached consensus here, probably no need to bring it up there
15:41:43 <mattmceuen> Ok, moving on:
15:41:50 <mattmceuen> #topic baremetal renaming changes merging tomorrow (04-March)  (alexanderhughes)
15:42:02 <mattmceuen> per Jaakko Kuuskoski during 03-March Airship design call
15:42:02 <mattmceuen> https://github.com/metal3-io/cluster-api-provider-baremetal/pull/268
15:42:02 <mattmceuen> https://github.com/metal3-io/metal3-dev-env/pull/239
15:42:03 <mattmceuen> https://github.com/metal3-io/metal3-io.github.io/pull/153
15:42:26 <alexanderhughes> just a quick announcement, Jaakko mentioned these are merging tomorrow during design call.  just want to make sure anyone who wasn't present on that call has an opportunity to see it here
15:42:45 <mattmceuen> good idea.
15:43:28 <mattmceuen> The gist is that all the references to a generic "bare metal provider" are being renamed more specifically to "metal3 provider"-related naming
15:43:58 <mattmceuen> that will allow for the existance multiple bare metal providers
15:44:21 <pramchan63> namesapce change in capi  from CAPBM to CAPM3  - noted
15:44:27 <howell> I think it's more clear too. this is a good change
15:44:49 <Connoreika> +
15:45:14 <mattmceuen> Alright, moving on unless there's anything else on this topic?
15:45:30 <mattmceuen> #topic: how i can put trusted root ca in pods of airsloop installation? (Connoreika)
15:45:47 <Connoreika> Yep
15:45:49 <mattmceuen> Connoreika's asked this a couple times in the chat, let's get him on the right direction:
15:45:59 <mattmceuen> I have MITM when i trying to download something from internet, and git doesn't want to clone repos.
15:46:17 <pramchan63> on metal3.io side it's still on hold?
15:46:30 <mattmceuen> This one is an airship 1 topic
15:46:49 <mattmceuen> Does anyone have a good reference at their fingertips for adding custom CAs to a deployment?
15:46:57 <dwalt> can you elaborate on what the man-in-the-middle is? A proxy server?
15:47:15 <pramchan63> you mean airsloop of airship 1.x
15:47:24 <Connoreika> No, its security team, they listen all the traffic in company.
15:48:16 <uzumaki> dwalt, yeah, the proxy server, sort of
15:48:16 <dwalt> Do you still have a direct connection to the internet?
15:48:52 <Connoreika> Yes, direct connection. But they change certs on fly.
15:49:00 <dwalt> Uzumaki: if it's a proxy server, do you know its address? And does it require a certificate?
15:49:27 <uzumaki> well, the thing with MITM is, it's principally hidden from the client and server
15:49:42 <Connoreika> No, its not proxy.
15:49:53 <uzumaki> It's like Server <... SSLA...> MITM <...SSLB...> Client
15:50:05 <mattmceuen> Have you seen this example doc, Connoreika?:  https://github.com/airshipit/treasuremap/blob/master/site/seaworthy/secrets/certificates/certificates.yaml
15:50:08 <Connoreika> Yes. exactly.
15:50:32 <mattmceuen> That one defines the certs, CAs for the seaworthy site
15:51:01 <mattmceuen> That might not apply for the "armada reaching out" case though
15:51:10 <Connoreika> But im not shure what to put in that example and where?
15:51:15 <pramchan63> what does MITM mean ? #link https://airship-treasuremap.readthedocs.io/en/latest/airsloop.html
15:51:18 <mattmceuen> yeah, I retract that one
15:51:37 <uzumaki> pramchan63, Man-In-The-Middle, a way to snoop on SSL traffic
15:51:51 <Connoreika> And first problem is with armada :(
15:52:34 <pramchan63> thanks so question of avoiding attacks through proxy is causing issues
15:52:55 <Connoreika> No.
15:53:10 <Connoreika> I have a root ca cert.
15:53:38 <Connoreika> Usually, i put it into the host system, and cert, that security team become signed.
15:53:55 <Connoreika> And trusted
15:54:15 <Connoreika> Althow it's selfsigned.
15:54:29 <uzumaki> yeah, just like server BMC https certs
15:55:06 <Connoreika> But, when we setup airship, it's startind armada in pod, and in that pod, it's doing git clone.
15:55:31 <Connoreika> That pod, doesnt know anything about my selfsignet cert.
15:55:47 <pramchan63> i see
15:55:55 <Connoreika> So git clone - failed. Coz of fake cert.
15:56:14 <mattmceuen> is there any chance you can use a non-self-signed CA, e.g. letsencrypt?
15:56:41 <mattmceuen> I'm not sure this has been solved for within Airship unfortunately
15:56:48 <Connoreika> It's not me. Im in bank, and it's bank security team.
15:56:53 <mattmceuen> yeah, makes sense
15:56:54 <mattmceuen> hmm
15:57:22 <Connoreika> They listen that way alll the trafic from and to our bank.
15:58:07 <mattmceuen> lol I guess SSL is working as designed.. now I understand the MITM reference
15:58:20 <uzumaki> haha
15:58:51 <uzumaki> is there a way to force local git client to accept self-signed certs?
15:59:06 <mattmceuen> can the MITM  use a CA that's has a chain of trust back to the root CAs maybe?  I know that's probably outside your control
15:59:24 <dwalt> #link https://stackoverflow.com/questions/11621768/how-can-i-make-git-accept-a-self-signed-certificate
15:59:27 <dwalt> it appears so
15:59:28 <mattmceuen> We're out of time for the meeting, but let's please keep the conversation going here...
15:59:43 <mattmceuen> Requests for review:
15:59:44 <mattmceuen> https://review.opendev.org/#/c/711019/ - drydock, security alert for 2 CVEs relating to old packages
15:59:44 <mattmceuen> https://review.opendev.org/#/c/710085/ - remove kubectl subcommand from airshipctl
15:59:44 <mattmceuen> https://review.opendev.org/#/c/710469/ - refactor of airshipctl types to be golint compliant
15:59:45 <uzumaki> it can actually, but the thing is, going back to root ca might cost you a license
15:59:48 <Connoreika> What i do usually
15:59:51 <mattmceuen> Review on those please :) ^^
15:59:58 <uzumaki> and on the flip side, that will make the MITM even more sneaky
16:00:02 <mattmceuen> #endmeeting