16:00:53 <mattmceuen> #startmeeting airship
16:00:54 <openstack> Meeting started Tue Jul  2 16:00:53 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:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:57 <openstack> The meeting name has been set to 'airship'
16:00:58 <hogepodge> hi
16:00:59 <mattmceuen> #topic Rollcall
16:01:02 <roman_g> o/
16:01:04 <alexanderhughes1> \o/
16:01:12 <mattmceuen> Hello everyone, here is our agenda du jour:  https://etherpad.openstack.org/p/airship-meeting-2019-07-02
16:01:22 <mattmceuen> Let's give it a couple mins for folks to join and add things to the agenda
16:01:49 <ian-pittwood> o/
16:03:16 <mattmceuen> alrighty
16:03:20 <mattmceuen> #topic Announcements
16:04:12 <mattmceuen> First off -- voting for our TC will commence later today.  Contributors should get a one-time-use email in their inbox later today; please let me know if anyone doesn't get it
16:04:18 <mattmceuen> voting will last for one week
16:05:14 <mattmceuen> Thank you in advance to everyone who is running, it's really awesome to see folks from six different companies having nominated, not to mention that all the candidates are fantastic individuals.
16:05:21 <mattmceuen> Next:
16:05:23 <mattmceuen> Starting next week:  meeting time is 2pm UTC (2 hours earlier than today)
16:05:37 <mattmceuen> I think we discussed this last week, so this is just a reminder!
16:05:53 <mattmceuen> Next:
16:06:17 <mattmceuen> A project proposal was approved by the OPNFV TSC this morning, to leverage Airship as a reference installer for standard NFV infrastructure
16:06:31 <hogepodge> mattmceuen: have we updated the meeting time in the opendev calendar?
16:06:34 <mattmceuen> (the standards focus on telco-grade NFVI and are still being authored)
16:06:42 <roman_g> mattmceuen: Any links to that?
16:06:44 <mattmceuen> hodgepodge:  nope, good catch, thank you!  I'll update today
16:06:59 <mattmceuen> roman_g:  I don't believe so yet, but I will share as soon as I get some
16:07:05 <roman_g> thanks
16:07:13 <mattmceuen> I know some folks in our community have been contributing to that already, like kskels
16:07:49 <mattmceuen> So more to come, but that's a really exciting way to help make sure Airship remains aligned to some of the more telco-oriented use cases that are developing in the industry!
16:07:54 <roman_g> yes, IRC meeting time should be updated in several places (wiki, eavesdrop repo, and may be soemwhere else) + e-mail to announcement mailing list
16:08:12 <kskels> fyi: good page for opnfv -> https://wiki.opnfv.org/display/PROJ/Project+Proposals+Airship
16:08:20 <mattmceuen> thx kskels
16:08:32 <roman_g> kskels: thank you
16:09:13 <mattmceuen> For background, here's a link to an article from a while back about the NFVI standards effort itself: https://www.telecomtv.com/content/nfv/csp-led-nfvi-task-force-to-be-hosted-by-gsma-35623/
16:09:25 <mattmceuen> roman_g:  thanks for that, I'll make sure to check the boxes
16:09:43 <mattmceuen> A few extra reminders are always a good thing :)
16:10:32 <mattmceuen> roman_g:  was making sure the meeting time got communicated out fully all you wanted to discuss for this one:     Update meeting time results: https://etherpad.openstack.org/p/airship-meeting-vote-2019
16:10:47 <mattmceuen> Or is there more we should discuss as well?
16:11:07 <roman_g> Тщб ше огые туувы ещ иу гзвфеув цшер куыгдеы
16:11:16 <roman_g> No, it just needs to be updated with results
16:11:26 <mattmceuen> Ok awesome - I will do so
16:11:50 <mattmceuen> Anthing else on these announcements before we move on?
16:12:52 <mattmceuen> #topic     Follow up on PostgresHA
16:13:03 <mattmceuen> https://review.opendev.org/#/c/657667/
16:13:10 <mattmceuen> This one's yours roman_g, take it away
16:13:57 <roman_g> Well, it's yours, Matt. Do we just get it merged as a complete work or is anything else is missing?
16:14:01 <mattmceuen> Reviews on that PS would be appreciated :)
16:14:17 <roman_g> Do any docs need to be updated on it?
16:14:26 <roman_g> except tools/upgrades/postgresql/README.md
16:14:33 <mattmceuen> I need to double check  on it in seaworthy
16:15:39 <mattmceuen> I'm not aware of any other docs that need updating on behalf of HA Postgres, if anyone's aware of any please let me know and I'll be sure to update.
16:15:48 <roman_g> OK, OK.
16:16:06 <mattmceuen> I'll make sure whether that PS is good to merge or not in the next couple days, thanks for bringing it up roman_g
16:16:41 <mattmceuen> #topic Follow up on Code formatting standardization across projects
16:17:05 <mattmceuen> Good one to revisit, we'd brought up a few weeks ago that there may be benefit to standardizing across projects a bit
16:17:12 <mattmceuen> (or a bit more, I should say)
16:17:46 <roman_g> alexanderhughes1 started to do some changes to projects. Just wanted to be sure we have code formatting and style documented.
16:18:21 <alexanderhughes1> yeah I did things backwards.  I have a proposal out for Pegleg now https://review.opendev.org/#/c/664125/ looking for thoughts on live reformat.  then put those thoughts into documentation for other projects
16:18:29 <mattmceuen> alexanderhughes1: thanks for getting those changes started.  Is there anything we need to levelset on as a patchset against the documentation as well?
16:18:55 <alexanderhughes1> like to get people's thoughts on what I have up now so they can see how those knobs in YAPF actually affect the code.  then take those into documentation for the other projects
16:19:28 <roman_g> alexanderhughes1: to here, please: https://airshipit.readthedocs.io/en/latest/code-conventions.html#linting-and-formatting-standards
16:19:34 <roman_g> add it there
16:20:20 <alexanderhughes1> sure.  I'll add thoughts there on what I have going so far, and link back to the patchset in progress
16:20:32 <roman_g> your PS for Pegleg looks good, but I'm nowhere expert in formatting :)
16:21:04 <mattmceuen> that would be awesome alexanderhughes1.  I think getting the PS against the docs will be a good way to position the pegleg changes as the beginning of cross-project alignment
16:21:15 <alexanderhughes1> thanks :)  I'll link both ways so people can see the proposal, and how it looks in practice, and add my reasoning for selecting these knobs
16:21:53 <mattmceuen> excellent
16:22:14 <mattmceuen> Anything else on cross-project standards before moving on?
16:22:34 <alexanderhughes1> not specific to the python projects - but want to keep thinking about airshipctl
16:23:01 <roman_g> Golang?
16:23:18 <alexanderhughes1> right now we're talking about gates for gofmt for code submitted which is a good start.  this doesn't impact imports that are separated with a blank line.  should standardize that as we did in python projects https://docs.openstack.org/hacking/latest/user/hacking.html#import-order-template
16:23:35 <mattmceuen> yeah, would be great to have some conventions off the bat.  I think the only contention we have is "use the go formatter" which already solves a multitude or problems
16:24:13 <alexanderhughes1> yeah gofmt is huge - but the one thing it's missing is import orders.  if I have a block of 3 then a block of 2, then a block of 4.  each of those blocks separated by a blank line will be sorted alphabetically within their own block
16:24:28 <alexanderhughes1> but we'll want to address what each block represents, https://docs.openstack.org/hacking/latest/user/hacking.html#import-order-template is a good candidate
16:25:33 <mattmceuen> Want to propose that as a separate PS against our code style docs alexanderhughes1?  Add a subsection for golang, with our one for-sure bullet and your additional proposal?
16:25:57 <alexanderhughes1> glad to :)
16:26:10 <mattmceuen> excellent
16:26:40 <mattmceuen> Ok - moving on!
16:26:44 <mattmceuen> #topic     Roman needs help: https://review.opendev.org/#/c/668038/ - tests fail
16:27:05 <mattmceuen> want to give us an overview of this one roman_g?
16:27:21 <roman_g> Alex helped to understand where the problem lies. Now I need to understand how to fix it.
16:27:53 <roman_g> Basically I broke encryption tests with this PS, and did not understand why is that happening.
16:28:15 <roman_g> So.
16:28:49 <roman_g> Let's move on to other topic. I need to digest what Alex said to be ealier today (in logs above, prior to the meeting).
16:29:44 <mattmceuen> Ok, that sounds good.  Can definitely discuss more in the channel here as well later today
16:29:48 <mattmceuen> thanks guys
16:29:59 <mattmceuen> Next up!
16:30:05 <mattmceuen> #topic Docs project now exists:  next steps
16:30:15 <mattmceuen> we now have a https://opendev.org/airship/docs project !
16:30:33 <mattmceuen> We had discussed this a while back, with the goal of being the home of cross-airship documentation
16:30:54 <mattmceuen> (project-specific documentation would continue to live in their projects)
16:31:21 <mattmceuen> We have a list in an etherpad, but sorry, I don't have it at my fingertips at the moment.   The gist of what we want to move in, however, is:
16:31:38 <mattmceuen> 1: all the documentation from the AIAB project
16:31:50 <mattmceuen> 2: all the non-treasuremap-specific documentation from treasuremap
16:32:42 <roman_g> 1: pending PS reviews.
16:33:06 <roman_g> 2: what is non-treasuremap-specific documentation in treasuremap?
16:33:07 <mattmceuen> from treasuremap, that means the Dev Guide, Troubleshooting Guide, Site Authoring Guide, and Config Update Guide would move I believe -- does that sound right kskels?
16:33:24 <roman_g> kskels: step in
16:33:24 <mattmceuen> And then Airskiff, Airsloop, Seaworthy docs would continue to live in TM
16:35:24 <mattmceuen> It's possible that the SIte Authoring / Config Update guides should continue to live in TM, since they're so TM YAML-oriented
16:35:45 <mattmceuen> A case could be made either way for those
16:36:24 <roman_g> Kaspars is not here. Let's leave it for now.
16:36:44 <mattmceuen> Agree, we can circle back later
16:37:12 <mattmceuen> However, we do need gates in `docs`, I don't believe we have any yet
16:37:17 <mattmceuen> unless you've added any roman_g?
16:37:23 <roman_g> added, yes
16:37:26 <mattmceuen> sweet!
16:37:29 <roman_g> waiting for review
16:37:29 <mattmceuen> Thank you :)
16:37:37 <mattmceuen> I am behind in reviews this week, sorry
16:37:41 <roman_g> welcome :)
16:38:12 <mattmceuen> After we get the docs migrated from AIAB, I think that `docs` can take over responsibility for pushing rendered docs to readthedocs.io as well
16:38:52 <roman_g> this is ready to be reviewed and merged.
16:39:08 <roman_g> including migration of docs from AIAB to docs repo
16:39:12 <mattmceuen> beautiful.  Ok, I think we're going in a good direction here and can follow up with kskels for that last detail later
16:39:15 <mattmceuen> That's awesome
16:39:38 <mattmceuen> once we have the skeleton and seed content in docs, it'll make it easier for others to contribute more.
16:39:56 <mattmceuen> so, moving on!
16:40:04 <mattmceuen> #topic Revisit using `cicd layer` for overrides on top of a site definition
16:40:21 <mattmceuen> So the problem statement is:
16:40:43 <mattmceuen> We want to be able to apply overrides against some of the sites we have today
16:40:53 <mattmceuen> E.g. "airskiff but with opensuse overrides"
16:41:02 <mattmceuen> e.g. "aiab but with tungsten fabric SDN"
16:41:31 <mattmceuen> A few weeks ago we floated the idea of using a rumored `cicd` layer underneath `site` to accomplish this
16:42:00 <mattmceuen> however, in getting in to the details of that this morning, it's not perfectly straightforward, as pegleg does not support that yet
16:42:32 <mattmceuen> note:  we're going to support service layer type functionality with Airship 2.0
16:42:48 <mattmceuen> (details are still TBD but it must/will happen)
16:43:17 <mattmceuen> So what we need to figure out in the meantime, how can we best support these types of use cases/overrides in the meantime, using the Airship 1.x tools we have?
16:44:15 <mattmceuen> alexanderhughes1 we had just started talking about, if we were going to add a "legit" fourth layer, where would we insert it
16:44:40 <mattmceuen> between `type` and `site` potentially?
16:45:57 <roman_g> could we define a sequence of layers application?
16:46:06 <roman_g> sequence of overrides
16:46:32 <jamesgu> mattmceuen: not trying to throw another wrench into it. does the gate run against a single version of openstack currently, or multiple versions? I see the overrides for some OSH charts start to have default release specific overrides?
16:47:31 <mattmceuen> roman_g:  I think that's basically what we have today, but we have a sequence of three -- and that doesn't give us enough "space" to do all the config de-duplication we want anymore
16:47:41 <alexanderhughes1> well there's a couple things, and we'd want to POC it - but at a high level one possible solution might be adding to layering-definition.yaml "overrides" at bottom of list, on top of the site.  add to that site-definition.yaml an override_type definition, then create override documents that would exist in a /path/to/override/definitions/
16:48:14 <mattmceuen> jamesgu: we don't do testing of different sets of openstack overrides in treasuremap today, testing different versions of openstack is more osh territory
16:48:16 <alexanderhughes1> then tell pegleg to collect all the documents for the site (global, type defined by site-def, site name, and overrides defined by site def)
16:49:33 <mattmceuen> how much effort do you think that would be from a pegleg perspective, alexanderhughes1?
16:50:07 <alexanderhughes1> still preliminary thoughts, I can play with it over the weekend and see what struggles I have and discuss next week
16:50:37 <mattmceuen> Does that exactly solve the problem, though -- if you configure your site to pull extra overrides declaratively, that is great.  but,
16:50:49 <mattmceuen> we have an airskiff site that we don't want to pull in overrides
16:51:05 <mattmceuen> in the default case, at least
16:51:18 <mattmceuen> but then we want to pull in overrides against it in other cases
16:51:22 <mattmceuen> Let me clarify
16:51:34 <mattmceuen> we want to say "deploy airskiff" and "deploy airskiff, but with opensuse"
16:51:52 <mattmceuen> if airskiff (site) is hardwired to pull overrides, then it would always pull in opensuse
16:52:27 <mattmceuen> anyway - I think we've explored the solution space a bit
16:52:36 <mattmceuen> like you said alexanderhughes1, let's think about this
16:52:41 <alexanderhughes1> that's the sticking point, if we want to pull in overrides we have to tell Pegleg somehow.  the least amount of duplication off the top of my head is modifying site-def
16:52:49 <mattmceuen> jamesgu: however, I don't want to hold you up either
16:53:07 <mattmceuen> A couple options on how we could proceed in the meantime with opensuse airskiff
16:53:33 <mattmceuen> 1. make a copy of airskiff, with the intention of de-duplicating those manifests once we have a path forward ironed out
16:53:55 <mattmceuen> 2. make a "do not merge" patchset against airskiff, applying opensuse overrides, until we have a path forward ironed out
16:54:06 <kskels> I think airkiff using sloop can be made fairly lightweight - so duplication would be minimal
16:54:13 <kskels> didn't we have a patchset for that somewhere @drew
16:54:25 <mattmceuen> dwalt: ? ^
16:55:02 <dwalt> yes! There is a patch; however, it recently entered merge conflict
16:55:07 <dwalt> I'll send it over
16:55:10 <mattmceuen> alexanderhughes1:  I like the idea of having separate sites for airskiff and airskiff-opensuse, as long as "most of their manifests" live somewhere outside the site level
16:55:50 <mattmceuen> awesome ty dwalt
16:55:51 <dwalt> #link https://review.opendev.org/656882
16:56:10 <mattmceuen> well we have enough to stew on, gotta keep moving as the end of the meeting time is nearly upon us
16:56:27 <mattmceuen> let's please keep the ball moving before those of us in the US go on holiday!
16:56:49 <mattmceuen> #topic Review Requests
16:56:54 <mattmceuen> https://review.opendev.org/#/c/664045/ - Check sync of only active MaaS rack controllers
16:56:54 <mattmceuen> https://review.opendev.org/#/c/668020/ - airship/docs docs and gates for docs
16:56:54 <mattmceuen> https://review.opendev.org/#/c/668664/ - airship/docs Import documentation from airsip-in-a-bottle
16:56:54 <mattmceuen> https://review.opendev.org/668665 - airship/airship-in-a-bottle Export all documents to Airship Docs project
16:56:54 <mattmceuen> https://review.opendev.org/#/c/667707/ - airship/treasuremap (calling Pegleg in container under non-root user) Fix: git module requires user to exist
16:56:54 <mattmceuen> https://review.opendev.org/#/c/661004/ - airship/treasuremap treasuremap updater script, Add cross-verification of Git commit ID'd and image tags
16:56:54 <mattmceuen> https://review.opendev.org/#/c/666606/ - Airship mailing list for CI errors reporting; Cores: add +1's, please
16:56:55 <mattmceuen> https://review.opendev.org/#/c/667318/ - airship/election - rts formatting fixes
16:56:55 <mattmceuen> https://review.opendev.org/668650 - airship/election Add gate for docs build
16:57:00 <mattmceuen> Lots of requests for reviews this time
16:57:21 <mattmceuen> Let's clean up some of our open patches, there's a lot going on and it will be good to get merged what is ready!!
16:57:37 <mattmceuen> Any additional PS team?
16:57:57 <alexanderhughes1> need to add another -- https://review.opendev.org/#/c/668517/ this patch adds support for Pegleg to use a site encrypted set of global passphrase/salt, and then use those global keys to encrypt/decrypt any global layer documents
16:58:28 <alexanderhughes> can be expanded to type level if we wanted
16:59:25 <mattmceuen> thanks alexanderhughes, good add and I'll take a look
16:59:41 <alexanderhughes> IE if every site needed to be able to use some passphrase, and it was encrypted with a global passphrase Pegleg will be able to decrypt it if you store the global passphrase as an encrypted document along with the other site encrypted documents
17:00:22 <mattmceuen> that's a wrap folks -- for those of us in the US have a happy Fourth of July!  For everyone else - well hopefully you have a great Fourth of July too :D
17:00:31 <mattmceuen> #endmeeting