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