14:00:18 <nishantkr> #startmeeting airship
14:00:19 <openstack> Meeting started Tue Mar 10 14:00:18 2020 UTC and is due to finish in 60 minutes.  The chair is nishantkr. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:22 <openstack> The meeting name has been set to 'airship'
14:00:30 <nishantkr> #topic Rollcall
14:00:42 <ian-pittwood> o/
14:00:57 <alexanderhughes> o/
14:01:05 <uzumaki> o/
14:01:05 <nishantkr> Hello guys, Here is the agenda for today's meeting - https://etherpad.openstack.org/p/airship-meeting-2020-03-10
14:01:28 <mattmceuen> o/
14:01:34 <nishantkr> Please add any topics you would like to discuss, we will get started in couple of minutes
14:03:54 <nishantkr> #topic Announcements
14:04:16 <nishantkr> alexanderhughes: please go for it
14:04:16 <dwalt> o/
14:04:36 <nishantkr> o/ dwalt
14:04:37 <jamesgu> o/
14:04:54 <alexanderhughes> hello, just a quick reminder we transitioned to github issues for scope tracking a couple weeks ago.  for those that are looking for something to work on there's a couple good starting points I'd recommend
14:05:02 <seaneagan> o/
14:05:35 <alexanderhughes> 1. find something that has an issue and is assigned to a milestone.  this will help you identify issues that need to be worked in an ordered fashion https://github.com/airshipit/airshipctl/milestones
14:06:20 <alexanderhughes> or 2. if you're new to the project and looking for something that might interest you check out the labels https://github.com/airshipit/airshipctl/issues things like "good first issue" or "component/documents" to help narrow down issues that align with your interests
14:06:42 <mattmceuen> ++
14:07:00 <alexanderhughes> if there is something you think airshipctl needs but is not yet present on issues, please feel free to open an issue, and the project organizers will review and discuss it.  usually during the flight plan calls on wednesdays
14:07:51 <alexanderhughes> that's all from me :)
14:08:04 <nishantkr> thanks for sharing that information alexanderhughes , This is really helpful
14:09:13 <nishantkr> #topic Does the community see any obvious knowledge gaps
14:09:44 <nishantkr> alexanderhughes: that's you again, please go for it :)
14:10:56 <alexanderhughes> thanks Matt.  so this is a little bit of a followup on the announcement, and comes from a conversation I had yesterday looking for an area in Airship2 development that had a need to develop more expertise.  the area called out that I want to start working on is provisioning - but I wonder if there are other areas that would benefit from more people focusing on them: documents, baremetal provisioning, cluster
14:11:52 <alexanderhughes> etc.  and this question serves 2 functions... 1: as we get new people contributing are they able to help fill in some gaps?  and 2: do we have people with expertise in some of these areas that can serve as "mentors" of sorts, to help the new contributors get up to speed quickly
14:12:59 <mattmceuen> I feel like some "domains" of work have been shaping up for airship2, like UI, provisioning, YAML engineering, CI automation...
14:13:21 <mattmceuen> some of those have SIG meetings, and some do not (but they could consider spinning them up if helpful)
14:13:45 <mattmceuen> I'm trying to think of gaps
14:13:48 <portdirect> provisioning is a rather loaded term in the world of airship ;)
14:14:34 <portdirect> from the call earlier today - i wonder how much we are looking at things like the kubeadm capi implementation?
14:14:35 <mattmceuen> to be specific, I meant "widget provisioning"
14:14:41 <portdirect> esp for things like etcd
14:15:10 <mattmceuen> good point, and kubeadm deep knowledge for both config and management would be uber helpful to grow on our team
14:15:11 <pramchan> well we can use pre-provisioning and post-provisionong wrt  BM and clusters to segregate the associated tasks
14:16:04 <portdirect> the other aspect i think that woudl be great to see - is real thought given to failure domain handling and labeling
14:16:35 <portdirect> this is less of a 'pure' airship2 issue, but one we also have in airship1 today
14:16:57 <portdirect> is there a way we can expose failure domain info to workloads?
14:17:17 <mattmceuen> +, I didn't call it out before but workload management is a domain of work, which spans argo things and helm/tiller things
14:17:26 <pramchan> well labels need to defined before we can use them and atleast we in community do not have a cluse what lables mean in Airship to use
14:17:57 <portdirect> pramchan: but what should we define ;) also this goes beyond kust labeling
14:18:10 <portdirect> things like pod affinity, etc
14:19:01 <pramchan> sure but that's the architecture and design call to freez labels for different use as 10 use cases Rodolfo was mentioning
14:19:33 <portdirect> pramchan: im reffering more to what runs ONTOP of airship itself
14:19:55 <portdirect> one day we will have a working cluster, then the real work begins
14:21:24 <pramchan> my understanding till date has been we learn what cluster API or metal3.io can offer besides argo on top and then we borrow or adopt what works for airship, rather than define what we need and adjust later
14:21:35 <uzumaki> I agree, portdirect things are really complicated in airship, and we're all just focussing on the infrastructure itself (which we used to call the UCP), not the workload yet, gosh
14:23:00 <pramchan> yes UCP -undercloud platform still exists although we do not want to use that term.
14:23:39 <portdirect> anyway - didnt mean to derail - but in answer to alexanderhughes's question i think documentation re target use cases, and workload management are some of the biggest gaps atm in the community
14:24:04 <uzumaki> +1
14:24:17 <portdirect> and closing them may help make some of what we do simpler to conceptualizes, but also ensure that we are building a platform that supports them
14:24:40 <mattmceuen> lol hopefully something in there piqued everyone's interest for digging into -- good topic alexanderhughes
14:24:45 <alexanderhughes> would you say these are gaps where we have no knowledge in the community - or do you know of people working these items currently to begin collaborating with to share some of that knowledge?
14:25:09 <pramchan> +1 shoukd consider getting Treasuremp 2.0 and Readthedoc completed as we move
14:26:30 <portdirect> alexanderhughes: for much of this is just not having looked out that far with airship2
14:27:02 <portdirect> som of this is fairly high level - eg CNFs needx, AI needs y etc
14:27:14 <pramchan> Lets bring it to community gathering once MM anounces the dates and bridge and open topics to debate
14:27:23 <uzumaki> portdirect, agree. I don't think the 2.0 community is thinking of these things
14:27:47 <mattmceuen> alexanderhughes:  I think the kubeadm area (through CAPBK and otherwise), and failure domain stuff jump out at me as additional areas where more depth would be valuable
14:28:08 <portdirect> but can get reasonable granular - eg storage provisioning etc, and if we use somthing like say ceph via rook - how can we manage this - taking into account failure domains in a deployment etc
14:28:24 <portdirect> 100% agree with mattmceuen's comment above
14:28:51 <portdirect> simple things - eg whats going on with etcdadm, or was that effort abandonded?
14:29:25 <nishantkr> Is there a good way we can document somewhere about these areas within airship2, keep a track of people who are working on it and see which area needs more attention?
14:29:40 <pramchan> etcadm is trying to align with kubeadm as last i evesdropped to hear their take
14:29:41 <uzumaki> that sounds like a good idea
14:30:09 <uzumaki> nishantkr, create a new etherpad and link it in the design one?
14:30:23 <pramchan> +1
14:31:11 <nishantkr> Yup that's always an option :)
14:31:12 <pramchan> call it user stories plus use cases
14:31:29 <uzumaki> cool, what do you guys this? alexanderhughes mattmceuen portdirect
14:32:01 <alexanderhughes> I'd like to see this as well.  a high level overview of what areas are being worked now - what we think is coming in the future, and who we have that generally works in which domains.  using a table like that would be easier to visualize where our gaps are, what needs future thought and who the "go to" person is for each area when trying to onboard new people or get status updates
14:32:21 <mattmceuen> we could consider using tags for different (coursegrained!) domains, and tagging work in github issues
14:32:33 <mattmceuen> so we'd be maintaining all of that stuff in one place
14:32:39 <mattmceuen> but I don't have a strong opinion
14:32:51 <nishantkr> yeah even i was thinking if we could somehow track this in github
14:33:03 <mattmceuen> thensomeone could search github issues for upcoming e.g. bare metal provisiong scope or what have you
14:34:23 <pramchan> remember adding too many issues and backlogs to github will strain the githup pipeline , rather discuss agree and then add new issues to github
14:34:38 <uzumaki> agree. that could become an addendum to what we're talking about, that whole etherpad thing, where like alexanderhughes says we could also have a table/list of who's doing what
14:35:10 <nishantkr> This is a good topic to revisit again with options on how we can maintain this in a common place like github or etherpad or something else?
14:35:32 <mattmceuen> pramchan: good point; I was only talking about tagging issues that /already/ have anyway, as opposed to adding a lot of new ones w/o thinking them through
14:36:21 <uzumaki> I'm thinking this, etherpad with overall view of this thing, with that list like alexanderhughes said. IN ADDITION, introduce extra labels in github like mattmceuen said, just as a value added thing, for people to browse the github to look at the work itself (or perhaps introduce new work under those domains)
14:36:30 <alexanderhughes> I think for tracking work github, but an etherpad addendum could be a good way to summarize the work people have already done that was tracked in github.. using that plus YAML sig attendance we can start to get a better idea of who is working what and which areas are still light on contributors
14:36:47 <uzumaki> exactly my though alexanderhughes
14:37:02 <pramchan> +1
14:37:15 <mattmceuen> the good thing about these SIG meetings is that they kinda start up when we need them, and then expire when they're not needed anymore
14:37:55 <pramchan> well that's case with Bootstrap SIG for now
14:38:07 <nishantkr> ok sounds good, is that something you would want to start up with alexanderhughes and take feedback from folks in the next meeting?
14:38:17 <mattmceuen> so let's keep an eye out for specific topics where focused deisign work would be needed, when we get to that point.  I wouldnt' want to create a SIG for all of these topics necessarily now and then have everyone sitting on calls all day :D
14:39:08 <uzumaki> haha, agree! +1 mattmceuen
14:39:14 <alexanderhughes> I'd like to discuss this with the TC on Thursday.  I'll do a pass through github issues and sync with a few of you to come up with a rough table of what's being worked now and who works that space.  then start adding onto it using the airship design calls for what we think is coming and see if we can start filling it out to make sure we at least have someone thinking about these upcoming topics
14:39:30 <alexanderhughes> I'll share the etherpad I come up with at our next community meeting on the 17th
14:39:45 <pramchan> Also is the wc call timing changed besides zoom link?
14:40:36 <alexanderhughes> great question, all of the Airship meetings to my knowledge are created in US timezones.  because the US observes daylight saving time, meeting times in the US are unchanged - but - for countries where DST is not observed, the meetings are now 1 hour earlier
14:40:59 <ashferg> did your calendar invite show the wrong time?
14:41:00 <alexanderhughes> IE 10 CST / 16:00 UTC is now 10 CDT / 15:00 UTC
14:41:18 <uzumaki> alexanderhughes, I'd like to stay looped into this use cases discussion
14:42:10 <pramchan> No ashfreg, it was a late email for monay changing of bridge and that confused me this week with DST changes
14:42:52 <pramchan> NO issues will review the meeting minutes later
14:42:59 <nishantkr> ok i think we are onto a roundtable discussion already
14:43:15 <openstackgerrit> Ahmad Mahmoudi proposed airship/deckhand master: Replaced pip with pip3  https://review.opendev.org/711299
14:43:24 <nishantkr> is there anything else someone would like to discuss today?
14:44:04 <mattmceuen> any requests for additional code review?
14:44:19 <pramchan> Is there any agreement on which metal3.io or capi versions Airship will use?
14:44:35 <pramchan> I mean airship 2.0
14:44:43 <alexanderhughes> airshipctl in general =/  we've had a huge influx of commits lately, but review counts have been relatively steady so work is outpacing reviews
14:44:55 <alexanderhughes> had a big push Friday to get it down, but more eyes in general would be helpful
14:44:57 <mattmceuen> ++
14:45:30 <uzumaki> I can look at some things (although I'm not fully intimate with the airshipctl code base yet)
14:45:54 <mattmceuen> awesome ty uzumaki
14:46:14 <uzumaki> sure, any tips for a new onboarding 'set of eyes' for commit reviews? what are we generally looking for?
14:46:35 <nishantkr> I think ahmad was looking for some core reviews on a shipyard PS here - https://review.opendev.org/#/c/709056/
14:47:18 <nishantkr> uzumaki - i would look for open PS here - https://review.opendev.org/#/q/project:airship/airshipctl+status:open
14:47:37 <alexanderhughes> most patchsets in airshipctl map to an issue https://github.com/airshipit/airshipctl/issues?q=label%3A%22ready+for+review%22
14:47:55 <mattmceuen> uzumaki: some folks who have more experience in the technology (e.g. go) give reviews from a code convention / cleanliness perspective, and some folks with more of the domain knowledge give review from a "what is being accomplished" perspective, there is no wrong answer!
14:48:12 <alexanderhughes> when reviewing - does the patch meet the story requirements, does the patch pass unit tests (and for new code were new tests added that make sense), does the code make sense
14:48:38 <uzumaki> mattmceuen, I see, that's helpful alexanderhughes
14:48:42 <mattmceuen> If anyone is interested in the domains of work we were discussing earlier, then I'd see whether there's any outstanding work in that area -- CICD, bare metal provisioning, etc
14:49:06 <mattmceuen> outstanding work needing review, I mean.  That would help ramp up as well.
14:49:26 <uzumaki> So, in order to review, I'd just add myself as a reviewer on that change, do my stuff (comments etc) and that's it?
14:49:42 <mattmceuen> yep!
14:50:03 <uzumaki> cool! I look at all the patchsets in airshipctl anyway, I'll start reviewing given the tips
14:50:05 <alexanderhughes> the issues link above routes you to where the patches live on gerrit (Nishant's link) and from there hit the reply button and give a vote with comments
14:50:21 <pramchan> We have one and asked Digambar to send email on definiton for BM machine YAML to use for Airship 2.0, if we go by what meatl3.io or cluster api define or we define as what Airship needs?
14:50:57 <diga> mattmceuen:  Baremetal provisioning through metal3 ?
14:51:20 <diga> Yes, pramchan. I will send mail in sometime
14:51:31 <pramchan> +1
14:51:54 <nishantkr> Thanks diga
14:52:12 <mattmceuen> diga:  yeah, I was kind of lumping together CAPI, M3, and related airshipctl/YAML work into a big bare metal provisioning category
14:52:21 <diga> nishantkr: wc
14:52:24 <mattmceuen> even though that's a very very broad category
14:52:34 <diga> yeah
14:52:37 <diga> agree
14:53:01 <diga> Now CAPBK changed to CAPM3
14:53:04 <mattmceuen> also, when review is needed on changes to other repos (e.g. metal3) it would be great to bring them to this meeting
14:53:08 <pramchan> Mainly we need to understand gaps to drive gopher cloud and Ironic in advance
14:53:18 <uzumaki> alexanderhughes, that sounds simple enough. SO my workflow so far looks like get the labeled issues from github -> get to the change -> reply/comment looking at the issue and seeing if the code does what it says. That sounds doable.
14:53:18 <mattmceuen> since they wouldn't show up in the filter nishant posted
14:53:35 <diga> mattmceuen: yeah
14:53:48 <mattmceuen> pramchan,diga:  sounds great, will watch for the email on airship-discuss!
14:54:00 <alexanderhughes> yep.  combing through gerrit directly is fine too, patches should be using sufficiently verbose commit messages to describe the intended changes and why they're needed
14:54:30 <uzumaki> yes, but some of them just reference the git issue, which is fine as well.
14:54:43 <nishantkr> uzumaki: and if there's something you do not understand in the code, it's alright to ask questions on the PS as well to get more clarity
14:55:09 <uzumaki> nishantkr, i see. And if the discussion is ongoing, I don't necessarily have to give it a +1/-1, keep it a 0?
14:55:10 <nishantkr> I do that all the time :)
14:55:19 <mattmceuen> ++ uzumaki
14:55:19 <pramchan> +1 matt Diga is working on it and we need comments to plan for Open Infra PTG
14:55:41 <pramchan> +1 uzumaki
14:55:51 <uzumaki> Alright. I guess I can lend a hand in some reviews mattmceuen alexanderhughes nishantkr
14:55:51 <nishantkr> yup that's right uzumaki
14:55:59 <alexanderhughes> that'd be great, thanks uzumaki
14:56:04 <ian-pittwood> Here's a good filter for manually combing gerrit https://review.opendev.org/#/q/status:open+NOT+label:Verified%253D-1+NOT+label:Workflow%253D-1+NOT+message:DNM+NOT+message:WIP+project:airship/airshipctl
14:56:53 <nishantkr> thanks for the link ian-pittwood
14:57:10 <nishantkr> ok guys any other roundtable items before we close out the meeting?
14:57:31 <uzumaki> that's cool ian-pittwood I've actually subscribed to the airshipctl project on opendev, I guess I can get rid of it, since I'm gonna be combing gerrit/github for work now.
14:57:37 <uzumaki> nishantkr, nothing from me. I'm good.
14:58:07 <pramchan> for review - https://review.opendev.org/#/c/686389/
14:58:58 <jtwill98> ian:  there are many items on that list which have gone stale like https://review.opendev.org/#/c/690870/
14:59:16 <jtwill98> Is there a process for moving them to closure
14:59:22 <pramchan> Does this suffice for vBMC doc or do we need to place in Treasuremap 2.0 docs?
15:00:35 <alexanderhughes> gerrit and opendev are interchangeable terms.  any time we're talking about reviewing code on gerrit we mean review.opendev.org for one of the airship projects.  big focus lately is the airship/airshipctl project
15:01:02 <ian-pittwood> jtwill98 I don't really have a good answer for that. Eventually those changes should be abandoned most likely
15:01:09 <nishantkr> we are out of time guys, Thanks everyone for joining,  we can continue rest of the discussion after the meeting as well :)
15:01:14 <nishantkr> #endtopic
15:01:16 <alexanderhughes> thanks all
15:01:23 <nishantkr> #endmeeting