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