16:00:00 <mattmceuen> #startmeeting airship
16:00:01 <openstack> Meeting started Tue Apr 16 16:00:00 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:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:05 <openstack> The meeting name has been set to 'airship'
16:00:06 <mattmceuen> #topic Rollcall
16:00:09 <levmorgan> o/
16:00:14 <michael-beaver> o/
16:00:16 <mattmceuen> o/ everyone, let's give it a couple minutes
16:00:33 <evgenyl> Hi everyone!
16:00:34 <mattmceuen> agenda, please feel free to add anything you'd like to discuss today: https://etherpad.openstack.org/p/airship-meeting-2019-04-16
16:00:41 <AlexanderHughes> o/
16:00:47 <evgenyl> mardim: Yeah, I'm here.
16:00:54 <mattmceuen> o/ evgenyl great job on the Airship demo :)
16:01:01 <mardim> hey how are you ?
16:01:13 <mattmceuen> hey mardim
16:01:19 <mardim> I am wondering if you still need the airship-seaworthy
16:01:26 <mardim> hello mattmceuen
16:01:28 <mardim> :)
16:01:57 <AvinashBR> Hey Matt, great presentation on Brighttalk
16:02:05 <mattmceuen> Thanks AvinashBR!
16:02:25 <kaspars__> ah! I missed it :(
16:02:26 <dwalt> o/ hey everyone
16:02:54 <mattmceuen> No worries kaspars__ was recorded, I'll share the link here when I get it
16:03:02 <kaspars__> thank you thank you
16:03:09 <mattmceuen> Alright, let's get started:
16:03:14 <mattmceuen> #topic Would it make sense to break out the OSH HTK pins in Treasuremap similarly to what is done for Airship?
16:03:23 <openstackgerrit> Drew Walters proposed openstack/airship-shipyard master: CI: Add Airskiff check  https://review.openstack.org/653035
16:03:23 <mattmceuen> This was something jamesgu__ had brought up last week
16:04:04 <mattmceuen> And we were going to mull on it for a week.  Basically, our Treasuremap reference manifests have one helm-toolkit reference defined per chart for Airship charts, but one dependency shared for the OpenStack charts
16:04:05 <jamesgu__> ah yes
16:04:34 <mattmceuen> And he had run into a situation where he wanted to pin different helm-toolkits for different openstack charts - was not possible without refactoring
16:04:35 <arunkant> o/
16:04:39 <mattmceuen> o/ arunkant
16:05:03 <mattmceuen> so the thought was:  should we just refactor the openstack HTK refs in Treasuremap to be split out, like Airship is?
16:05:15 <mattmceuen> I for one have not come up with any reason not to :)
16:05:32 <dwalt> This week there was a scenario where this would have been helpful. I am in favor of splitting :)
16:05:35 <mattmceuen> But interested if anyone else has other thoughts / opinions
16:05:51 <mattmceuen> Well there you go, it's officially a recurring situation
16:05:52 <kaspars__> I also concur - seems good thing to do especially for site updates, etc when fixing bugs, etc.
16:07:05 <mattmceuen> #action mattmceuen will create a story in storyboard to split out HTK dependencies for Treasuremap reference openstack charts
16:07:47 <mattmceuen> thanks guys - it is time-boxed-unanimous (I am going to keep using that one).  Anything else on this topic?
16:08:09 <evgenyl> +1 for splitting.
16:08:35 <mattmceuen> awesome
16:08:40 <mattmceuen> next topic:
16:08:45 <mattmceuen> #topic Governance repo has been created
16:09:02 <mattmceuen> per discussion last week:  https://opendev.org/openstack/airship-governance now exists
16:09:06 <mattmceuen> it is very very empty
16:09:44 <mattmceuen> I believe the first patchset against it needs to add a zuul job, and in our case that zuul job should probably lint / build docs, since that's the only thing we expect this repo to be used for!
16:10:42 <mattmceuen> Would anyone be interested in helping add a basic gate to the repo, so jezogwza_ can push an initial draft governance doc to it?
16:10:48 <openstackgerrit> Sirajudeen proposed openstack/airship-in-a-bottle master: Multinode support for promenade encryption  https://review.openstack.org/652735
16:11:54 <mattmceuen> I believe it's pretty straightforward to create a basic readthedocs-focused project -- for example:  https://opendev.org/openstack/airship-treasuremap/src/branch/master/.zuul.yaml
16:13:02 <mattmceuen> We'll table that for now - if anyone wants to cut their teeth with some zuul'ing, it would be very valuable - the more zuul knoweldge we have in our team the easier it is to add additional testing/checks/gating
16:13:34 <mattmceuen> #topic Need spec update (line 80), review from cores and approval for multi-distro spec
16:13:53 <mattmceuen> This is either dwalt or arunkant, you guys both are shades of blue in the etherpad :D
16:14:09 <mattmceuen> The multi-distro spec: https://review.openstack.org/#/c/643106/
16:14:14 <kaspars__> I would like to get more familiar with Zuul - but can't commit for this week..
16:14:42 <dwalt> I don't remember adding this :P
16:14:42 <mattmceuen> understand kaspars__, you've had your hands full dude
16:15:03 <arunkant> arunkant: its me. Just continuing from last week discussion. Looking for updates on this spec as there is discussion about some clarification
16:15:21 <mattmceuen> https://review.openstack.org/#/q/status:open+branch:master+topic:airship_suse
16:16:41 <openstackgerrit> Drew Walters proposed openstack/airship-treasuremap master: airskiff: Make airskiff gate non-voting  https://review.openstack.org/653039
16:16:45 <arunkant> As per current spec, its not clear what tag should be used for image building (line 80)
16:17:15 <openstackgerrit> Drew Walters proposed openstack/airship-treasuremap master: airskiff: Make airskiff gate non-voting  https://review.openstack.org/653039
16:17:22 <mattmceuen> roman_g would you be able to specify the tag format in the current PS?
16:17:24 <arunkant> and there is clarification/update needed in spec around that
16:18:20 <mattmceuen> I believe roman_g was on vacation, we may not have him today
16:19:16 <mattmceuen> #action mattmceuen to follow up with roman_g on tag format in multi-os spec
16:19:19 <arunkant> Based on earlier conversation on this topic, I recall consensus on what Michael Beaver has mentioned in his comments
16:19:36 <ian-pittwood> Where is the etherpad for this meeting? I looked on eavesdrop.openstack.org/#Airship_Team_Meeting, but the latest on there is 3/26.
16:19:38 <mattmceuen> Yeah, I think we have consensus, and it's just a matter of getting it in the PS
16:19:54 <mattmceuen> Hey ian-pittwood -- here you go: https://etherpad.openstack.org/p/airship-meeting-2019-04-16
16:20:08 <ian-pittwood> Thanks mattmceuen
16:21:04 <mattmceuen> I'll try to see when roman_g will be back, if "soon" I'll ask if he can update the PS, and if not I'll push a change, since we're all aligned based on previous discussion
16:21:21 <mattmceuen> anything else on this one arunkant or anyone else?
16:21:52 <arunkant> just need that patch approved so that other related reviews can get attention
16:22:09 <mattmceuen> yeah.  agreed
16:22:32 <mattmceuen> Alright, next topic:
16:22:36 <mattmceuen> #topic Python 3.7 - when should we start gating?
16:22:37 <arunkant> mattmceuen: If you are busy, I can also update the spec
16:23:07 <dwalt> That's me!
16:23:18 <mattmceuen> Thanks arunkant - will let you know :)
16:23:30 <dwalt> Felipe submitted a patch to gate Pegleg against python 3.7
16:23:49 <dwalt> are we ready to start doing that? If so, should we do the same for all components?
16:24:09 <dwalt> I personally have no objections but wanted to check here first
16:24:14 <mattmceuen> Couple thoughts:
16:24:27 <mattmceuen> 1. I am for consistency across Airship projects when feasible / reasonable
16:25:02 <mattmceuen> 2. iff any project fails gating against python 3.7, we should only introduce it as a non-voting gate for that project
16:25:19 <mattmceuen> Beyond that I don't have any opinions around what the right timing is
16:25:34 <openstackgerrit> Merged openstack/airship-treasuremap master: Sloop type and Airsloop site  https://review.openstack.org/649195
16:25:41 <mattmceuen> What do you guys think?  What's OpenStack's roadmap for 3.7 gates?
16:25:41 <mardim> ohhh ^
16:26:29 <openstackgerrit> Merged openstack/airship-spyglass master: Remove flask YAML web editor from Spyglass  https://review.openstack.org/650993
16:27:03 <dwalt> That sounds like a good plan to me. I'm not sure of the official roadmap
16:27:23 <ian-pittwood> +1. I think doing the nonvoting gate is a good start to see how far back we are from full support
16:27:29 <mattmceuen> python version-specific gating falls into that catogory of things I'd default to following the OpenStack projects on unless we find a reason not to -- they put a lot of thought into that stuff
16:27:44 <mattmceuen> cool
16:27:47 <openstackgerrit> Dimitrios Markou proposed openstack/airship-treasuremap master: [WIP] Create pipeline for airsloop site  https://review.openstack.org/649432
16:28:02 <michael-beaver> Same, no idea about the official roadmap, but I think at least getting a non-voting gate in would be good
16:28:10 <mattmceuen> dwalt can I give you an action item :D  it's the tax for bringing it up
16:28:18 <openstackgerrit> Dimitrios Markou proposed openstack/airship-treasuremap master: [WIP] Create documentation for airsloop site  https://review.openstack.org/651652
16:28:27 <openstackgerrit> Kaspars Skels proposed openstack/airship-treasuremap master: Enable nested virtualization by default  https://review.openstack.org/652139
16:28:29 <dwalt> mattmceuen: action item me, please :)
16:28:34 <mattmceuen> #action dwalt to check on the OpenStack roadmap for python versions and gating
16:28:41 <mattmceuen> let us know what you find
16:28:45 <dwalt> will do!
16:29:10 <mattmceuen> I think, for any project that is already 3.7-friendly, we should go ahead and make it voting -- we don't want regression away from a working configuration
16:29:32 <mattmceuen> But for any projects (if any) that aren't 3.7-friendly a non-voting gate gives us time to fix
16:29:37 <michael-beaver> ++
16:29:37 <AlexanderHughes> +1
16:29:39 <ian-pittwood> +1
16:29:41 <mattmceuen> ok, I think we beat that into the ground enough
16:29:47 <mattmceuen> thanks for bringing that up dwalt
16:30:12 <dwalt> sure thing
16:30:42 <mattmceuen> dwalt per the comment in the etherpad -- if you find the "justification" behind the python version roadmap (e.g. corresponding python version lifecycle stuff, etc) please let us know what you find
16:30:46 <mattmceuen> ty
16:31:06 <mattmceuen> Next topic:
16:31:21 <mattmceuen> #topic Pegleg support for custom character pool during passphrase/salt generation
16:31:42 <mattmceuen> alexanderhughes that's yours, right?  My monitor is bad at differentiating shades of purple ;-)
16:31:50 <AlexanderHughes> yes
16:31:51 <mattmceuen> https://storyboard.openstack.org/#!/story/2005372
16:31:55 <mattmceuen> awesome, go for it
16:32:25 <AlexanderHughes> in patch https://review.openstack.org/#/c/648701/ we changed pegleg's generate cryptostring function to only use a small set of special characters in order to reduce the likelihood of a generated salt/passphrase breaking an application or database
16:32:44 <AlexanderHughes> during discussions in that patch @lamt felt it would be a good idea to let the user override the default pool of characters by passing their own - and I agree
16:33:27 <AlexanderHughes> there are outstanding questions on how to accomplish this - such as minimum complexity requirements in a passed custom pool (do we require all 4 sets of characters - upper/lower/number/symbol) or change the minimum length?
16:34:06 <mattmceuen> I guess everyone's security rules are different!
16:34:22 <mattmceuen> So, thinking out loud:
16:34:23 <evgenyl> I'm wondering if there is some standard on password complexity that we can follow.
16:35:14 <AlexanderHughes> agreed, and for that reason I am of a mind that the default behavior is good enough for most use cases... if there is a case where a user needs to override that behavior they should be responsible for that pool.  my suggestion is if they require a password with only upper and lowercase letters for example the only requirement we have on them is the existing length requirement, and at least one character from each uppercase
16:35:16 <AlexanderHughes> passphrase
16:35:47 <mattmceuen> Since Pegleg is actually generating the passphrase, it makes sense to ensure somehow that it can follow reasonable operator needs
16:36:05 <mattmceuen> But we shouldn't go too far overboard IMO
16:36:20 <mattmceuen> I.e., password rules are notoriously hard and different
16:37:02 <mattmceuen> As long as Pegleg supports passphrase generation that is
16:37:02 <mattmceuen> 1) stronger than the operator rules
16:37:02 <mattmceuen> 2) doesn't violoate any operator assumptions
16:37:02 <mattmceuen> I think we should be good right?
16:37:24 <mattmceuen> #2 is the character set thing - we don't want to break a database
16:37:57 <mattmceuen> I mean, an operator could always base64 the passphrase from pegleg if they needed to, too
16:38:24 <mattmceuen> Which is what Kubernetes does vis a vis secrets
16:38:27 <AlexanderHughes> correct, and in patch 648701 we limited the punctuation characters to just the following @#&-+=?  but I am concerned there may be a case now we aren't aware of - or will be in the future where this set of characters runs afoul of what the user wants/needs
16:38:59 <openstackgerrit> Dimitrios Markou proposed openstack/airship-treasuremap master: [WIP] Create documentation for airsloop site  https://review.openstack.org/651652
16:40:24 <AlexanderHughes> so ultimately the question is - 1. do we need to support custom pools, and 2. if we do what limitations do we place on that pool, if any
16:41:25 <dwalt> It doesn't sound like this is a high priority item, as this was changed for compatibility with OpenStack services, right?
16:41:39 <mattmceuen> My opinion is 1. "no", as long as we address the common problems with the default / hardcoded pool.   We can add support in the future if needed, and an operator and b64 the passphrase if needed too
16:42:03 <dwalt> ++
16:42:17 <mattmceuen> What are your thoughts AlexanderHughes?  Agree/disagree?
16:43:03 <AlexanderHughes> Agree we can update the hardcoded pool as needed - if it gets to a point where there's not much left in the default pool revisit the idea of supporting custom pools
16:44:31 <mattmceuen> Awesome - sounds like a plan to me.  For the PS as-is, do we need to dial back the hardcoded pool now?  Or is it already a good choice as far as we know?
16:44:53 <AlexanderHughes> to our knowledge the patchset represents the broadest set of characters that works without issue
16:45:11 <mattmceuen> great!
16:45:45 <mattmceuen> Alright, moving on unless there's anything else on this topic:
16:46:04 <mattmceuen> #topic Spyglass plugin management
16:46:10 <ian-pittwood> This one's me
16:46:35 <mattmceuen> ian-pittwood -- can we use this as an opportunity to give anyone who doesn't know an elevator pitch of what Spyglass is?
16:47:44 <ian-pittwood> I just started working on it so I'm not sure if I'd have the best explanation yet
16:48:09 <mattmceuen> haha then let me try
16:48:19 <ian-pittwood> StaceyF is typing something right now too I think
16:48:20 <StaceyF> Spyglass is a tool that will be used to take data from a source (could be multiple sources)  that define what a site is and it will take data and format it specifically for Pegleg to consume (lint, collect, render) and then Pegleg will upload these documents to shipyard
16:48:48 <ian-pittwood> The part that this issue covers is the aggregation of data
16:49:04 <StaceyF> There will be different plugins that can be used by Spyglass depending on where that source data will come from
16:49:24 <ian-pittwood> Currently we have a couple hardcoded plugins that aggregate data for Spyglass to process. One is included in Spyglass, the other appears to reference closed source data
16:49:37 <mattmceuen> Thanks StaceyF.  The way I think of it is that Spyglass is intended to generate most/all of the site-specific YAMLs based on an external system of record, right?
16:49:47 <StaceyF> correct
16:49:59 <ian-pittwood> I want to take these plugins and separate them from Spyglass and I was curious what the crowd opinion is on how to do plugin management for openstack projects
16:50:18 <mattmceuen> Yeah, OpenStack is full of projects that have pluggable backends
16:50:49 <mattmceuen> Barbican might be a good example, since it's recent enough to have learned from mistakes of the past
16:50:58 <mattmceuen> And also because it's something we use in Airship
16:51:08 <ian-pittwood> Ok, I'll take a look at that
16:51:23 <mattmceuen> I haven't dug into it though, so that's just a thought -- anyone else have more solid advice?
16:52:39 <ian-pittwood> There's several different options to do it so I just wanted to make sure that Spyglass stays uniform with other projects
16:53:26 <mattmceuen> Yes, good call.  I'd also say look at Drydock of course, since that has a pluggable mechanism too (albeit with one prod-grade plugin at the moment)
16:54:10 <mattmceuen> alright, 5 mins remaining:
16:54:12 <ian-pittwood> Would the plan be to take the current plugins and place them into separate repos?
16:54:23 <mattmceuen> aha!  now that is a good question :)
16:54:50 <mattmceuen> I feel like that's an area where the openstack community has gone back and forth a bit (thinking tempest in particular)
16:54:59 <mattmceuen> I believe the best practice is separate repos
16:55:50 <mattmceuen> Anything else on this one, guys?
16:56:13 <dwalt> Nothing from me. Sounds like a good path forward
16:56:17 <mattmceuen> #topic Review Requests
16:56:22 <mattmceuen> Continuous-integration enhancements
16:56:22 <mattmceuen> https://review.openstack.org/#/q/status:open+branch:master+topic:ci/latest-htk
16:56:22 <mattmceuen> https://review.openstack.org/599020
16:56:22 <mattmceuen> https://review.openstack.org/653039
16:56:23 <mattmceuen> https://review.openstack.org/623549
16:56:23 <mattmceuen> https://review.openstack.org/651628
16:56:47 <mattmceuen> dwalt want to give a little overview on this collection?
16:57:22 <dwalt> Gladly. The first topic is an effort to add CI jobs to each repo (with charts) that packages against the latest Helm-tookit
16:57:51 <dwalt> Currently, Airship pins and gates against a stable version of helm-toolkit that is manually uplifted in a tools script
16:58:31 <dwalt> Secondly, there are a lot of patches out there for Airskiff, as it is ready to be added as a check job to Shipyard, Armada, and Deckhand
16:58:49 <mattmceuen> sweeeeet
16:59:14 <mattmceuen> That's great - looking forward to the Shipyard / Armada / Deckhand checks for sure
16:59:16 <dwalt> Since Airskiff has been unreliable as a gate in treasuremap due to the lack of cross-gating, I propose that we make it non-voting until the corresponding check jobs become voting
16:59:27 <dwalt> and the last two are necessary improvements
16:59:33 <mattmceuen> ++
16:59:47 <dwalt> that's all
16:59:52 <dwalt> I see we're short on time
16:59:54 <mattmceuen> For the latest-htk jobs, will those be voting or non-voting?
16:59:59 <dwalt> non-voting
17:00:08 <dwalt> moreso an indicator of being safe to upgrade
17:00:08 <mattmceuen> gotcha.  makes sense to me.
17:00:24 <dwalt> or - urgent fix is required
17:00:24 <mattmceuen> Thanks all for a great meeting, we are out of time but feel free to stay and chat :D
17:00:33 <dwalt> thanks!
17:00:40 <mattmceuen> #endmeeting