14:00:18 #startmeeting airship 14:00:19 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:22 The meeting name has been set to 'airship' 14:00:30 #topic Rollcall 14:00:42 o/ 14:00:57 o/ 14:01:05 o/ 14:01:05 Hello guys, Here is the agenda for today's meeting - https://etherpad.openstack.org/p/airship-meeting-2020-03-10 14:01:28 o/ 14:01:34 Please add any topics you would like to discuss, we will get started in couple of minutes 14:03:54 #topic Announcements 14:04:16 alexanderhughes: please go for it 14:04:16 o/ 14:04:36 o/ dwalt 14:04:37 o/ 14:04:54 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 o/ 14:05:35 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 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 ++ 14:07:00 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 that's all from me :) 14:08:04 thanks for sharing that information alexanderhughes , This is really helpful 14:09:13 #topic Does the community see any obvious knowledge gaps 14:09:44 alexanderhughes: that's you again, please go for it :) 14:10:56 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 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 I feel like some "domains" of work have been shaping up for airship2, like UI, provisioning, YAML engineering, CI automation... 14:13:21 some of those have SIG meetings, and some do not (but they could consider spinning them up if helpful) 14:13:45 I'm trying to think of gaps 14:13:48 provisioning is a rather loaded term in the world of airship ;) 14:14:34 from the call earlier today - i wonder how much we are looking at things like the kubeadm capi implementation? 14:14:35 to be specific, I meant "widget provisioning" 14:14:41 esp for things like etcd 14:15:10 good point, and kubeadm deep knowledge for both config and management would be uber helpful to grow on our team 14:15:11 well we can use pre-provisioning and post-provisionong wrt BM and clusters to segregate the associated tasks 14:16:04 the other aspect i think that woudl be great to see - is real thought given to failure domain handling and labeling 14:16:35 this is less of a 'pure' airship2 issue, but one we also have in airship1 today 14:16:57 is there a way we can expose failure domain info to workloads? 14:17:17 +, 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 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 pramchan: but what should we define ;) also this goes beyond kust labeling 14:18:10 things like pod affinity, etc 14:19:01 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 pramchan: im reffering more to what runs ONTOP of airship itself 14:19:55 one day we will have a working cluster, then the real work begins 14:21:24 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 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 yes UCP -undercloud platform still exists although we do not want to use that term. 14:23:39 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 +1 14:24:17 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 lol hopefully something in there piqued everyone's interest for digging into -- good topic alexanderhughes 14:24:45 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 +1 shoukd consider getting Treasuremp 2.0 and Readthedoc completed as we move 14:26:30 alexanderhughes: for much of this is just not having looked out that far with airship2 14:27:02 som of this is fairly high level - eg CNFs needx, AI needs y etc 14:27:14 Lets bring it to community gathering once MM anounces the dates and bridge and open topics to debate 14:27:23 portdirect, agree. I don't think the 2.0 community is thinking of these things 14:27:47 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 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 100% agree with mattmceuen's comment above 14:28:51 simple things - eg whats going on with etcdadm, or was that effort abandonded? 14:29:25 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 etcadm is trying to align with kubeadm as last i evesdropped to hear their take 14:29:41 that sounds like a good idea 14:30:09 nishantkr, create a new etherpad and link it in the design one? 14:30:23 +1 14:31:11 Yup that's always an option :) 14:31:12 call it user stories plus use cases 14:31:29 cool, what do you guys this? alexanderhughes mattmceuen portdirect 14:32:01 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 we could consider using tags for different (coursegrained!) domains, and tagging work in github issues 14:32:33 so we'd be maintaining all of that stuff in one place 14:32:39 but I don't have a strong opinion 14:32:51 yeah even i was thinking if we could somehow track this in github 14:33:03 thensomeone could search github issues for upcoming e.g. bare metal provisiong scope or what have you 14:34:23 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 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 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 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 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 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 exactly my though alexanderhughes 14:37:02 +1 14:37:15 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 well that's case with Bootstrap SIG for now 14:38:07 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 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 haha, agree! +1 mattmceuen 14:39:14 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 I'll share the etherpad I come up with at our next community meeting on the 17th 14:39:45 Also is the wc call timing changed besides zoom link? 14:40:36 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 did your calendar invite show the wrong time? 14:41:00 IE 10 CST / 16:00 UTC is now 10 CDT / 15:00 UTC 14:41:18 alexanderhughes, I'd like to stay looped into this use cases discussion 14:42:10 No ashfreg, it was a late email for monay changing of bridge and that confused me this week with DST changes 14:42:52 NO issues will review the meeting minutes later 14:42:59 ok i think we are onto a roundtable discussion already 14:43:15 Ahmad Mahmoudi proposed airship/deckhand master: Replaced pip with pip3 https://review.opendev.org/711299 14:43:24 is there anything else someone would like to discuss today? 14:44:04 any requests for additional code review? 14:44:19 Is there any agreement on which metal3.io or capi versions Airship will use? 14:44:35 I mean airship 2.0 14:44:43 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 had a big push Friday to get it down, but more eyes in general would be helpful 14:44:57 ++ 14:45:30 I can look at some things (although I'm not fully intimate with the airshipctl code base yet) 14:45:54 awesome ty uzumaki 14:46:14 sure, any tips for a new onboarding 'set of eyes' for commit reviews? what are we generally looking for? 14:46:35 I think ahmad was looking for some core reviews on a shipyard PS here - https://review.opendev.org/#/c/709056/ 14:47:18 uzumaki - i would look for open PS here - https://review.opendev.org/#/q/project:airship/airshipctl+status:open 14:47:37 most patchsets in airshipctl map to an issue https://github.com/airshipit/airshipctl/issues?q=label%3A%22ready+for+review%22 14:47:55 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 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 mattmceuen, I see, that's helpful alexanderhughes 14:48:42 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 outstanding work needing review, I mean. That would help ramp up as well. 14:49:26 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 yep! 14:50:03 cool! I look at all the patchsets in airshipctl anyway, I'll start reviewing given the tips 14:50:05 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 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 mattmceuen: Baremetal provisioning through metal3 ? 14:51:20 Yes, pramchan. I will send mail in sometime 14:51:31 +1 14:51:54 Thanks diga 14:52:12 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 nishantkr: wc 14:52:24 even though that's a very very broad category 14:52:34 yeah 14:52:37 agree 14:53:01 Now CAPBK changed to CAPM3 14:53:04 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 Mainly we need to understand gaps to drive gopher cloud and Ironic in advance 14:53:18 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 since they wouldn't show up in the filter nishant posted 14:53:35 mattmceuen: yeah 14:53:48 pramchan,diga: sounds great, will watch for the email on airship-discuss! 14:54:00 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 yes, but some of them just reference the git issue, which is fine as well. 14:54:43 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 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 I do that all the time :) 14:55:19 ++ uzumaki 14:55:19 +1 matt Diga is working on it and we need comments to plan for Open Infra PTG 14:55:41 +1 uzumaki 14:55:51 Alright. I guess I can lend a hand in some reviews mattmceuen alexanderhughes nishantkr 14:55:51 yup that's right uzumaki 14:55:59 that'd be great, thanks uzumaki 14:56:04 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 thanks for the link ian-pittwood 14:57:10 ok guys any other roundtable items before we close out the meeting? 14:57:31 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 nishantkr, nothing from me. I'm good. 14:58:07 for review - https://review.opendev.org/#/c/686389/ 14:58:58 ian: there are many items on that list which have gone stale like https://review.opendev.org/#/c/690870/ 14:59:16 Is there a process for moving them to closure 14:59:22 Does this suffice for vBMC doc or do we need to place in Treasuremap 2.0 docs? 15:00:35 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 jtwill98 I don't really have a good answer for that. Eventually those changes should be abandoned most likely 15:01:09 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 #endtopic 15:01:16 thanks all 15:01:23 #endmeeting