16:00:42 <mattmceuen> #startmeeting airship
16:00:43 <openstack> Meeting started Tue Apr  9 16:00:42 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:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:48 <openstack> The meeting name has been set to 'airship'
16:00:49 <mattmceuen> #topic Rollcall
16:00:54 <mattmceuen> GM / GE everyone!
16:01:01 <dwalt> o/ gm!
16:01:02 <michaelbeaver> o/ GM
16:01:03 <mattmceuen> Here's the agenda for today: https://etherpad.openstack.org/p/airship-meeting-2019-04-09
16:01:07 <seaneagan> o/
16:01:10 <levmorgan> o/
16:01:20 <mattmceuen> let's give it a couple mins for folks to trickle in and add items to the agenda
16:01:36 <arunkant> o/
16:01:42 <mfuller_> o/
16:02:26 <mattmceuen> hey everyone thanks for joining
16:03:55 <mattmceuen> ok, let's get started
16:03:58 <mattmceuen> #topic How do manage Roadmaps for Airship
16:04:24 <mattmceuen> Rodolfo wanted to discuss this one -- from the agenda
16:04:24 <mattmceuen> How does Roadmap items / features relate to storyboard or patchsets or labels
16:04:24 <mattmceuen> How do roadmap features relate to treasuremap Monthly Tags
16:04:30 <mattmceuen> All yours jezogwza
16:05:36 <jezogwza> Ok, originlly when we started we used milestones in git to drive definition of features and or milestone releases for the project. Doesnt seem we are doign that anymore
16:06:11 <jezogwza> Just wondering how we get back to something that allows us to build automation for the treasuremap , and release notes, etc that we can get behind
16:06:49 <mattmceuen> Excellent topic
16:07:20 <mattmceuen> As dwalt and myself scraped a ton of git logs to handcraft some release notes, this is near to my heart ;-)
16:07:40 <jezogwza> Do we know how other projects approach this?
16:07:41 <sthussey> There are several systems for turning the git history into release notes
16:08:22 <openstackgerrit> Rahul Khiyani proposed openstack/airship-maas master: Maas: Add pod/container security context       - deployment-ingress-errors.yaml  https://review.openstack.org/639200
16:08:59 <mattmceuen> The OpenStack standard-ish way is to use the OPenStack Reno project -- https://docs.openstack.org/reno/latest/
16:09:16 <mattmceuen> But I'd be interested in a value comparison among choices
16:09:35 <mattmceuen> Anyone have substantial experience (or opinions) on this?
16:10:48 <dwalt> I see that there is a sphinx extension for the openstack-reno one, that's a bonus
16:10:53 <mattmceuen> I did try setting up Reno once for OSH, but it never merged :))
16:11:02 * mattmceuen the extent of matts experience
16:11:20 <dwalt> mattmceuen: do you still have a link to that patch? Would be interested in taking a look at how it's set up
16:11:24 <jezogwza> That reno sounds interesting, how however that doesn't solve for Feature management/Roadmap ‌etc. But it could be at least part of that puzzle.
16:11:27 <sthussey> I think to get real value you'd first need better upstream tracking of defects and enhancements
16:11:43 <mattmceuen> Yep: https://review.openstack.org/#/c/563481/
16:11:47 <mattmceuen> Agree sthussey
16:11:48 <sthussey> Generally any of these systems are about turning metadata in commit messages into links to existing artifacts
16:11:53 <mattmceuen> Let's start there
16:12:14 <sthussey> https://github.com/github-tools/github-release-notes
16:12:22 <mattmceuen> So one thing we make hit-or-miss use of so far is using the "Story:" and "Task:" metadata in our commits
16:12:39 <mattmceuen> Those drive story lifecycle in storyboard if you use 'em
16:14:01 <jezogwza> Seems reasonable to start with choosing one of this tools as our next step.
16:14:22 <sthussey> https://blogs.sap.com/2018/06/22/generating-release-notes-from-git-commit-messages-using-basic-shell-commands-gitgrep/
16:14:34 <mattmceuen> Since kaspars__ is driving monthly releases of Treasuremap (and therefore, of "packaged" airship) does it make sense to start targeting/tracking scope in storyboard for these releases?
16:15:06 <jezogwza> I was hoping along with his monthly tags, we could at least delivery an understandig of what change between tags
16:15:22 <mattmceuen> ++
16:15:35 <sthussey> It will be non-trivial to generate that documentation
16:15:45 <mattmceuen> Monthly release notes will make Summittime release notes easy :)
16:15:55 <sthussey> As his tagged 'release' is an integration of lots of pieces
16:16:13 <sthussey> So either his release notes will just be 'Upgraded Airship-Drydock to x.y.z'
16:16:41 <sthussey> Or he'll need to start pulling in all the changes for all the pieces being integrated
16:16:45 <mattmceuen> Yeah, it will take some transitive data gathering to make that meaningful
16:16:47 <jezogwza> Could it be that each project can generate its own, and treasuremap just collects.
16:16:54 <seaneagan> we also don't even have x.y.z for airship components yet
16:17:35 <mattmceuen> The other option is to track scope / monthly releases in storyboard, and let that drive things-- storyboard tying it together directly, rather than the treasuremap integration per se
16:17:37 <jezogwza> Well it could be ok to start with Dydock : ps 1.. 10, Promenade psn..m, etc
16:17:59 <jezogwza> Its better than nothing
16:18:11 <sthussey> I would start with a commit message standard to contain the information that should go in the notes
16:18:21 <sthussey> because that is going to be the foundation of anything else
16:19:07 <mattmceuen> The little I know about Reno:  it uses a file full of metadata in the project, and then as "changelog worthy" changes are made, the file is appended to as part of the came commit
16:19:15 <mattmceuen> Just a different spin on the commit message approach
16:19:54 <sthussey> I prefer the mechanism of just turning commit msgs into release notes
16:20:08 <sthussey> For a commit that should be omitted, that can be declared in the commit msg
16:20:17 <sthussey> By default all commits should be accounted for in the release notes IMO
16:20:47 <mattmceuen> I suggest let's let this topic rest for today - think about it, select some potential tools / approaches, and revisit in a couple weeks.  Agree?
16:21:00 <jezogwza> Agree
16:21:14 <sthussey> Sure
16:21:23 <dwalt> Sounds like a plan
16:21:38 <mattmceuen> Ok cool.  I'll go out of order on the agenda slightly to make this a segueway then
16:21:42 <mattmceuen> #topic Airship PTG agenda
16:21:49 <mattmceuen> https://etherpad.openstack.org/p/airship-ptg-train
16:22:01 <mattmceuen> I took an initial stab at an agenda for the PTG
16:22:26 <mattmceuen> The PTG will be extra short this year, but there will be forums and things at the Summit proper, so I expect some convo to happen ahead of time
16:23:11 <mattmceuen> Please add in anything you'd like to discuss to the agenda, and then the things that we fit into our day-and-a-half  of focused discussion will be prioritized based on what needs the most discussion, and who's able to be there & what they want to discuss
16:23:52 <mattmceuen> The segueway bit is that I took a stab at laying out our big rocks of post airship 1.0 roadmap scope
16:24:15 <mattmceuen> I'm sure I missed some things so please add them in if so
16:24:42 <mattmceuen> I will plan to do a comparison between storyboard and that list to get them trued up a bit, as I know that's not all outlined in storyboard yet
16:25:14 <mattmceuen> Heads up that our PTG meeting time is Friday afternoon and Saturday morning and afternoon
16:25:44 <mattmceuen> If you have to cut out early please make a note in the etherpad so we prioritize things that need to be discussed on Friday with folks that will be there
16:25:54 <mattmceuen> That's all I have on that topic, anything else?
16:26:35 <mattmceuen> Ok, moving on:
16:26:41 <mattmceuen> #topic Proposed additional project:  airship-governance
16:27:18 <mattmceuen> We want to post a draft formal Airship governance document, so that we can iterate on discussion and fine tuning it
16:27:26 <mattmceuen> We need a place to push a patchset :)
16:27:59 <mattmceuen> OpenStack and Starling-X both have their own dedicated governance repos (links in agenda) and that seems to me to be a reasonable approach
16:28:16 <mattmceuen> As previously discussed we should get some quorum here before creating any new airship repos
16:28:38 <mattmceuen> Are you all ok with that approach for managing governance docs?  Or better ideas?
16:29:17 <mattmceuen> The value of a separate repo is 1) opportunity to limit the +2'ers down the road, 2) the repo won't change as frequently as other documentation
16:29:38 <mattmceuen> Please vote with +1 or -1
16:29:43 <dwalt> +1
16:29:45 <michaelbeaver> +1
16:30:21 <jamesgu__> +1
16:30:45 <arunkant> +1
16:31:03 <mattmceuen> Thanks guys - I will count that as "timeboxed unanimous" :)
16:31:03 <mfuller_> +1
16:31:21 <mattmceuen> Hope to get draft governance in front of y'all in short order
16:31:44 <mattmceuen> #action mattmceuen to submit request to create airship-governance repo
16:32:17 <mattmceuen> #action mattmceuen to review storyboard content against proposed roadmap scope in the PTG etherpad
16:32:36 <mattmceuen> ok, moving on:
16:32:43 <mattmceuen> #topic Multi-distro spec : How to get final inputs and approval
16:32:52 <mattmceuen> thanks for refreshing this arunkant
16:33:01 <mattmceuen> https://review.openstack.org/#/c/643106/
16:34:00 <arunkant> So looks like there are number of comments on suggestion and seems to be agreement on most of topics .
16:34:11 <mattmceuen> Agree
16:34:15 <mattmceuen> For folks who have given this a review already - let's give it a final review today
16:35:08 <arunkant> okay..so can we target this to be reviewed and possibly approved by end of this week ?
16:35:45 <mattmceuen> I think we should aim for that target  - let's get this done
16:36:08 <arunkant> okay..thanks
16:36:38 <mattmceuen> anything else on the multi-distro topic today folks?
16:37:21 <mattmceuen> ok - moving on:
16:37:34 <mattmceuen> #topic What is the recommended approach to Tempest testing in an Airship deployed site?
16:37:42 <mattmceuen> mfuller_ raised this
16:38:07 <mattmceuen> I think this is a multifaceted question mfuller_
16:38:32 <mattmceuen> Are you thinking along the lines of testing Airship itself via Tempest, or testing a deployed OpenStack on top of Airship?
16:38:49 <mfuller_> The latter, sorry I should have been more specific
16:39:01 <mattmceuen> No worries, I think they're both good questions ;-)
16:39:53 <mattmceuen> So yeah, the helm test flag on OSH components to use tempest is more geared around "helm test" type scenarios - smoke testing or ensuring the widget got deployed right
16:40:17 <mattmceuen> There is also a Tempest helm chart that OSH has that can be used for more full-suite Tempest validation
16:40:46 <mattmceuen> I'm not a Tempest expert, but I think the guys in #openstack-helm can probably point you to resources on how to get this started
16:41:26 <mattmceuen> So that is to say, "standalone chart" and "helm test" both have their place side by side
16:41:34 <mfuller_> My experience so far with the run_tempest flag has been mixed. Since it can be enabled per chart, I was expecting the tests would only require that service to be available, but even for services like glance, it requires a compute endpoint to already be defined and running
16:43:06 <mfuller_> However, if I instead wait until all OpenStack services are running, I've then run into an issue with the default roles that are created in keystone. The tempest verifier expects 'Member' to be there, but there's only 'member'
16:43:23 <mattmceuen> ug
16:43:30 <mfuller_> and a duplicate role error occurs
16:44:10 <mfuller_> So I wasn't sure if going this route was the best approach
16:44:46 <mattmceuen> I know that's something that had been dealt with in the past; I thought the OSH team had ironed those things out -- possible that a few remained hidden though. I believe the problem may have been that some of the Members changed to members (or vice versa) in some openstack release IIRC
16:45:15 <mattmceuen> I suggest you bring up that error in #openstack-helm and see if some of the tempest wizards there are already aware and have advice, or, if that's news
16:45:48 <mfuller_> Are there plans to implement a global chart for tempest in treasuremap?
16:46:42 <mattmceuen> I don't think there are plans now, but I don't see why it couldn't be added
16:47:18 <mattmceuen> Would you be able to collaborate on that mfuller_?
16:48:06 <mfuller_> Sure, absolutely, with the caveat that my chart authoring skills are still very green ;)
16:48:07 <mattmceuen> As the airship team knows the manifest parts well, but less experience with the tempest parts
16:48:14 <mattmceuen> Perfect collaboration then :)
16:48:40 <mattmceuen> #action mattmceuen to create Storyboard story to track adding Tempest to Treasuremap
16:48:53 <mattmceuen> thanks for bringing that up
16:49:20 <mattmceuen> #topic Roundtable
16:49:45 <mattmceuen> Any other topics you's like to discuss today?
16:50:27 <jamesgu__> matt: this may have been discussed previously... the airship services has its own htk definition, and osh services uses a common one. what's the reasons behind the difference?
16:50:32 <dwalt> I don't think roman_g is here, but does anyone know what items are outstanding for the transition to opendev?
16:51:13 <mattmceuen> jamesgu__:  I think the only difference is that they were assembled by different teams.  There are pros/cons both ways
16:51:27 <jamesgu__> we had a case (at leaast temporarily) we need to use a different version of htk between openstack services.
16:52:14 <mattmceuen> jamesgu__: in particular, the OSH comonents are all integrated together very frequently with OSH-Infra, so it pushes a little more toward the "keep it simple" approach as there's less likelihood of getting one version of HTK that is not compatible with all OSH charts
16:53:00 <jamesgu__> the use case we have is to upgrade/update a openstack service
16:53:07 <mattmceuen> jamesgu__: OTOH Airship is a collection of different projects, each of which may need to be pinned to a particular HTK due to compatibility reasons (e.g. recently a HTK upgrade impacted divingbell only)
16:54:04 <jamesgu__> right, I was wondering if the osh global charts in airship could build in the same flexbility of different htk chart versions.
16:54:07 <mattmceuen> Since it's all configuration-driven, I think that based on operator needs it's totally fine to have more than one HTK definition for an OSH setup when warranted
16:54:50 <mattmceuen> kaspars__ or evgenyl, do you have an opinion on that?
16:55:30 <mattmceuen> dwalt:  I haven't heard any updates.  Happen to know when roman_g is back?
16:56:01 <mattmceuen> jamesgu - can I add this as a topic for next week's meeting and get folks to think about it before then?
16:56:13 <jamesgu__> yes absolutely. thanks!
16:56:32 <mattmceuen> #action mattmceuen get some thoughts on splitting out HTK pins for OSH in TM
16:56:39 <kaspars__> I agree, in my view each component should have it's own HTK (e.g. nova, keystone) - but good to hear from OSH team more
16:57:04 <mattmceuen> That's exactly what I'm thinking too kaspars__, good to see what their lessons learned are
16:57:50 <mattmceuen> Couple minutes left, any last topics to bring up?
16:58:27 <mattmceuen> In that case -- thanks everyone for a great meeting
16:58:33 <mattmceuen> Appreciate your time and thought
16:58:37 <mattmceuen> have a good week.
16:58:41 <mattmceuen> #endmeeting