14:00:37 <mattmceuen> #startmeeting airship
14:00:38 <openstack> Meeting started Tue Aug 25 14:00:37 2020 UTC and is due to finish in 60 minutes.  The chair is mattmceuen. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:41 <openstack> The meeting name has been set to 'airship'
14:00:42 <mattmceuen> #topic Rollcall
14:00:48 <airship-irc-bot2> <alexander.hughes> o/
14:00:54 <mattmceuen> Good morning / evening everyone, welcome to our team meeting!
14:00:57 <mattmceuen> https://etherpad.opendev.org/p/airship-meeting-2020-08-25 <- agenda
14:00:57 <airship-irc-bot2> <mb551n> o/
14:01:02 <airship-irc-bot2> <ak3216> o/
14:01:06 <airship-irc-bot2> <ih616h> o/
14:01:07 <mattmceuen> please add anything you'd like to talk about today
14:01:18 <airship-irc-bot2> <pb269f> o/
14:01:33 <airship-irc-bot2> <james.gu> o/
14:01:50 <mattmceuen> #link https://etherpad.opendev.org/p/airship-meeting-2020-08-25
14:01:52 <airship-irc-bot2> <mf4716> o/
14:01:52 <airship-irc-bot2> <lb4368> o/
14:02:01 <roman_g> o/
14:02:21 <mattmceuen> Ok, let's get started:
14:02:26 <mattmceuen> #topic Announcements
14:02:57 <mattmceuen> The Open Infra Summit and PTG will both be virtual, and in back-to-back weeks in October this year
14:03:25 <mattmceuen> Part of the Summit (IMO - the most valuable part) is the cross-team Forums
14:03:49 <mattmceuen> Forums follow a similar, but slightly less formal, proposal format compared to summit talks
14:04:33 <mattmceuen> The submission window for Forums will be Aug 31 - Sept14 -- so please think of / propose any good cross-team discussion opportunities.  I.e. on topics that are shared across different projects
14:04:51 <mattmceuen> Could be different projects that work together, or, could just be different projects that could learn from each other
14:05:29 <mattmceuen> For the PTG -- I added Airship sessions on the calendar for Wednesday, Oct 28 and Thursday Oct 29, 13:00-17:00 UTC (8-noon US central)
14:05:48 <mattmceuen> As the PTG draws near, we can draft up an agenda
14:06:11 <mattmceuen> If those times aren't good for folks, please let me know
14:06:30 <mattmceuen> That's all I have for announcements - any questions/comments on the above^?
14:06:33 <airship-irc-bot2> <alexander.hughes> #link https://www.eventbrite.com/e/open-infrastructure-summit-2020-tickets-96967218561 #link https://www.eventbrite.com/e/project-teams-gathering-october-2020-tickets-116136313841  both the PTG and Summit are free to register for using links above
14:07:15 <mattmceuen> thanks Alex
14:07:27 <mattmceuen> Alright, moving on:
14:07:52 <mattmceuen> #topic Proposal: make community meeting bi-weekly, and cancel the day beforehand if there are no items on the agenda
14:08:16 <mattmceuen> This was an idea from the working committee, based on the fact that our agendas have been pretty light for this meeting recently
14:08:37 <mattmceuen> although I'm happy to meet every week, we also wanted to be respectful of everyone's time, especially from other timezone
14:08:55 <mattmceuen> How would everyone feel about making this meeting bi-weekly?
14:09:08 <openstackgerrit> Drew Walters proposed airship/treasuremap v2: DNM: Testing CI  https://review.opendev.org/747958
14:09:15 <sreejithp> o/
14:09:36 <mattmceuen> Or, if anyone would prefer weekly, please speak now or forever hold your peace ;-)
14:09:59 <airship-irc-bot2> <mf4716> +1 @mattmceuen - for making meetings bi-weekly
14:10:06 <airship-irc-bot2> <alexander.hughes> if we have nothing to discuss absolutely cancel.  I think we can do better with sharing the agenda though regardless of frequency we could start linking "next meeting agenda" in the current meeting etherpad, and sharing at the end of each meeting during round table
14:10:13 <airship-irc-bot2> <ak3216> +1 bi-weekly is fine with me
14:10:14 <mattmceuen> +1
14:10:28 <airship-irc-bot2> <kk6740> +1 bi-weekly
14:10:50 <airship-irc-bot2> <ih616h> +1
14:10:55 <dwalt> That's a good idea alexanderhughes. I also like what OSH does. One rolling agenda like the design calls
14:10:55 <mattmceuen> Sounds like a plan!  A lot of the discussion has simply moved into the design meetings, but this IRC meeting is still very helpful for non-design kinds of topics
14:11:17 <mattmceuen> Yeah, that's a very good idea
14:11:41 <mattmceuen> Because it could be a one stop shop for "agenda" and "when was the next meeting, I forget"
14:11:59 <dwalt> ++. And we don't have to recreate it ;)
14:12:03 <mattmceuen> :D
14:12:25 <airship-irc-bot2> <alexander.hughes> agree, just want to make sure people know where the agenda is prior to 30m leading up to meeting.  if our plan is to cancel a day before we want to people to be able to easily find agenda to put things on it before Mondays
14:12:41 <airship-irc-bot2> <alexander.hughes> clarifying: cancel if no agenda topics the day before
14:13:31 <mattmceuen> Yes, agree.  I'll put a recurring item on my Calendar to check the agenda, and will send out a note on the ML with the updated schedule
14:13:50 <mattmceuen> We can try it and pivot back to more meetings if/when needed
14:13:55 <airship-irc-bot2> <alexander.hughes> +1
14:14:03 <mattmceuen> Ok, sounds good!  Along the same lines:
14:14:15 <mattmceuen> #topic Any other feedback on how to make this meeting valuable?
14:14:31 <mattmceuen> You guys got a head start on this one already with the rolling agenda :)
14:14:57 <mattmceuen> anything else that would be valuable to y'all?  Other topics to discuss, or changes we can make to how this meeting is run?
14:15:32 <openstackgerrit> diwakar thyagaraj proposed airship/porthole master: Upgrade Kubectl to 1.18.6  https://review.opendev.org/747772
14:15:51 <mattmceuen> We have a "Community Feedback" standing item in the agenda, which I think has been used exactly zero times
14:16:04 <mattmceuen> so if you think of any other improvements, please do share them
14:16:16 <mattmceuen> Anything else before we move on?
14:17:00 <mattmceuen> #topic Airship in a Bottle issue
14:17:32 <mattmceuen> @ankitg raised an issue this morning on Airship 1's AIAB all-in-one demo project
14:17:34 <mattmceuen> <ankitg> Hello,  We are facing an issue with airship in a bottle setup. After successful deployment of Openstack via Airship, the public network which gets created by default is not reachable from the Openstack host itself. Thus when we create a VM on openstack and assign a floating point IP which is from the same public network subnet is not pingable from the host. Openstack VMs are not reachable from host and
14:17:34 <mattmceuen> vice versa.   The default configuration should be working as it is without any manual implementation.  We tried changing some network configurations to fix this, but nothing worked.  Thus, We need help on how we can resolve this issue.
14:17:44 <mattmceuen> Do we have ankitg here still?
14:18:21 <mattmceuen> Then I'll ask more broadly, has anyone /tried/ running airship in a bottle recently?
14:19:17 <mattmceuen> I think it's fair to ask ourselves, do we want to support AIAB anymore?  It was always "extra work" to keep it up to date
14:19:37 <mattmceuen> And the use case for it was "new interested devs/operators" -- today I think we'd steer those folks toward Airship 2
14:20:23 <airship-irc-bot2> <alexander.hughes> I have not, but I know the team has been working hard on Airship in a Pod.  I think that should be our focus rather than AIAB support for new devs/operators
14:20:33 <mattmceuen> +1
14:20:41 <airship-irc-bot2> <pb269f> would it be possible to get a 'frozen in time' release of AIAB together?
14:21:12 <mattmceuen> airship in a tightly corked bottle
14:21:35 <mattmceuen> I'd need to look at all the pinning that's in place -- that would certainly be ideal
14:21:57 <airship-irc-bot2> <pb269f> ++ it would if possible be preferable to full abandonment
14:22:54 <mattmceuen> Agree.  An assessment of AIAB should be done to see if it can be permanetently pinned.  Are any Airship 1-focused developers here who would be willing to take that as an action item?
14:24:13 <mattmceuen> I'll take it as an action item to raise this on the ML so that more devs see it; I think someone up-to-speed on Airship 1 would be in the best position to run with this
14:24:53 <mattmceuen> Ok, one final topic:
14:25:04 <mattmceuen> #topic airship v2.0 kubeconfig
14:25:07 <mattmceuen> airship v2.0 kubeconfig when two contexts are needed, clusterctl move, deployment of cluster object and waiting for nodes, managing workload cluster (where kubeconfig comes from remote cluster)
14:25:20 <airship-irc-bot2> <kk6740> hi, that’s more tech design topoc
14:25:44 <airship-irc-bot2> <kk6740> i have created, since we did n’t have time on design call, so i thought i get some input in it
14:25:47 <airship-irc-bot2> <kk6740> form here
14:26:05 <mattmceuen> sure thing
14:26:18 <mattmceuen> Can you elaborate a bit more on it? :)
14:27:17 <airship-irc-bot2> <kk6740> so when working with kubernetes we have 3 corner cases where we actually do need 2 kubeconfigs: 1. Clusterctl move 2. managing workload cluster, we don’t have kubeconfig of workload cluster localy, its pulled from parent cluster, which is target in our default case 3. waiting for nodes on workload cluster to become ready, after applying cluster-api `cluster`  object
14:28:15 <openstackgerrit> Sirisha Gopigiri proposed airship/hostconfig-operator master: WIP -- Building Zuul Gates for hostconfig repository  https://review.opendev.org/747675
14:28:47 <airship-irc-bot2> <kk6740> so if we store the kubeconfig inside the document model or take them from kubernetes cluster that hosts cluster-api components, for those corner cases, we need to somehow provide both kubeconfig for target and workload cluster
14:29:18 <airship-irc-bot2> <kk6740> or provide single kubeconfig, but need to identify a context which one is for partent and which one is for actual workload cluster (or target)
14:29:47 <mattmceuen> How do we feed that into airshipctl's clusterctl move today?
14:30:01 <airship-irc-bot2> <kk6740> only in command line `flag`
14:30:12 <airship-irc-bot2> <kk6740> so that’s like a workaround to make sure it workds for now
14:30:17 <mattmceuen> yeah makes sense
14:30:29 <airship-irc-bot2> <kk6740> before we come up with more generic way, which i am trying to do now
14:30:30 <airship-irc-bot2> <pb269f> will this not also become more common, if airship grows to be able to manage multiple workload clusters?
14:30:41 <mattmceuen> +1
14:31:07 <mattmceuen> worthy of ease-of-use support, because of that use case.  It won't just be a "day 1" action
14:31:39 <airship-irc-bot2> <pb269f> todays corner, tomorrows wall?
14:31:47 <mattmceuen> lol
14:32:06 <airship-irc-bot2> <ankitg> Hello , I just the messages
14:32:10 <airship-irc-bot2> <pb269f> multiple contexts in a single kubeconfig sounds appealing here
14:32:17 <airship-irc-bot2> <pb269f> but would need to mull on it
14:32:42 <airship-irc-bot2> <ankitg> Can someone help me to fix the issue in my AIAB
14:32:59 <mattmceuen> hey @ankitg - no worries - yep we're looking for someone to help with that, and will follow up on the mailing list
14:33:04 <airship-irc-bot2> <kk6740> @pb269f yes,i am trying to exercise a generic approach, so it’s not treated like cordner case
14:34:17 <airship-irc-bot2> <ankitg> Thanks @mattmceuen
14:36:08 <mattmceuen> @kk6740, all of these operations still feel like things you're doing against the management cluster, right?
14:36:10 <airship-irc-bot2> <kk6740> so i created a small approach, where each phase has field cluster, and this way we know where we are applying it
14:36:24 <airship-irc-bot2> <kk6740> and cluster has a parent, if parent is needed
14:37:01 <airship-irc-bot2> <kk6740> so basically, the executor, can find a parent cluster, and request the workload cluster kubeconfig from it
14:37:22 <airship-irc-bot2> <kk6740> i have tried different aproaches, but it seems that we must have the relationship to parent cluster somewhere
14:37:49 <mattmceuen> so basically, each phase would have a pointer to where to get its kubeconfig from -- in the "move" case etc it would be "from the management cluster"?
14:38:07 <airship-irc-bot2> <pb269f> makes sense i think - so (and i know im jumping ahead a bit here) you could have multiple 'workload' phses, but attached to different clusters?
14:38:31 <airship-irc-bot2> <kk6740> you may have different workload phases for different clusters
14:38:32 <airship-irc-bot2> <kk6740> https://review.opendev.org/#/c/747818/2/pkg/api/v1alpha1/phase_types.go
14:38:42 <airship-irc-bot2> <kk6740> this is how it would look like, i imagine
14:39:23 <openstackgerrit> Vrushali proposed airship/treasuremap v2: ----WIP -- Building Zuul Gates for hostconfig-operator on treasuremap: v2 branch.  https://review.opendev.org/747965
14:39:30 <airship-irc-bot2> <pb269f> hmm - def a topic for the design calls - but i think this looks sane
14:39:44 <mattmceuen> What would the logic in airshipctl be for "where do I find my kubeconfig"?
14:40:00 <mattmceuen> Since it could come from several different places after this change
14:40:28 <mattmceuen> from a cluster, from a file in the manifest structure, from an arbitrary filesystem file...
14:40:47 <airship-irc-bot2> <kk6740> so i used a builder pattern, for that. we simply shove all we have into builder, and then tell it build(), and its going to go through an algorithm, which will check if flags are defined
14:41:04 <mattmceuen> cool.  that sounds good to me too in principle!
14:41:32 <airship-irc-bot2> <kk6740> https://review.opendev.org/#/c/747818/2/pkg/phase/phase.go - lines 149-154
14:41:56 <airship-irc-bot2> <kk6740> so kubeconfig comes from flag, use it as is
14:42:18 <airship-irc-bot2> <kk6740> then if it has parrent, and we are allowed to use dynamic kubeconfig (from parent), we use that
14:42:25 <mattmceuen> are you planning to bring this up again on Thursday's design meeting @kk6740?
14:42:49 <airship-irc-bot2> <kk6740> yes, i will try, just wanted to get some feedback before
14:42:55 <airship-irc-bot2> <kk6740> if that seems alirght
14:43:02 <airship-irc-bot2> <kk6740> i can proceed and try to make a demo
14:43:04 <openstackgerrit> Vrushali proposed airship/treasuremap v2: ----WIP --  https://review.opendev.org/747965
14:43:22 <mattmceuen> Sounds like a good potential path forward to me :)  thanks for bringing it up
14:44:00 <mattmceuen> Ok, unless there are any final thoughts on the kubeconfig topic, I think we can move on:
14:44:06 <airship-irc-bot2> <kk6740> we can move on
14:44:12 <mattmceuen> #topic Review Requests & Roundtable
14:44:16 <mattmceuen> https://review.opendev.org/#/c/738410/  <- add Hardware Classification Controller function to airshipctl
14:44:41 <mattmceuen> This one^ adds a function to airshipctl for Metal3's Hardware Classification Controller
14:45:02 <mattmceuen> It doesn't contain any site integration or gating yet, but that's planned for a follow-on changeset
14:45:17 <mattmceuen> Any other review requests?
14:46:36 <mattmceuen> Other roundtable topics today?
14:47:21 <mattmceuen> Alright, then I think we can adjourn - good meeting, thanks everybody!
14:47:34 <dwalt> thank you!
14:47:37 <mattmceuen> #endmeeting