15:01:39 <dwalt> #startmeeting airship
15:01:40 <openstack> Meeting started Tue Feb 25 15:01:39 2020 UTC and is due to finish in 60 minutes.  The chair is dwalt. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:43 <openstack> The meeting name has been set to 'airship'
15:01:51 <dwalt> Hello all!
15:01:53 <dwalt> #link https://etherpad.openstack.org/p/airship-meeting-2020-02-25
15:02:04 <mattmceuen> o/
15:02:10 <souradage> o/
15:02:11 <dwalt> Agenda is above. The weekly design call is ongoing, so I suspect that most still have their attention over there
15:02:26 <ian-pittwood> o/
15:02:28 <michael-beaver> o/
15:04:10 <aaronsheffield> o/
15:04:50 <diga_> Hi
15:05:06 <Connoreika> Hi
15:05:12 <alexanderhughes> o/
15:05:20 <howell> o/
15:05:20 <Connoreika> Any help on my question?
15:05:25 <diga_> are we having meeting today ?
15:05:26 <dwalt> o/ diga_ Connoreika
15:05:37 <mattmceuen> Yeah, meeting starting now
15:05:39 <dwalt> We're just getting started!
15:05:47 <dwalt> Folks are filtering in from the design call
15:05:51 <mattmceuen> Sorry Connoreika, missed your question - can you please reask?
15:06:08 <Connoreika> After meeting then.
15:06:29 <mattmceuen> sure thing, we usually have roundtable discussion at the end as well, you're welcome to ask there too
15:06:46 <dwalt> Anyway, let's go ahead and start
15:06:54 <dwalt> #topic KubeCon Amsterdam Meetup
15:07:00 <mattmceuen> that's mine
15:07:01 <dwalt> all yours mattmceuen
15:07:16 <diga_> #topic I wants to discuss about https://github.com/airshipit/airshipctl/issues/64
15:07:21 <mattmceuen> So I sent out an email on the ML on this topic this morning
15:07:32 <dwalt> I'll add that to our agenda diga_ :)
15:07:45 <diga_> Thank you!
15:07:49 <mattmceuen> The gist is that we're planning on hosting an Airship Meetup again at KubeCon in Amsterdam
15:07:49 <jemangs> o/
15:08:14 <mattmceuen> So if you're at KubeCon, you are welcomed and encouraged to attend!
15:08:14 <uzumaki> o/
15:08:38 <mattmceuen> I want to give it a bit more time this time, the majority of a day, to allow breathing room and deep dive discussion on work that's going on
15:09:12 <mattmceuen> I proposed a couple of days in there, so if you're planning on attending KubeCon, please take a look and give it some thought
15:09:26 <mattmceuen> That's really all I had to bring up on this in the meeting, though.  Any questions?
15:10:22 <mattmceuen> ok then we can move on drew!
15:10:36 <uzumaki> can somebody share the agenda etherpad link?
15:10:46 <dwalt> Uzumaki: https://etherpad.openstack.org/p/airship-meeting-2020-02-25
15:10:49 <dwalt> mattmceuen: thanks!
15:10:52 <dwalt> the next one is also yours
15:10:54 <uzumaki> dwalt, thanks!
15:10:55 <dwalt> #topic Slack
15:11:32 <mattmceuen> Thanks
15:11:49 <mattmceuen> This is just to drop the idea in you guys' ears
15:12:33 <mattmceuen> one sec
15:12:49 <mattmceuen> Ok I'm back
15:12:51 <roman_g> I'm fine with IRC. Anyhow there is not much activity.
15:13:07 <mattmceuen> We have a number of new team members joining Airship 2 development
15:13:13 <mattmceuen> From different companies
15:13:26 <mattmceuen> so I thin IRC and/or Slack as a communication tool will spike in value here shortly
15:13:52 <uzumaki> Yes, it's very convenient
15:13:55 <souradage> What was the driving factor to use IRC over like Slack in the first place?
15:13:56 <mattmceuen> I'm interested in exploring IRC/Slack integration again; we had this a couple years ago, but have not used it since
15:14:21 <mattmceuen> That would allow folks to choose whichever client they prefer, but the sync'ing would need to be rock solid (this was a problem before)
15:14:28 <roman_g> Slack becomes paid at some moment of time, you know.
15:14:32 <mattmceuen> Many people have weighed in that they prefer Slack
15:14:40 <mattmceuen> Slack is free unless you choose to pay for it
15:14:57 <uzumaki> lol
15:15:06 <Connoreika> Mb discord? Same but free, and good voice
15:15:13 <alexanderhughes> as long as there is integration I don't think it matters - but I would encourage everyone to continue their IRC as that's the platform the other projects use that we integrate with
15:15:16 <mattmceuen> IRC is the standard in the OSF world, and it puts us right next to our OpenStack collaborators
15:15:51 <mattmceuen> The opinions above are exactly why I'm interested in mirroring back and forth from Slack<->IRC
15:15:54 <uzumaki> I'm fine with IRC. It's easy and convenient and simple
15:15:54 <mattmceuen> when it works it works well
15:16:02 <mattmceuen> and we have vastly different preferences
15:16:05 <mattmceuen> and value to both
15:16:39 <mattmceuen> Anyway, I didn't bring it up to make a decision today, just to gather more opinions, and let y'all know that I'm investigating the state-of-the-integration
15:16:51 <uzumaki> okay
15:16:59 <mattmceuen> Will report back with findings hopefully next week -- please think about the pros/cons/etc in the meantime!
15:17:08 <mattmceuen> That's all from me dwalt
15:17:22 <dwalt> thanks mattmceuen
15:17:28 <dwalt> let's keep things moving
15:17:28 <alexanderhughes> on a related note, might be a good opportunity to add to wiki the IRC links to our collaborative projects
15:17:30 <alexanderhughes> metal3 etc
15:17:35 <dwalt> #topic https://github.com/airshipit/airshipctl/issues/64
15:17:36 <roman_g> mattermost has been researchd as an alternative to slack, mattmceuen
15:17:45 <diga_> Hey
15:17:47 <dwalt> hey diga_
15:18:01 <diga_> I request everyone to go through the issue once
15:18:27 <diga_> This is regarding JIRA AIR 79 the Expected HArdware Configuration
15:18:32 <mattmceuen> roman_g Connoreika:  I'll take a look at mattermost and discord, thanks :)
15:18:39 <diga_> There are two part of this work
15:18:48 <diga_> 1. South Bound - Metal3
15:19:11 <diga_> 2. Airship - We have to introduce mechnism at Airship level to adopt this feature
15:20:03 <mattmceuen> That's great diga_, thanks
15:20:05 <diga_> We already had discussion with MEtal3 community and came to conclusion that instead of implementing in BMO, let's have seperate CRD called Hardware-Classification-Controller
15:20:21 <diga_> Already base framework is merged
15:20:47 <mattmceuen> Yeah, I see there's a lot of discussion/work in the corresponding Metal3 issue
15:20:48 <diga_> We are testing some code, by Friday we are submitting two PR's to this repo
15:20:57 <diga_> Yeah mattmceuen
15:21:48 <diga_> I would like to understand where is the right place in Airshipctl for this mechnism to implement
15:22:15 <mattmceuen> So the good news is that I think the change is "mostly" transparent from an Airship perspective.  Here's why:
15:22:37 <mattmceuen> Airship is already going to need to invoke ClusterAPI -> Metal3 to accomplish BM provisioning,
15:23:03 <mattmceuen> and your M3 change lives 100% so far in Metal3, so I think airship simply benefits from it being there
15:23:13 <mattmceuen> there are a couple things I can think of that airship will need to take into account:
15:23:31 <mattmceuen> 1. making sure the BMO documents are populated with expected hardware info
15:23:47 <mattmceuen> 2. good error handling when the expected hardware doesn't match the real hardware
15:23:54 <mattmceuen> can you think of anything additional?
15:24:02 <diga_> Yeah
15:24:47 <diga_> We can also think of other classification filters like GPU, NFV params where we can filter the hosts accordingly
15:25:28 <diga_> Do we have any standard labels for use by our HCC (Hardware-Classification-Controller)
15:25:28 <alexanderhughes> I think this is a topic that would benefit from the flight plan call to groom this and think through implications and followup work that needs to occur
15:25:40 <alexanderhughes> #link https://wiki.openstack.org/wiki/Airship#AIRSHIP_Flight_Plan_-_Community_Management_Meetings
15:25:46 <diga_> okay
15:25:57 <diga_> Thank you, Will attend it
15:26:20 <dwalt> this may also be a relevant issue on airshipctl
15:26:22 <dwalt> #link https://github.com/airshipit/airshipctl/issues/29
15:26:36 <dwalt> to take advantage of the work being done in ClusterAPI
15:26:46 <diga_> I think Hardware-Classification-Controller will play big role in classifying hosts. That way, we can select right host for provisioning also
15:27:00 <diga_> and we can do entire lifecycle management easy
15:28:55 <mattmceuen> diga_:  what kinds of labels are you thinking of?
15:29:14 <mattmceuen> Today we label hosts dynamically based on declared intent, for things like "this is an openstack control plane host" or "this is a compute host" etc etc
15:29:32 <mattmceuen> but that's actually labelling the k8s node, not the host
15:29:38 <diga_> Yes
15:30:00 <diga_> Currently we are following the same, we are adding Hardware profile labels to host CR
15:30:01 <mattmceuen> So I don't think we have any standards yet
15:30:04 <mattmceuen> Cool
15:30:06 <diga_> ohh
15:30:15 <diga_> :)
15:30:30 <mattmceuen> Well let me clarify :)
15:30:39 <diga_> Sure
15:30:55 <mattmceuen> Ideally we'd keep it flexible and data-driven. I can find some similar labelling done in Airship 1 for you, let me find it real quick
15:31:15 <diga_> okay.
15:32:40 <mattmceuen> https://opendev.org/airship/treasuremap/src/branch/master/global/profiles/host/cp.yaml#L57-L116
15:32:52 <diga_> let me take a loot at it
15:33:28 <mattmceuen> that's defining the labels for the host, and then the different helm chart-deployed software running on top of the cluster is targeted at hosts with particular labels
15:33:34 <mattmceuen> host->node :D
15:33:54 <diga_> Okay
15:34:16 <diga_> Then we are on right track because we are adding profile label to the host
15:34:20 <dwalt> thanks for the links mattmceuen
15:34:38 <diga_> Do we need to introduce another label in this file for BM and Hardware profiles ?
15:34:41 <mattmceuen> diga_ -- I'll try to catch up on those two issues and have a better idea going forward
15:34:46 <diga_> https://www.irccloud.com/pastebin/IhFC9Kc8/
15:34:58 <diga_> Because only relative stuff I found is above
15:35:18 <diga_> Sure mattmceuen
15:35:23 <mattmceuen> That whole file will be basically replaced by a similar file (different schema) in Airship 2
15:35:38 <mattmceuen> And the new file doesn't really exist yet
15:35:49 <diga_> mattmceuen Can we discuss this feature in next design meeting ?
15:36:13 <mattmceuen> Yup I think that would be a good idea -- can you add it to the agenda here?   https://etherpad.openstack.org/p/Airship_OpenDesignDiscussions
15:36:22 <diga_> Sure mattmceuen
15:36:45 <dwalt> great. Anything else on this one?
15:36:46 <diga_> I will add there
15:36:59 <dwalt> #topic metal3 + Airship 2
15:37:03 <diga_> Thanks mattmceuen, it was nice talking to you :)
15:37:09 <mattmceuen> Same diga_ :)
15:37:09 <dwalt> uzumaki: all yours
15:37:14 <uzumaki> dwalt, thanks!
15:37:44 <uzumaki> So, I just have a few quick question I guess. 1- where are things regarding merging metal3 in Airship 2.0?
15:38:53 <mattmceuen> So we're migrating to github issues uzumaki - we don't have everything in place quite yet,
15:39:04 <mattmceuen> but we're adding items quickly and as needed
15:39:12 <mattmceuen> This might be a good one for that
15:39:29 <mattmceuen> The Airship 2.0 work will mostly be two things in this area:
15:39:40 <mattmceuen> 1. integrating with Cluster API (work in progress)
15:39:44 <uzumaki> Sure, I can add an issue to airshipctl repo to keep this going.
15:40:00 <mattmceuen> (since cluster will drive metal3)
15:40:11 <mattmceuen> and 2.  configuring the bare metal crds appropriately
15:40:26 <mattmceuen> that sounds good to me uzumaki
15:40:33 <mattmceuen> and then we can review it in the flight plan call
15:40:40 <dwalt> ++
15:40:51 <uzumaki> yes, that'll be good
15:41:05 <mattmceuen> dwalt:  we're currently putting issues against specific projects, and then pulling them all into the Airship 2 board for display, right?
15:41:16 <mattmceuen> (just wanted to make sure airshipctl is the right place to create the issue)
15:41:26 <dwalt> mattmceuen: that's correct
15:41:34 <dwalt> #link https://github.com/orgs/airshipit/projects/1
15:41:57 <dwalt> Above is the board. Once an issue is created, a core just adds it
15:42:11 <dwalt> And then we assign further labels in the flight plan call
15:42:15 <mattmceuen> ok, great thanks
15:42:20 <dwalt> sure
15:42:23 <uzumaki> So, it's safe to put the issue in airshipctl repo?
15:42:35 <dwalt> uzumaki: I think that makes the most sense
15:42:41 <uzumaki> great
15:42:57 <dwalt> alrighty, moving along
15:43:04 <dwalt> #topic Amsterdam Update
15:43:09 <mattmceuen> Hello
15:43:11 <mattmceuen> It's me again
15:43:11 <dwalt> mattmceuen: all yours again
15:43:29 <mattmceuen> So I wanted to add an addendum around the Meetup in Amsterdam
15:43:51 <mattmceuen> word of caution:  with the spread of the coronavirus, there's a lot up in the air
15:44:20 <mattmceuen> around whether the conference will still happen (LSF is still planning on it as of yesterday), and whether collaborating companies will allow folks to attend
15:44:56 <mattmceuen> So I would just suggest, if you haven't already booked travel, please don't do it now just for Airship
15:45:21 <mattmceuen> If for some reason things go sideways, we'll find some other means to have a Meetup instead
15:45:44 <mattmceuen> (since it's the thing I am most looking forward to at kubecon!)
15:45:56 <mattmceuen> Alright that's all from me dwalt
15:46:03 <uzumaki> one quick question
15:46:06 <mattmceuen> sure
15:46:07 <dwalt> thanks mattmceuen
15:46:44 <jemangs> (re: KubeCon, Ericsson have today until further notice suspended all non-essential international business travel)
15:46:46 <uzumaki> Where are some areas I can start contributing into, regarding metal3 in Airship2.0? I can see the YAML part of things, which I'm looking at, trying to get upto speed. what else?
15:48:05 <mattmceuen> The first thing I'd suggest is to get looped in on the zuul CI stuff that's being set up to stand up a dev/test environment
15:48:13 <mattmceuen> Let me find a link or two:
15:48:18 <uzumaki> that'll be great
15:49:01 <mattmceuen> https://review.opendev.org/#/c/708654/
15:49:30 <mattmceuen> https://review.opendev.org/#/c/693238/
15:50:16 <mattmceuen> we haven't made it too deep into the metal3 provisioning yet (focusing first on getting redfish-based provisioning of the ephemeral node, which will actually run metal3)
15:50:32 <uzumaki> oh, I see
15:50:46 <mattmceuen> So if you take a peek at those works-in-progress then come to the flight plan call and see what you can volunteer for (or ask be created in github issues) I think that's a good plan
15:51:14 <uzumaki> yeah that sounds good. Another thing, if I want to setup a dev environment for airshipctl, on my laptop, quickest way to do that?
15:51:19 <mattmceuen> We're adding CI jobs to airshipctl now just for the sake of speed; we'll move them all to the zuul jobs repo after they're in good shape
15:52:04 <mattmceuen> Should be the same set of zuul jobs :)  it's actually just ansible + shell scripts that mostly can be run in your own vm the same way as is done by zuul
15:52:16 <mattmceuen> Or at least that's the intent
15:52:21 <mattmceuen> may still be some rough edges :)
15:52:43 <uzumaki> well, rough edges are fine, as long as something's setup for convenience :D
15:53:02 <mattmceuen> yup!  and every rough edge is something we want to smooth down!
15:53:09 <uzumaki> we do, indeed.
15:53:15 <openstackgerrit> Kostyantyn Kalynovskyi proposed airship/airshipctl master: [AIR-97] Adding initinfra subcommand  https://review.opendev.org/693238
15:53:25 <uzumaki> what about the other question, quickly setting up a dev env for airchipctl?
15:53:57 <mattmceuen> the goal is it to be the same set of ansible, really
15:54:17 <mattmceuen> that goes through the steps of building, installing, running the various stages of the deployment process
15:54:23 <mattmceuen> any other ideas from airshipctl devs?
15:54:28 <dwalt> In addition to the playbooks, this should help get you started
15:54:30 <dwalt> #link https://github.com/airshipit/airshipctl/blob/master/docs/source/developers.md
15:55:37 <uzumaki> And how does gerrit review tie in, with all of this contribution process?
15:55:42 <dwalt> If you find anything along the way that would be helpful to add, please don't hesitate to do so!
15:55:43 <uzumaki> thanks, dwalt
15:55:51 <openstackgerrit> diwakar thyagaraj proposed airship/divingbell master: [FIX] Enable DivingBell Gate Job  https://review.opendev.org/709761
15:55:54 <dwalt> uzumaki: yep, we still use gerrit
15:56:04 <mattmceuen> gerrit is the review process / repo for the projects in the airship namespace
15:56:12 <mattmceuen> (like airshipctl)
15:56:15 <dwalt> #link https://review.opendev.org/#/q/project:airship/airshipctl
15:56:24 <mattmceuen> They get mirrored over to github whenever there's a merge
15:56:36 <mattmceuen> So the github issues point at the github "copy" of the code
15:56:49 <uzumaki> So github is the main upstream, and the opendev repo's are the 'waiting list' until reviewed and tested?
15:57:34 <mattmceuen> Yep that's a good way of looking at it.  The repos in open infra world also have a nice github-like UI, so you can really browse the code either place:  e.g.
15:57:53 <mattmceuen> https://opendev.org/airship/airshipctl
15:58:11 <mattmceuen> which UI etc you use is just up to personal preference
15:58:20 <dwalt> Sorry to interject, but we are almost out of time. Is there anything else pressing before we close? We can also take these questions offline and continue discussing.
15:58:41 <mattmceuen> sure sounds good to me
15:59:03 <dwalt> Great, thanks for coming all! Have a good day.
15:59:11 <dwalt> #endmeeting