14:00:04 <mattmceuen> #startmeeting airship
14:00:05 <openstack> Meeting started Tue Aug  6 14:00:04 2019 UTC and is due to finish in 60 minutes.  The chair is mattmceuen. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:09 <openstack> The meeting name has been set to 'airship'
14:00:10 <mattmceuen> #topic Rollcall
14:00:19 <alexanderhughes> o/
14:00:20 <mattmceuen> Hey everyone, GM / GE!
14:00:21 <howell> o/
14:00:22 <nishantkr> o/
14:00:25 <mattmceuen> Agenda: https://etherpad.openstack.org/p/airship-meeting-2019-08-06
14:00:31 <evgenyl> Hi everyone!
14:00:33 <mattmceuen> please add any discussion topics for today to this^
14:00:39 <mattmceuen> o/ all
14:00:50 <mattmceuen> we'll give it a min for folks go get their laptops warmed up
14:00:55 <jamesgu> o/
14:01:31 <evrardjp> o/
14:01:43 <dwalt> o/
14:02:04 <openstackgerrit> Marjorie Middleton proposed airship/porthole master: Initial Commit of compute-utility container code compute-utility pod permits access to functionality of several compute pods.  https://review.opendev.org/674695
14:02:37 <mattmceuen> ok, let's get started:
14:02:42 <mattmceuen> #topic Update Eavesdrop to include links to other Airship meetings?
14:02:50 <mattmceuen> go for it alex
14:03:45 <alexanderhughes> hi, we've got a large number of meetings and it seems we keep adding more.  it's great that people are interested in various aspects of airship design - I was just wondering especially for new users that haven't subscribed to the mailing lists they're missing out on some opportunities to join our discussions
14:04:04 <alexanderhughes> can we add these meetings to eavesdrop?  we have 5 a week now that I know of
14:04:20 <mattmceuen> we have been adding them to the wiki, but you're right, not evesdrop:  https://wiki.openstack.org/wiki/Airship
14:04:29 <mattmceuen> I think it makes sense to add them
14:04:36 <alexanderhughes> and for the new users those email lists I mention above can be found at #link lists.airshipit.org
14:05:41 <mattmceuen> if we add new meetings, would they show up under the existing Airship header?
14:05:58 <mattmceuen> or would Airship end up with five list items on an already-crowded list
14:06:19 <evrardjp> I would prefer eavesdrop, because ics generation is neat :)
14:06:26 <mattmceuen> ++
14:06:59 <alexanderhughes> can we rename airship team meeting -> Airship community meetingS and then add each in our section?
14:07:17 <evrardjp> alexanderhughes:  yeah, It's possible to have multiple meetings
14:07:23 <evrardjp> I mean
14:07:31 <roman_g> o/
14:07:44 <evrardjp> because it's possible to add multiple meetings, it would be clearer to have each of them named appropriately :)
14:07:46 <alexanderhughes> just thinking about organization in the summary list where our link is.  having 5 meetings seems overkill, but if you can click on our link then browse our short section it's a good balance in my mind
14:08:25 <evrardjp> Just pointing to eavesdrop?
14:08:29 <mattmceuen> It looks like you might not get much differentiation between what the different time slots under a "header" are for
14:08:32 <evrardjp> Or adding all the meetings into one ics
14:09:03 <mattmceuen> I.e., I see Auto-scaling SIG Meeting has two different invites, but I don't see that you can differentiate between different topics (SIG-X, SIG-Y) for them?
14:09:07 <evrardjp> I think it's fine to have multiple meetings, because not everybody care about everything
14:09:17 <alexanderhughes> ah I see.  yeah maybe we need 5 separate entries
14:09:36 <evrardjp> mattmceuen: because that's the same meeting different timezones
14:09:36 <mattmceuen> Let's start with that since it's good for us, and if it's frowned upon, we should find out in code review :)
14:09:53 <evrardjp> for different meetings see for example the OpenStack TC, which has meetings and office hours
14:09:55 <mattmceuen> evrardjp advanced technology!!
14:10:05 <mattmceuen> what will they think of next
14:10:10 <evrardjp> mattmceuen: ics is so 21th century
14:10:14 <mattmceuen> lol
14:10:15 <alexanderhughes> lol
14:10:40 <alexanderhughes> I'm happy with that, just want to make finding logs, calendar invites etc. easier for people in general to stay up to date with airship progress/news
14:10:59 <mattmceuen> was just going to ask for volunteer :)  that's a great idea alexanderhughes, thanks for bringing it up
14:11:33 <evrardjp> alexanderhughes: I don't have Airship in my agenda because there is no eavesdrop link , so I rely on 20th century tech called human memory
14:11:41 <evrardjp> very not reliable depending age of said tech
14:11:48 <alexanderhughes> haha
14:11:51 <mattmceuen> :D
14:12:09 <mattmceuen> alright - I think we can move on to the next topic:
14:12:15 <mattmceuen> #topic Airship WC election requirements
14:12:39 <mattmceuen> So in our ongoing working committee election process, we have hit a first-time-through bump
14:13:05 <evrardjp> it's not really a bump IMO :)
14:13:28 <mattmceuen> A handful of folks who had nominated for the committee were admitted by the election officials, and post-hoc discovered not to be eligible per airship governance description of eligibility
14:13:37 <mattmceuen> So they have been withdrawn
14:13:58 * mattmceuen feels very bad - mea culpa 100%
14:14:11 <evrardjp> mattmceuen: you shouldn't worry about that : )
14:14:21 <mattmceuen> Really appreciate the nominations and hope all of these excellent gents nominates again in the future
14:14:22 <evrardjp> I expect there is no hard feelings
14:14:28 <mattmceuen> ty jp :)
14:14:47 <evrardjp> everybody is doing their best, and as you can see, there is willingness to step up ;)
14:14:52 <evrardjp> mattmceuen: yw :)
14:15:15 <mattmceuen> Yes, it's really awesome to see the community growth and community involvement
14:15:16 <pramchan62> Any idea what requirements were difficult to meet?
14:15:24 <mattmceuen> Yes - let's discuss
14:15:35 <mattmceuen> So the TC requirements are different than the WC requirements
14:15:36 <evrardjp> well tbh it's not the requirements that I would like to discuss
14:15:48 <evrardjp> on that topic
14:15:54 <evrardjp> it's to make sure it doesn't happen ? :)
14:15:58 <evrardjp> again*
14:16:11 <evrardjp> (implementing a job for validating, like it's done in openstack?)
14:16:18 <pramchan62> ok
14:16:20 <mattmceuen> TC candidates are broadly eligible based on contributions to the community.  WC candidates are more narrowly eligible based on having gotten commits merged to a repo in the previous 12 months
14:16:20 <evrardjp> (sorry to highjack this!)
14:16:51 <mattmceuen> I think step 1 is to better understand the requirements, lol
14:17:06 <evrardjp> on that I can blame myself for not reading appropriately
14:17:08 <mattmceuen> Step 2 is to either automate them or have a rote process to validate them
14:17:12 <mattmceuen> #same
14:17:52 <pramchan62> Is zull pipeline setup for airship 2.0 modules yet?
14:17:58 <pramchan62> Zuul
14:18:01 <mattmceuen> evrardjp, are there any best practices you're aware of that could help with that?
14:18:12 <mattmceuen> from the openstack community, which has been doing this for a while
14:18:42 <evrardjp> yeah we do have jobs for that in the election repo -- I suggest to speak with current election officials on how the zuul jobs are set up
14:19:34 <mattmceuen> we should be able to incorporate their functionality; our election repo was based on theirs, but with most of the automation turned off in the interest of time
14:19:35 <evrardjp> you would have to do something special for the affiliation afaik, but that probably should be done after election results
14:19:39 <mattmceuen> would be good to refine that for the next round
14:19:44 <evrardjp> which is after candidacies
14:19:55 <mattmceuen> cool
14:20:15 <evrardjp> mattmceuen: yup. To make things simpler, having only one set of requirements would be easier too
14:20:29 <evrardjp> for the test jobs I mean
14:21:10 <mattmceuen> pramchan62:  the first module targeted for 2.0 (airshipctl) has zuul gating set up; we'll keep adding gates as we keep adding modules
14:21:56 <mattmceuen> I think that'll be a good thing to retrospect on - the TC can adjust the requirements if we propose reasonable changes
14:22:30 <alexanderhughes> agreed, I can add this as an action item to the TC agenda.  I'd like to take a second look at the WC requirements for next election cycle
14:22:50 <jamesgu> ++
14:23:20 <mattmceuen> alright, anything else on this topic?
14:23:39 <mattmceuen> we'll be kicking off the voting later today
14:24:09 <alexanderhughes> just a heartfelt apology to those that ran and were disqualified after their nominations were merged, and thanks for your understanding with our stumbles.  we'll get better over time
14:24:36 <mattmceuen> ++
14:24:46 <mattmceuen> Ok!  next topic:
14:24:51 <mattmceuen> #topic Aligning airskiff to sloop type has presented challenges
14:25:07 <mattmceuen> So jamesgu has been working on some manifest alignment
14:25:14 <mattmceuen> between sloop and airskiff
14:26:01 <mattmceuen> one of the goals of this is to make it easy(er) to have airskiff sites that are customized, e.g. for opensuse images
14:26:34 <mattmceuen> I think we've exhausted the wiggleroom in our three-layer (global, type, site) hierarchy in trying to get all of this aligned.  Challenges include:
14:27:15 <jamesgu> yes, the challenge is that we only allow one shot at replacement in armada manifest, airskiff has to duplicate the abstract charts, certs, etc in airskiff site. Now we are going to make it worse with airskiff-*
14:27:42 <mattmceuen> airskiff doesn't need kubernetes widgets (e.g. etcd), but has to override them in its list of "unused" charts.  To me it feels like cauterizing abstract documents we don't want anyway.  These docs would need to be duplicated across airskiff-X and airskiff-Y
14:28:07 <jamesgu> sorry crossed msgs
14:28:30 <jamesgu> mattmceuen: I added option b in the agenda
14:28:37 <mattmceuen> yeah, one-shot replacement makes sense in some contexts, but jamesgu ran into wanting to replace the full-site manifest that was already replaced at the type level
14:28:41 <mattmceuen> no worries :D
14:29:11 <mattmceuen> I'll paste the ideas in here as well:
14:29:11 <mattmceuen> option a:Make a "skiff" a type?
14:29:11 <mattmceuen> option b: remove the full-site and cluster-bootstrap manifest from sloop type (means airsloop will add its own full site and bootstrap yaml as its own armada manifest)
14:29:38 <kskels> maybe we need to talk about it more - but there are ways to workaround it by creating charts/chart-groups with different names
14:29:52 <kskels> even for full-site - in shipyard it's possible to specify which full-site manifest to run
14:30:10 <kskels> also, I think we should make replacement somehow multi-level.. wonder if that is possible
14:30:35 <openstackgerrit> Luna Das proposed airship/porthole master: Add Tracking User Identity in openstack utility container logs  https://review.opendev.org/674808
14:30:41 <dwalt> So if we add a skiff type, we still have to override unused documents. Are there other benefits to doing so?
14:30:53 <jamesgu> kskels: agree that replacement should be multi level.
14:31:09 <mattmceuen> the idea there dwalt is that at least we'd only be overriding them once at the type level, and airskiff-X becomes easy
14:31:20 <dwalt> The idea behind using sloop for Airskiff was only that it reduced the replica count and reduced the total number of Airskiff-specific documents slightly
14:31:29 <jamesgu> the issue is the sloop site manifest full-site and cluster-bootstrap... both of which incudes the k8s charts for example
14:31:54 <kskels> yes - but can't we just choose different name for them
14:32:02 <mattmceuen> kskels: agree that specifying a different manifest document is a tool in our toolbox as well
14:32:04 <kskels> and do armada apply `full-site-airskiff`?
14:32:34 <openstackgerrit> Luna Das proposed airship/porthole master: Add Tracking User Identity in openstack utility container logs  https://review.opendev.org/674808
14:32:49 <mattmceuen> I think that solves for one challenge (one-shot replacement, at least for that doc)
14:32:55 <jamesgu> yes we are using different names, but the full-site and bootstrap from sloop are included nonetheless in the generated site and armada tries to valdiate them
14:33:05 <kskels> ah.. got it..
14:33:19 <kskels> usually though extra files wouldn't matter
14:33:24 <mattmceuen> kskels:  `full-site-airskiff` doesn't solve for cauterizing unused abstract documents though, right
14:33:24 <kskels> as long as they are not having errors
14:33:32 <jamesgu> so that could be an armada validation bug or design ;-)
14:33:54 <mattmceuen> It's intentional
14:34:10 <mattmceuen> As is one-shot replacement
14:34:24 <kskels> hm.. I didn't know one-shot replacement was intential
14:34:25 <openstackgerrit> Luna Das proposed airship/porthole master: Add Tracking User Identity in openstack utility container logs  https://review.opendev.org/674808
14:34:35 <kskels> replacement anyway is kind a "inheritance" or overlay
14:34:37 <mattmceuen> Although I could be convinced that value trade-off isn't worth it
14:34:50 <jamesgu> a simpler solution (since this will change in 2.0) is to remove the full-site and boostrap armada manifest in the sloop type and let airsloop and airskiff to define their own
14:35:18 <openstackgerrit> Merged airship/pegleg master: Add support domain-scoped token for CLI  https://review.opendev.org/674175
14:35:32 <kskels> to simply fix this we could just move the sloop/full-site to site/airsloop/
14:35:41 <kskels> and then each site will automatically require to define their own
14:35:59 <jamesgu> kskels: texactly, hat's the option b proposal
14:36:02 <mattmceuen> sounds like you guys are thinking along the same lines
14:36:03 <dwalt> That makes sense to me
14:36:32 <kskels> yeah - but then hope it's not the same for all other files in `sloop`..
14:36:35 <mattmceuen> Just to confirm:  validation won't barf if there are uncauterized abstract documents, as long as they are not pulled in from a manifest file?
14:36:39 <jamesgu> if mattmceuen likes it too we have a deal :-)
14:36:41 <kskels> which in that case would be better to do your own airskiff
14:37:05 <jamesgu> I tested it for airskiff, it seems to be happy, not tested airsloop yet
14:37:26 <mattmceuen> jamesgu:  if it work well, let's do it - if not, I would suggest skiff type as a plan B
14:37:37 <jamesgu> sounds good!
14:37:42 <kskels> sounds good!
14:37:47 <mattmceuen> kskels: do you know whether anyone is actively basing out-of-tree sites off of sloop type?
14:38:09 <mattmceuen> I know there were some ericsson folks who had used sloop, but I didn't know if they were pointing sites back at treasuremap or not
14:38:40 <kskels> good question.. though due to our tags `v1.3` and all - I think it would be acceptable even if they do..
14:38:46 <mattmceuen> agree
14:38:48 <mattmceuen> ok
14:39:21 <mattmceuen> I think we have a plan - any other discussion before moving on?
14:39:30 <jamesgu> no, thanks all
14:39:30 <mattmceuen> #topic How to build kubernetes-entrypoint
14:39:40 <mattmceuen> ok - this is my plea for help
14:39:56 <mattmceuen> as discussed last week I think, k8s-entrypoint project has migrated to airship: https://opendev.org/airship/kubernetes-entrypoint
14:40:00 <mattmceuen> still getting it set up
14:40:20 <mattmceuen> but one thing that confuses me -- the stackanetes project builds a container and pushes it to quay with every merge
14:40:29 <mattmceuen> but for the life of me I can't find either a dockerfile or a CI job
14:40:33 <howell> do we have contact info for anyone from the stackanetes team?
14:40:37 <howell> I assume we don
14:40:47 <howell> don't want to move the image
14:41:01 <mattmceuen> alanmeadows and portdirect been chatting with those guys and could ask I'm sure
14:41:17 <mattmceuen> looks like we don't have seaneagan here  - he might know
14:41:38 <howell> I'll contact him
14:42:12 <mattmceuen> I think we do want to start hosting the image in the normal airship registry namespace; it's currently getting pushed to a stackanetes namespaced location
14:42:14 <howell> but beyond that, I don't see anything in that repo that could create the image nor push it to quay.io
14:42:28 <alanmeadows> ^ yes
14:42:42 <portdirect> its build in quay.ios build system
14:42:46 <portdirect> built rather
14:42:53 <portdirect> we should just create our own
14:42:54 <alanmeadows> with regard to us wanting to push the image into an airship quay namespace
14:42:56 <howell> if we're pushing it to a new location, what's to stop us from just writing our own?
14:43:00 <mattmceuen> ok
14:43:03 <howell> ah, portdirect beat me to it
14:43:20 <portdirect> I'll also get some basic ci pushed up today
14:43:31 <mattmceuen> awesome - ty portdirect
14:43:48 <portdirect> np - though i stress the word 'basic'  :D
14:43:50 <evrardjp> portdirect: have a look at zuul's buildset registry if you can
14:43:55 <evrardjp> haha
14:43:56 <evrardjp> I see
14:43:57 <evrardjp> :)
14:44:30 <mattmceuen> alright, let's keep moving, few items left:
14:44:33 <mattmceuen> #topic Base image vulnerabilities
14:44:48 <mattmceuen> alexanderhughes go for it
14:45:04 <openstackgerrit> PRATEEK REDDY DODDA proposed airship/porthole master: Chart/Dockerfile for Openstack Utility Container Added Support for rbac  https://review.opendev.org/674670
14:45:39 <alexanderhughes> a while back we had a discussion about reducing image vulnerabilities in pegleg and spyglass by migrating to ubuntu:xenial instead of python:3.6 - this improved, but across airship we're still sitting around 15 medium vulnerabilities per image some with as many as 200 total vulnerabilites (lows, etc. included)
14:45:58 <alexanderhughes> since most of these vulnerabilities are from the base image, does it make sense for us to build our own minimal base image to use for each project?
14:46:20 <alexanderhughes> or do we want to just wait on updates to the official ubuntu images?
14:46:48 <mattmceuen> my 2c is the latter.  Operators/vendors are likely using their own base images anyway
14:47:03 <evrardjp> I would wait for updates, because it's building tech debt which we might be less good to track of
14:47:11 <mattmceuen> So probably makes sense to rely on canonical to do their own work on that
14:47:13 <mattmceuen> ++
14:47:40 <evrardjp> but is that a big deal though?
14:47:58 <evrardjp> sorry to ask that question, but I expected that everyone would build their own images with their own infra
14:48:20 <evrardjp> I didn't expect to say "the official airship images published on opendev are secure"
14:48:26 <evrardjp> liability and stuff :)
14:48:56 <alexanderhughes> we already support overriding the dokcerfiles with the FROM argument so if people want things more secure than we offer they can accomplish that.  I've just been involved in a lot of vulnerability talks lately and want to make sure we're making a reasonable effort at securing what we offer
14:48:57 <evrardjp> while we should do the best, people should be aware of things :)
14:49:05 <roman_g> +2 to evrardjp
14:49:06 <openstackgerrit> Merged airship/pegleg master: Fix: Allow Pegleg to generate unencrypted bundle  https://review.opendev.org/673904
14:49:21 <portdirect> evrardjp: +2 to 'but I expected that everyone would build their own images with their own infra'
14:49:25 <evrardjp> alexanderhughes: I think we all agree, it's just about making the message crystal clear :)
14:49:30 <portdirect> but at the same time, we want to make that easy
14:49:36 <evrardjp> portdirect: agreed :)
14:50:18 <mattmceuen> cool - I think we're aligned.  good with that plan alexanderhughes?
14:50:22 <alexanderhughes> yes
14:51:12 <mattmceuen> alright, moving on:
14:51:17 <mattmceuen> #topic Question re. single rabbitmq cluster PS
14:51:25 <mattmceuen> all yours evrardjp
14:51:25 <jamesgu> that was me... this is just an initial inquiry re. the "recent" change to a single rabbitmq cluster. we are evaluating what it means for scaling. Do we still have the flexibility / choice in place to allow seperate rabbiqmq cluster when the cloud scales up?
14:51:28 <mattmceuen> oop
14:51:29 <mattmceuen> s
14:51:35 <mattmceuen> purples all look the same in etherpad :)
14:51:45 <jamesgu> yep :-)
14:52:01 <mattmceuen> jamesgu:  yes, absolutely still have that flexibility
14:52:51 <evrardjp> mattmceuen: I was following that up too, so that's fine :)
14:53:06 <mattmceuen> the choice to go down to one cluster was driven by rabbitmq clustering issues.  every time the cluster starts up, you're rolling the dice on getting an issue in the clustering
14:53:17 <mattmceuen> the more clusters, the more opportunities for clustering issues
14:53:32 <mattmceuen> my understanding is that this is resolved in an upcoming version of rabbitmq
14:53:46 <evrardjp> that doesn't sound like an answer I will accept easily :)
14:54:00 <mattmceuen> portdirect can supply all kinds of hideous details
14:54:22 <jamesgu> what would it take for a smaller openstck cloud on a single cluster to scale up and have multiple rabbit clusters? It is no longer simple replicas # adjustment anymore, right?
14:54:34 <evrardjp> mattmceuen: I would say.. "assuming deploy of rabbitmq is fine", what would you do?
14:54:59 <evrardjp> valid question of jamesgu on how to scale
14:55:27 <evrardjp> (the question I asked was, ofc, for large clusters)
14:55:41 <evrardjp> small clusters are just fine with minimum things
14:55:48 <mattmceuen> jamesgu:  we can definitely still follow the same setup as before with multiple rabbit clusters
14:56:06 <evrardjp> mattmceuen: so the option is not removed, merely the default changes?
14:56:11 <mattmceuen> correct
14:56:17 <evrardjp> that's fine for me then :)
14:56:23 <pramchan62> +1
14:56:23 <evrardjp> docs have been provided?
14:56:26 <mattmceuen> the "reference archiecture" was changed, for now at least
14:56:45 <evrardjp> (I know I am annoying)
14:56:46 <mattmceuen> depends how much you enjoy reading yaml, evrardjp
14:56:53 <jamesgu> but no gate or treasuremap will use the multi cluster approach more... concern is over the time it will become less (unofficial) supported
14:56:56 <evrardjp> mattmceuen: that's not docs
14:57:02 <evrardjp> json is for machine
14:57:02 <mattmceuen> docs-as-code
14:57:11 * mattmceuen note: I am being annoying on purpose
14:57:23 <evrardjp> mattmceuen: weirdly loves that :)
14:57:24 <mattmceuen> yes, this is a very documentable thing
14:57:35 <evrardjp> I mean I weirdly like that*
14:57:48 <mattmceuen> as well as - getting documented when we can our more dependable clustering
14:57:51 <evrardjp> mattmceuen: +1 on that then!
14:58:01 <mattmceuen> #action mattmceuen to document our rabbitmq disposition
14:58:26 <mattmceuen> just a couple mins left --
14:58:28 <mattmceuen> #topic First TC meeting scheduled for 08-Aug-2019 at 9am CST
14:58:32 <mattmceuen> last topic!
14:58:34 <evrardjp> (it's important to clarify why we did this, what's the plan, and what can ppl do if they don't like the current state)
14:58:38 <mattmceuen> ++
14:58:44 <alexanderhughes> just an announcement really, connection details are here https://wiki.openstack.org/wiki/Airship/Airship-TC
14:58:55 <jamesgu> ++
14:59:09 <mattmceuen> that's great - thanks alexanderhughes
14:59:16 <alexanderhughes> Ryan wants to reserve last few minutes for community questions, call will be recorded and we'll share it and minutes as soon as we're able
14:59:21 <pramchan62> Is it open to all are only TC members meet?
14:59:37 <alexanderhughes> open to all for last few minutes, anyone can listen to the whole duration
14:59:44 <pramchan62> OK
14:59:46 <mattmceuen> awesome
15:00:04 <mattmceuen> great meeting - thanks everyone, & have a great week
15:00:10 <kskels> hey quick one
15:00:10 <alexanderhughes> reviews pls
15:00:11 <alexanderhughes> ^
15:00:14 <kskels> this one https://review.opendev.org/#/c/659369/
15:00:15 <mattmceuen> ah shoot
15:00:20 <kskels> broke the integration gates yesterday night
15:00:38 <kskels> if folks can take a look.. and maybe notify on these rather impacting changes..
15:00:51 <mattmceuen> #topic requests for review
15:00:54 <mattmceuen> https://review.opendev.org/#/c/671337/ - Pegleg certificate generation enhancements/fixes
15:00:54 <mattmceuen> https://review.opendev.org/#/c/673899/ - Pegleg dependency updates
15:00:54 <mattmceuen> https://review.opendev.org/#/c/673904/ - Pegleg bugfix to allow unencrypted Genesis bundle (as supported by Promenade)
15:00:54 <mattmceuen> https://review.opendev.org/#/c/671575/ - Shipyard
15:01:11 <mattmceuen> Thanks for the reminder Kaspars :)
15:01:32 <mattmceuen> eyeballs on these guys please^  plus kskels' https://review.opendev.org/#/c/659369/
15:01:42 <mattmceuen> thanks all
15:01:44 <mattmceuen> #endmeeting