16:00:28 <mattmceuen> #startmeeting airship
16:00:29 <openstack> Meeting started Tue Jun 25 16:00:28 2019 UTC and is due to finish in 60 minutes.  The chair is mattmceuen. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:32 <mattmceuen> #topic Rollcall
16:00:33 <openstack> The meeting name has been set to 'airship'
16:00:45 <mattmceuen> Hey everyone, we will be starting our weekly team meeting in a few minutes
16:00:54 <openstackgerrit> Roman Gorshunov proposed airship/airshipctl master: [WIP] Add basic gates and docs build  https://review.opendev.org/667393
16:00:59 <mattmceuen> Please add anything you'd like to discuss to our agenda here: https://etherpad.openstack.org/p/airship-meeting-2019-06-25
16:01:01 <dwalt> o/ !
16:01:09 <michael-beaver> o/
16:02:05 <kskels> o/
16:02:46 <alexanderhughes> o/
16:03:08 <mattmceuen> alright, let's get movin'
16:03:11 <howell> o/
16:03:29 <mattmceuen> #topic Meeting time voting
16:03:41 <mattmceuen> Just a reminder that we currently have a vote open here: https://etherpad.openstack.org/p/airship-meeting-vote-2019
16:03:54 <mattmceuen> To vote for the meeting time(s) for this meeting
16:04:03 <mattmceuen> If you have an opinion, please vote in there!
16:04:27 <mattmceuen> We are set to close by EOD.  Does anyone feel like that's not enough time, or would need some more time to gather valuable votes?
16:05:10 <alexanderhughes> it's been up for some time, imo close at EOD and revisit later if we're suffering low attendance regularly
16:05:20 <mattmceuen> +1 to that
16:05:45 <mattmceuen> Alright, I will tally them up and send out results EOD (I honestly haven't reviewed them yet)
16:06:03 <mattmceuen> Unless anything else on the meeting time topic, I will plow ahead
16:06:40 <mattmceuen> #topic Revisit OpenSUSE Airskiff integration approach
16:06:50 <mattmceuen> Just to close the loop on this from last week
16:07:29 <mattmceuen> a few weeks ago, we'd decided that OpenSUSE support for Airskiff could be accomplished by using a fourth deckhand layer, below site (named `cicd`)
16:07:49 <mattmceuen> last week, we decided to think that through a bit again, just to make sure there were no issues
16:07:56 <mattmceuen> arunkant are you around by chance?
16:09:09 <mattmceuen> (or any of the other opensuse gurus)
16:10:20 <mattmceuen> In this morning's design call, we started discussing how we can "do this right" in Airship 2.0, since we're moving toward reworking our manifest layering using Kustomize anyway
16:11:23 <mattmceuen> That makes a good opportunity to get new features in, like "service layer" type things that let you pull documents into a site from different sources, e.g. one source for your hardware, once or more sources for your workload and overrides
16:11:35 <mattmceuen> Next week we'll start reviewing some details
16:12:04 <mattmceuen> So I guess my question is, is "a cicd layer off of airskiff site" good enough for opensuse until that lands
16:12:15 <openstackgerrit> PRATEEK REDDY DODDA proposed airship/promenade master: Inculde a post-run to the airship-promenade-genesis-gate  https://review.opendev.org/666645
16:12:23 <mattmceuen> But I think we'll need to table it for now :)
16:12:56 <mattmceuen> However, on a related topic - another one from last week we were going to think about
16:13:17 <mattmceuen> #topic Tungsten Fabric Integration
16:13:35 <mattmceuen> obravo, you around?
16:14:03 <obravo> Yeah ,  hello!
16:14:25 <mattmceuen> The points above I made about "we want to do this right in Airship 2.0" applies to Tungsten Fabric in the same way that it applies to OpenSUSE
16:14:30 <obravo> Suddenly i`m still working in migrating to treasuremap
16:14:35 <mattmceuen> haha
16:14:54 <mattmceuen> oh awesome - do you have a patchset for treasuremap?  I missed it
16:14:58 <mattmceuen> can you share that?
16:15:20 <mattmceuen> in the etherpad would be perfect
16:15:30 <obravo> it`s still in progress , i`ll try to share it before next Tuesday
16:15:38 <mattmceuen> Sounds great
16:16:40 <mattmceuen> So I will ask you for your thoughts on how we should manage Tunsten Fabric overrides in Airship, until Airship 2.0 makes it easier :)  here are some options:
16:18:10 <mattmceuen> 1. Do what we want to do with Airskiff + OpenSUSE:  make another layer underneath of a site (e.g. underneath `aiab`) that applies TF overrides on top of that site.  This would be a great example for folks and is in line with work you've already done; however it wouldn't demonstrate a full example multinode site exactly
16:18:42 <mattmceuen> 2. Create a new `type` in Treasuremap that adds TF overrides, making it easy to base other sites off of it
16:19:09 <mattmceuen> the downside of that is it would have a lot of copy & paste overlap with other types, e.g. with `sloop`
16:20:14 <mattmceuen> 3. Create reference manifests outside of Treasuremap.  They could even be layered on top of Treasuremap `globals`, basically same as #2 but split out into a different repo
16:20:29 <mattmceuen> The benefit of #3 would be that you'd have a lot of control over what's in that separate repository
16:20:45 <mattmceuen> We can go one or more of these routes
16:21:14 <mattmceuen> I would suggest we start with #1 and then go forward from there, but am certainly open to good ideas from you obravo or the rest of the team!
16:21:52 <kskels> My vote would probably be #2 - but would really need to think more also..
16:22:42 <mattmceuen> #2 / #3 is certainly the more correct way to do it.  And if we did start with #1, it might be good to pivot to #2 / #3 afterwards
16:23:00 <kskels> ok, sounds good
16:23:10 <mattmceuen> It comes with its own additional technical debt associated with having a new type -- but that's the world we'll live in till we have service layers
16:23:45 <mattmceuen> Hopefully I explained those ok obravo - please let me know if it sounds like crazy talk or if you have questions
16:23:50 <obravo> Well , if you ask for my opinion -  i would prefer #1 . #2 is too difficult for temporary decision , and #3 makes layering system a little more tricky
16:24:53 <mattmceuen> Sounds good to me.  The person doing the work gets a big vote ;-)   we can take a look at it as a `cicd` layer implementation once it's done, and then pivot from there if we want
16:25:25 <mattmceuen> Then you'll also be going down a similar path to airskiff-opensuse as well
16:26:02 <mattmceuen> Hey jamesgu_, I think I may have seen you slip in as well?
16:26:32 <jamesgu_> @mattmceuen: hello
16:26:35 <mattmceuen> I captured some thoughts above on Airship 1.0 vs 2.0 OpenSUSE integration, for airskiff or otherwise
16:26:48 <mattmceuen> If you can give that a look at some point and let me know your thoughts that would be awesome
16:26:52 <AlexNoskov> Hey guys! Could you please review changes for promenade https://review.opendev.org/664467. Thanks!
16:27:03 <jamesgu_> sounds good.. catching up the notes here
16:27:13 <mattmceuen> o/ AlexNoskov will do - I'll add that to the review request list
16:28:09 <mattmceuen> Alright, thanks guys - moving on
16:28:17 <mattmceuen> #topic New AIAB in TM - ready to promote as *the* AIAB?
16:28:42 <mattmceuen> Since last week I've run through the new, Treasuremap-rehomed AIAB (single node), and it's been doing great in my testing
16:29:08 <mattmceuen> has anyone else had a chance to give it a spin?  Any issues / concerns seen with it?
16:29:21 <openstackgerrit> PRATEEK REDDY DODDA proposed airship/promenade master: Inculde a post-run to the airship-promenade-genesis-gate  https://review.opendev.org/666645
16:29:23 <kskels> I've tried it also - only 2x - worked good both cases.
16:29:37 <mattmceuen> excellent
16:29:55 <mattmceuen> we've also been pointing people who have been having problems with the "old" AIAB toward the new one
16:30:31 <mattmceuen> Are we ready then to start pointing people toward the new AIAB, from the airshipit.org home page, from documentation, etc?
16:30:35 <kskels> I think this is awesome - and should provide much better care and uplifts for AIAB compare to the old
16:30:38 <mattmceuen> I am leaning that way
16:30:39 <mattmceuen> ++
16:31:16 <kskels> +1 for docs
16:32:28 <mattmceuen> As far as deprecating the "old" aiab, I suggest we do it phased, and put a note in the project readme / instructions saying something like "Note:  airship-in-a-bottle has moved to the treasuremap project <link>.  The aiab in this project is deprecated and will be removed at some point in the future"
16:32:38 <mattmceuen> or some such.  does that sound reasonable
16:32:52 <dwalt> That sounds like a reasonable approach
16:32:59 <openstackgerrit> PRATEEK REDDY DODDA proposed airship/promenade master: Inculde a post-run to the airship-promenade-genesis-gate  https://review.opendev.org/666645
16:33:03 <evgenyl> ++ deprecation note should suffice for now.
16:33:16 <dwalt> Really excited to see the long-awaited transition :)
16:33:25 <mattmceuen> same
16:33:47 <mattmceuen> cool, we have a path forward!
16:34:16 <mattmceuen> anything else to bring up on the aiab front this week?
16:34:25 <dwalt> one qq, are there areny outstanding changes?
16:34:36 <dwalt> To the old AIAB repo
16:35:13 <mattmceuen> There is obravo's tungsten fabric patchset, but he said he's working on a transition to treasuremap, so I think if he's ok with it he can abandon the old one
16:35:13 <dwalt> Noticing some where we may need to inform the authors: https://review.opendev.org/#/q/project:airship/airship-in-a-bottle
16:35:37 <openstackgerrit> Dan Crank proposed airship/promenade master: [DO NOT MERGE] combination PS for testing  https://review.opendev.org/667402
16:35:55 <mattmceuen> yes - we'll need to try to reach out to them to make them aware
16:35:59 <obravo> sure, i`ll abandon it after this meeting
16:36:01 <mattmceuen> good catch dwalt
16:36:04 <mattmceuen> thanks obravo
16:36:22 <mattmceuen> I'll send out a heads-up on the mailing list
16:36:34 <mattmceuen> #action mattmceuen will send out a heads-up on the mailing list for aiab transition
16:36:38 <dwalt> Sure thing. I have one too that I need to reconcile :)
16:37:37 <mattmceuen> alright, moving on
16:37:44 <mattmceuen> #topic Patchset Review Requests
16:37:49 <mattmceuen> https://review.opendev.org/#/c/665667/ - Treasuremap Uplift PostgreSQL
16:37:49 <mattmceuen> https://review.opendev.org/#/c/664045/ - Check sync of only active MaaS rack controllers
16:37:49 <mattmceuen> https://review.opendev.org/664467 - Treasuremap Promenade Uplift
16:38:17 <mattmceuen> the middle one was on our list last week as well I believe, let's get some review on it for sure (as well as the uplifts)
16:38:30 <mattmceuen> any other patches you guys would like to call out?
16:39:12 <nishantkr> This one please - https://review.opendev.org/#/q/topic:add-release-annotation+(status:open+OR+status:merged)
16:39:19 <nishantkr> small change :)
16:39:58 <dwalt> thx nishantkr, I'll look into those
16:40:01 <mattmceuen> good one - thanks nishantkr
16:40:19 <nishantkr> Thank you
16:40:40 <alexanderhughes> I've got some work I'll be doing on Shipyard/Pegleg to accept an auth token passed rather than having the user provide their credentials to let the code auth against keystone and generate it's own token https://review.opendev.org/#/c/666402/
16:40:52 <alexanderhughes> looking for thoughts on how to implement shipyard side before I dig into pegleg's piece
16:41:51 <alexanderhughes> and forcing pegleg to use 640 permissions on any file it creates, just to make sure none of the secrets are ever overly permissive and future proofing against anything that doesn't have secrets now as an output but might depending on use case https://review.opendev.org/#/c/666319/
16:43:00 <mattmceuen> thanks alexanderhughes, good ones.  Can you walk through the use case a bit for using an auth token rather than user credentials?
16:43:51 <nishantkr> well i thought this token was generated by keystone and to be used by services for proceeding ahead in the execution flow if token was valid
16:44:12 <alexanderhughes> sure, Darren reached out to me recently and was concerned about people using automation (Jenkins) for pegleg's upload command to shipyard.  currently you provide the --os-auth-<> flags, including a password.  this leads to tracking issues and exposing the password.  he'd rather have the option for a user to get their own token and then provide it w
16:44:13 <alexanderhughes> ithout their credentials
16:44:58 <mattmceuen> yep, that makes a lot of sense
16:45:01 <alexanderhughes> I thought if we changed shipyard to look for an environment variable 'OS_AUTH_TOKEN' and use that if present it would solve our issue, then update pegleg's shipyard_helper code to match
16:45:13 <alexanderhughes> if not present, use existing code requiring the auth variables
16:46:26 <mattmceuen> sounds great, thanks!  always good to understand the "why", appreciate the description
16:46:35 <mattmceuen> #topic Roundtable
16:46:53 <mattmceuen> Any other topics that you'd like to bring up today team?
16:47:58 <openstackgerrit> James Gu proposed airship/election master: Adding James Gu candidacy for TC role  https://review.opendev.org/667409
16:49:34 <mattmceuen> in that case, we will call it a meeting.  thanks everybody!
16:49:39 <alexanderhughes> thanks!
16:49:47 <mattmceuen> #endmeeting