15:01:11 <mattmceuen> #startmeeting airship
15:01:12 <openstack> Meeting started Tue Nov 26 15:01:11 2019 UTC and is due to finish in 60 minutes.  The chair is mattmceuen. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:15 <mattmceuen> #topic Rollcall
15:01:16 <openstack> The meeting name has been set to 'airship'
15:01:23 <mattmceuen> Good morning/afternoon/evening everyone!
15:01:31 <dwalt> o/ top of the morning!
15:01:36 <seaneagan> o/
15:01:36 <uzumaki> o/
15:01:43 <diga> o/
15:01:43 <mattmceuen> Here is our agenda for today: https://etherpad.openstack.org/p/airship-meeting-2019-11-26
15:01:55 <rajat143> o/
15:01:56 <mattmceuen> Please add anything else you'd like to talk about today to it
15:01:58 <souradage> o/
15:02:01 <nishantkr> o/
15:02:07 <mattmceuen> we'll wait for another minute before getting going
15:02:30 <roman_g> o/
15:03:04 <mattmceuen> If you're not mattmceuen please add your IRC handle to the item that you add to the agenda, so I know who will be leading the discussion
15:03:23 <mattmceuen> I try to use the etherpad colors + participant list, but they all start looking the same :D
15:03:34 <openstackgerrit> Merged airship/porthole master: Postgresql-utility: Add pod/container security context  https://review.opendev.org/693049
15:03:35 <openstackgerrit> Merged airship/porthole master: Mysqlclient-utility: Add pod/container security context  https://review.opendev.org/693044
15:04:32 <mattmceuen> Ok, let's get started:
15:04:35 <mattmceuen> #topic     Reminder: new meeting time!
15:04:45 <mattmceuen> If you're here, you probably know this already!
15:04:57 <mattmceuen> So I think we can move ahead
15:05:17 <mattmceuen> #topic Mini-PTG at Kubecon last week
15:05:36 <mattmceuen> Thanks to everyone who was able to participate in the mini-ptg that we had in San Diego last week, ahead of the KubeCon summit
15:05:53 <mattmceuen> It was well attended -- around 20 people or so -- and very valuable discussion
15:06:13 <mattmceuen> We tried to take some good notes if anyone else would like to catch up:  https://etherpad.openstack.org/p/airship-kubecon-san-diego
15:06:32 <mattmceuen> A couple items from that discussion have made their way onto the agenda today
15:07:21 <mattmceuen> We spent a lot of time talking about Airship 2.0 bare metal testing and quite a bit of general Q&A and level setting around A2.0 details
15:07:43 <mattmceuen> Does anyone else have anything to add around the mini-ptg?  (or any questions?)
15:08:35 <mattmceuen> In that case, moving on to a related topic:
15:08:45 <mattmceuen> #topic KubeCon talk recommendations
15:09:31 <mattmceuen> we have an etherpad going of recommended talks from kubecon -- things that folks thought were particularly relevant to the airship team, or otherwise particularly informative
15:09:31 <mattmceuen> https://etherpad.openstack.org/p/airship-team-kubecon-playlist
15:09:51 <mattmceuen> Please take a look in there and see if there's anything you'd like to watch via youtube
15:10:00 <uzumaki> sure, thanks! this would be helpful
15:10:06 <mattmceuen> Or, if you have recommendations to add, please drop them in!
15:10:32 <uzumaki> quick question, how are things with treasuremap 2.0?
15:10:55 <roman_g> add it to topics
15:11:04 <mattmceuen> that's a good question uzumaki - by good luck I think we already have a topic for that today :)
15:11:17 <uzumaki> that's great mattmceuen
15:11:39 <mattmceuen> moving on to next topic:
15:11:42 <diga> that's good info link - thanks mattmceuen
15:11:50 <mattmceuen> you bet :)  hope you guys enjoy
15:11:54 <diga> will certainly go through it
15:11:59 <diga> Yeah
15:12:08 <mattmceuen> #topic New project proposal: airship/ansible-role-airship
15:12:46 <mattmceuen> One of the items that came out of the kubecon airship meetup was the need for a place for common, reusable ansible roles to live
15:13:02 <mattmceuen> for the purpose of running similar jobs across different airship projects
15:13:44 <mattmceuen> we are hoping with airship 2 to run more of our "full stack" jobs in nodepool / openstack infrastructure via zuul,
15:14:19 <mattmceuen> I took a *very quick* look around for prior art in the zuul/openstack world, and found some examples in opendev
15:14:46 <mattmceuen> airship/ansible-role-<something>  seems to follow the convention, and airship/ansible-role-airship seems reasonable to me
15:15:00 <roman_g> LGTM
15:15:12 <mattmceuen> Does anyone have more experience with zuul-focused role projects, and have any other ideas?
15:16:06 <mattmceuen> This project also has some foundations laid for it -- Kanwar and Pete both have some projects that can serve as seeds for this (links in etherpad)
15:16:50 <mattmceuen> if no questions / other ideas, per Airship community conventions, we will look for a general concensus on adding this repo.  Roman and I have given +1s, how about the rest of the team?
15:17:01 <dwalt> mattmceuen: will this only be used for CI?
15:17:09 <dwalt> or do we intend to run these locally?
15:17:38 <mattmceuen> Initially CI dwalt, but if we can get additional use out of it, all the better.  That's one reason it's nice not to have "zuul" in the project name
15:17:46 <openstackgerrit> Samuel Pilla proposed airship/treasuremap master: Upgrade Tiller version for k8s 1.16  https://review.opendev.org/694604
15:18:07 <mattmceuen> e.g. I believe the shade example project I linked to has a role that can be used 1) for CICD, 2) for general installation of Shade
15:18:29 <dwalt> That makes sense. If we plan to use another CI tool like Jenkins, where do we see those assets going?
15:19:16 <mattmceuen> today, Jenkins jobs live in Treasuremap (along with other flavors of scripting / deployment tooling)
15:19:44 <roman_g> dwalt: treasuremap and att-comdev/cicd.
15:19:52 <roman_g> @github
15:19:55 <mattmceuen> an alternative approach wouuld be to create a project for all kinds of installation helper / dev tooling, not just ansible.
15:20:09 <mattmceuen> But the nice thing about an ansible project is that it keeps the ansible things at the top level of the project
15:21:00 <souradage> What is the advantage of having ansible at the top level?
15:21:59 <mattmceuen> discoverability / usability -- as a developer you quickly know what the project is for, and quickly can find the things you're looking for in it, and have shorter paths in consuming projects
15:22:10 <dwalt> I wonder if that gives us a maintenance advantage, keeping all of those things in the same place
15:22:36 <openstackgerrit> Merged airship/porthole master: Openstack-utility: Add pod/container security context  https://review.opendev.org/693047
15:22:41 <dwalt> Would there be any objection to adding Airship 1 ansible roles to the repository?
15:23:19 <mattmceuen> re: A1.x roles:  no objection for me, as long as we made clear somehow what-was-for-what
15:24:22 <mattmceuen> re: maintenance, let's look to treasuremap as an example.   In hindsight are we happy with putting all kinds of tooling (etc etc) in one place, or would we rather have had more granular repos?
15:26:12 <dwalt> Well, updating tiller in the Armada repository, for example, breaks Airskiff CI jobs unless we update Kubernetes in Treasuremap
15:26:42 <dwalt> I suppose if the main CI for that repo lived in that repository, and used very generic ansible roles from this new repository, that might not happen
15:28:12 <mattmceuen> well what we're shooting for would be for the armada change to not get merged, because the CI breaking would -1 the change
15:28:29 <mattmceuen> so you'd have to change both (with a dependency between PS)
15:28:36 <mattmceuen> wherever the roles live
15:28:47 <dwalt> true, bad example. This only happens because the job is non-voting
15:28:52 <mattmceuen> yup
15:29:17 <dwalt> But it would eliminate the need for that extra change most likely. I can see benefits in doing so
15:33:07 <dwalt> This is more or less a long winded way of saying I support creating the repo
15:33:27 <mattmceuen> I think the details can continue to evolve, if we're good with having a repo specifically for the ansible roles
15:33:31 <mattmceuen> Ok cool
15:33:42 <mattmceuen> We have three +1's, any objections?
15:34:32 <mattmceuen> ok, then we will consider this one approved.  Thanks guys
15:34:50 <mattmceuen> #topic Jira vs GitHub issues
15:35:08 <mattmceuen> This was another topic that came out of the mini-ptg
15:35:24 <mattmceuen> I don't want to go down the rabbit hole of trying to come to a decision here/now
15:35:28 <mattmceuen> But to share the context:
15:35:59 <mattmceuen> as Airship interacts more and more with CNCF projects for Airship 2.0, more of our collaborators are familiar with github issues as a means to track project scope / file bugs
15:36:21 <openstackgerrit> Merged airship/porthole master: Etcdctl-utility: Add pod/container security context  https://review.opendev.org/693039
15:36:21 <openstackgerrit> Merged airship/porthole master: Compute-utility: Add pod/container security context  https://review.opendev.org/693038
15:36:22 <openstackgerrit> Merged airship/porthole master: Calicoctl-utility: Add pod/container security context  https://review.opendev.org/693054
15:36:22 <openstackgerrit> Merged airship/porthole master: Ceph-utility: Add pod/container security context  https://review.opendev.org/693037
15:36:31 <mattmceuen> the idea was shared to leverage issues in github.com/airshipit instead of our current jira tracker
15:37:18 <mattmceuen> there were opinions on both sides.  Does anyone have any initial opinions to share here?  Strong feelings for Jira or github issues?
15:37:58 <kskels> I think github is really handy and lightweight for focusing on code but in the same time spending least amount of time on administration
15:38:06 <kskels> I'm very much favor in github tracker
15:38:24 <mattmceuen> ty kskels
15:38:43 <uzumaki> I kindof second that. The thing i'm thinking, how will this 'transition' happen? from jira to github?
15:39:22 <mattmceuen> uzumaki:  I'm not sure whether there's some automation (or even integration!) that might help us -- I don't think this has been deeply investigated yet
15:39:34 <mattmceuen> Hopefuly not "copy and paste", but would not be the first time :)
15:39:46 <roman_g> As long as developers are paying attention to and working with bug requests (i.e. having time for working with issues submitted by community), I support any of GitHub/Jira. Github is easier.
15:39:48 <uzumaki> that's what bothers me about this. Otherwise, I second the github issue tracking
15:39:53 <mattmceuen> Case in point:  we only switched to Jira ~7 months ago
15:40:10 <mattmceuen> So I think we all need to be very sure as a community that we want github issues before switching again
15:40:33 <mattmceuen> So we will let this percolate for a while -- I'll send out a note on the mailing list as well
15:40:53 <uzumaki> I agree, roman_g. Github will be easier
15:41:04 <dwalt> I think kskels nailed it. Also, I believe GitHub has a fairly mature vulnerability reporting tool
15:41:14 <dwalt> Which was a possible challenge for us with jira
15:41:27 <mattmceuen> Yes, appreciate the feedback everyone.  Seems noone is in strongly in love with Jira
15:42:19 <mattmceuen> Ok, I think we can move on - we'll certainly come back to this topic in the future
15:42:24 <mattmceuen> #topic Define Baremetal YAML as MAAS is replaced by Metal3 - Is there is any changes in existing format ?
15:42:36 <mattmceuen> diga, this one is yours - want to outline it for us?
15:42:43 <diga> Yes
15:42:59 <diga> Currently I am seeing that there is no defined YAML for baremetal
15:43:15 <diga> with MEtal3 integration
15:43:50 <diga> IS there any YAML format we have designed for MEtal3 integration from airshipctl which we can consider for our AIR-79 epic
15:43:53 <diga> ?
15:44:09 <mattmceuen> let me take a quick look at that epic
15:44:14 <diga> ok
15:45:06 <diga> Most of the work on that EPIC is on Metal3 side
15:45:31 <AshuKumar> Image and Userdata parameters are missing in airshipctl/pkg/document/testdata/baremetal.yaml
15:45:51 <kskels> there are some things in https://review.opendev.org/#/q/status:open+project:airship/treasuremap+branch:v2
15:46:06 <kskels> I see some ironic resource, etc, not sure how relevant that is..
15:46:08 <mattmceuen> diga: have you taken a look at Dmitry's open patchsets on the treasuremap v2 branch? https://review.opendev.org/#/q/owner:dukov%2540mirantis.com+status:open
15:46:09 <diga> so we are not able to finalize  we should submit spec to airship or Metal3 side
15:46:18 <diga> Not yet
15:46:59 <mattmceuen> I think those patches have not merged yet because there's still some discussion ongoing around the *project structure*, i.e., what are our composites/functions and how do we layer them together
15:47:01 <mattmceuen> however
15:47:17 <diga> mattmceuen: how I can track work related to baremetal side on Airship  and get involved in it so that I can plan my implementation accordingly
15:47:18 <mattmceuen> after all the kustomization, the output will be normal Metal3 and Cluster API docs
15:47:35 <diga> ok
15:47:38 <mattmceuen> one approach would be:
15:48:00 <mattmceuen> you could start with a fully rendered "normal" metal3 document, without any kustomize, so that you don't have any dependencies
15:48:04 <mattmceuen> then we can refactor later
15:48:13 <diga> okay
15:48:22 <openstackgerrit> Ryan Schroder proposed airship/spyglass master: Spyglass Docs Update  https://review.opendev.org/695539
15:48:25 <mattmceuen> would that work, or any concerns w/ that approach?
15:48:37 <diga> That looks reasonable
15:48:42 <diga> Yes ofcourse
15:48:56 <diga> in that case, I have to drive spec through Metal3 community right ?
15:49:35 <mattmceuen> sorry, I missed that part - as part of your epic, do you need to change the metal3 document schema?
15:49:45 <diga> Get the implementation done there, then talk to you people on how we leverage those features
15:49:46 <mattmceuen> or just test using metal3 documents?
15:50:07 <diga> Yes, we are adding more hardware details in MEtal schema
15:50:14 <mattmceuen> ahh I see
15:50:20 <mattmceuen> sorry, misunderstood at first
15:50:21 <diga> no, its complete feature enhancement
15:50:27 <diga> NP
15:50:39 <mattmceuen> Yes - changes to the metal3 document schema needs to be run through the metal3 community/project
15:50:48 <diga> okay
15:50:49 <diga> got it
15:51:09 <mattmceuen> uzumaki, you also had some questions around treasuremap - did that get answered?
15:51:18 <diga> Do you have any specific meetings with Metal3 team setup weekly ?
15:51:47 <diga> so that I can raise this point with them on that meeting
15:52:07 <uzumaki> mattmceuen, I just wanted a quick overview of what's in the works there. How are we forming the treasuremap2 repo?
15:52:15 <mattmceuen> I don't unfortunately -- I think the best way to get in discussions with them is:
15:52:15 <mattmceuen> Metal³ Development Mailing List
15:52:15 <mattmceuen> #cluster-api-baremetal on Kubernetes Slack
15:52:29 <diga> okay
15:52:41 <diga> will take it up on slack
15:52:45 <mattmceuen> the mailing list is:      https://groups.google.com/forum/#!forum/metal3-dev
15:52:45 <diga> Thanks mattmceuen
15:52:54 <diga> (Y)
15:52:58 <mattmceuen> sure thing, let us know how it goes and if we can do anything to assist diga
15:53:25 <diga> sure, will ping you if I need anything to discuss
15:53:37 <mattmceuen> uzumaki:  a lot of the related discussion is happening in the Airship SIG YAML meetings on Mondays, are you looped into that one?
15:54:02 <uzumaki> unfortunately no, becomes too late for me over here for that meeting
15:54:17 <mattmceuen> yeah, sorry for that
15:54:25 <mattmceuen> I think they are usually recorded though, let me check
15:55:06 <openstackgerrit> diwakar thyagaraj proposed airship/porthole master: Verify Docker Default apparmor for Openstack Utility Container.  https://review.opendev.org/694385
15:55:27 <mattmceuen> I don't see a recording for yesterday's meeting, but some of the previous meetings are in there:  https://etherpad.openstack.org/p/Airship_Yaml
15:55:38 <mattmceuen> I will check w/ Rodolfo and see if he has a recording for yesterday's meeting
15:55:47 <uzumaki> I'll go through that. Thanks!
15:56:26 <openstackgerrit> diwakar thyagaraj proposed airship/porthole master: Verify Docker Default apparmor for Openstack Utility Container.  https://review.opendev.org/694385
15:56:42 <mattmceuen> sure thing, and feel free to ask any questions that don't get answered by those recordings
15:56:49 <mattmceuen> In general I'd summarize as:
15:57:23 <mattmceuen> 1) we plan to use native kubernetes documents and CRDs, instead of "airship schema" documents that were used in Airship v1
15:57:56 <mattmceuen> 2) We will do layering and substitution like we did in A1, but using Kustomize instead of Deckhand, which will allow for richer capabilities and less YAML duplication
15:58:52 <mattmceuen> 3) we are still ironing out exactly *how* we want to use Kustomize, since it's very flexible.  But from a logical standpoint, we want to use "functions" "composites" "types" and "sites" definitions -- these are logical constructs that we have defined for Airship (there's a link to a diagram in Rodolfo's agenda)
15:59:17 <mattmceuen> I have it on my plate to have a more concrete proposal for treasuremap v2 directory structure very soon
15:59:59 <uzumaki> that would be lovely, keep us updated on that proposal!
16:00:05 <mattmceuen> we discussed in San Diego and got some good feedback (the proposed diagram / TODOs are in the kubecon ptg etherpad - feel free to let me know if you have any questions on it)
16:00:07 <mattmceuen> sure thing sir
16:00:28 <uzumaki> Rodolfo's agenda?
16:01:05 <mattmceuen> same etherpad as the recordings:  https://etherpad.openstack.org/p/Airship_Yaml
16:01:25 <uzumaki> Great! thanks a lot
16:01:50 <mattmceuen> sure thing!
16:01:57 <mattmceuen> Oops we are at the end of our meeting time
16:02:09 <uzumaki> we are, it was too interesting :D
16:02:31 <mattmceuen> There are still a few meeting items left - can those be moved to next week, is there anything that you all want to discuss today?
16:02:44 <uzumaki> that was all from me
16:03:01 <diga> Fine with me
16:03:17 <shubham_kaushal> Fine with me
16:03:35 <mattmceuen> ok thanks team.  If anyone is waiting on feedback on anything we can definitely discuss here in between team meetings too
16:03:43 <mattmceuen> and/or on Rodolfo's design call meeting
16:03:51 <uzumaki> would let you know, thanks!
16:03:58 <mattmceuen> Thanks for joining today's meeting everyone!  great discussion.
16:04:01 <mattmceuen> #endmeeting