| *** diablo_rojo is now known as Guest1373 | 04:33 | |
| *** ykarel_ is now known as ykarel | 06:07 | |
| *** ykarel is now known as ykarel|lunch | 09:13 | |
| *** ykarel|lunch is now known as ykarel | 10:05 | |
| *** tobberydberg_ is now known as tobberydberg | 11:51 | |
| *** pojadhav- is now known as pojadhav | 13:22 | |
| *** pojadhav- is now known as pojadhav | 13:54 | |
| gmann | tc-members: meeting time | 15:00 |
|---|---|---|
| gmann | #startmeeting tc | 15:00 |
| opendevmeet | Meeting started Thu Sep 30 15:00:10 2021 UTC and is due to finish in 60 minutes. The chair is gmann. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
| opendevmeet | The meeting name has been set to 'tc' | 15:00 |
| yoctozepto | o/ | 15:00 |
| jungleboyj | o/ | 15:00 |
| gmann | fungi: clarkb dpawlik ping | 15:00 |
| gmann | #topic Roll call | 15:00 |
| gmann | o/ | 15:00 |
| dpawlik | o/ | 15:00 |
| fungi | mnaser is still presenting on openinfra.live | 15:00 |
| belmoreira | o/ | 15:00 |
| *** diablo_rojooooooo is now known as diablo_rojo | 15:00 | |
| clarkb | hi | 15:01 |
| gmann | only four tc-members, let's wait for 1 more min. | 15:02 |
| mnaser | o/ kinda? | 15:02 |
| gmann | let's start | 15:03 |
| gmann | #topic Follow up on past action items | 15:03 |
| gmann | gmann to remove 'TC tags analysis' from agenda | 15:03 |
| gmann | done | 15:03 |
| gmann | #topic Gate health check (dansmith/yoctozepto) | 15:03 |
| gmann | dansmith: yoctozepto go ahead | 15:03 |
| yoctozepto | gates are unbelievably happy our I'm just oblivious to gate issues | 15:03 |
| yoctozepto | or* | 15:04 |
| yoctozepto | :-) | 15:04 |
| jungleboyj | :-) | 15:04 |
| gmann | after lot of fixes :) | 15:04 |
| yoctozepto | yeah, but it was much smaller than previous similar events | 15:04 |
| yoctozepto | at least how I remembered them | 15:04 |
| gmann | apache2 on devstack uwsgi setup is fixed which blocked gate for almost 1.5 days | 15:04 |
| gmann | we also faced two more issue: 1. nova ceph on stable and 2. nova grenade on master failure | 15:05 |
| fungi | mit's fedora 34 mirror we sync from in opendev was broken, we just moments ago completed a switch to a mirror at uh.edu | 15:05 |
| gmann | both are fixed now | 15:05 |
| gmann | +1 | 15:05 |
| clarkb | did the dstat replacement issue ever get addressed? | 15:05 |
| fungi | also we've got another zuul restart coming up today for some more stabilization fixes in advance of xena release week | 15:05 |
| yoctozepto | clarkb: no, unfortunately | 15:06 |
| gmann | release is planned for next week so let's keep eyes on gate. | 15:06 |
| yoctozepto | guess it's not bad enough | 15:06 |
| yoctozepto | I'll look at it at some time for sure | 15:06 |
| gmann | thanks | 15:07 |
| gmann | anything else on gate? | 15:07 |
| gmann | #topic Place to maintain the external hosted ELK, E-R, O-H services | 15:08 |
| gmann | As background and to refresh the memory: | 15:08 |
| gmann | As there is/was no maintainer to maintain ELK services in OpenDev and these services were proposed to shutdown, we raised the ELK service help in community as well as to Board of Directors. | 15:08 |
| gmann | Allison(BoD chair) putting a great effort on this and it seems, there are good possibility (still under discussion) of getting hosted ELK service from OpenSearch (an open source fork of Elasticsearch). | 15:09 |
| gmann | in addition to hosted ELK, dpawlik volunteer to maintain it. | 15:09 |
| gmann | this etherpad has more details #link https://etherpad.opendev.org/p/elk-service-maintenance-plan | 15:10 |
| dpawlik | exactly gmann | 15:10 |
| gmann | Now two open questions on us: | 15:10 |
| gmann | let's go one by one | 15:10 |
| gmann | 1. is OpenSearch can fulfill our requirement for ELK service usage? | 15:10 |
| clarkb | Note OpenSearch doesn't do the L in ELK. Only the E and K | 15:10 |
| gmann | ok | 15:10 |
| gmann | clarkb: fungi dpawlik you can give more details on us | 15:11 |
| yoctozepto | can we use fluentd instead of logstash then? | 15:11 |
| gmann | s/us/this | 15:11 |
| fungi | and there's a bunch more tech in that suite openstack is relying on, elasticsearch is merely the queryable storage backend | 15:11 |
| yoctozepto | gmann: perhaps on us as well, who knows | 15:11 |
| wendar | yoctozepto: yes, and also, OpenSearch is working on an alternative to logstash, it just isn't ready yet | 15:11 |
| gmann | wendar: hi | 15:12 |
| wendar | hi | 15:12 |
| fungi | yoctozepto: whoever's going to run it can presumably design it to use whatever ingestion software they want, just note that there's already a pile of logstash grok parsers | 15:12 |
| gmann | fungi: yes, basically "ELK, Elastic-Recheck, and OpenStack-Health services" | 15:12 |
| fungi | grok parser rules | 15:12 |
| yoctozepto | fungi: yeah, I was wondering how much investment was done already | 15:12 |
| yoctozepto | then a logstash clone would be better | 15:12 |
| wendar | and, there is also an existing plugin for logstash to write to OpenSearch, so that might be the simplest in terms of immediate migration | 15:12 |
| yoctozepto | or that ^ | 15:13 |
| gmann | yeah | 15:13 |
| gmann | any other challenge we see on OpenSearch option? | 15:14 |
| * mnaser actually here | 15:14 | |
| gmann | mnaser: hi | 15:15 |
| fungi | also opendev's sysadmins don't want to be responsible for custom notification bits for this, so we need to be able to drop the gearman event bits from our base job and instead the ingestion should work on polling available apis | 15:15 |
| mnaser | ingestion rules are a thing, fluentd stuff is a thing, there's a few other ways that we can get data into opensearch which is going to have to probably be dealt with by whoever decides to pick this up tbh | 15:15 |
| yoctozepto | mhm | 15:16 |
| dpawlik | gmann: on disabling security plugin, we can have elasticsearch like it is running right now on opendev, but the proxy rules what operations like PUT/POST/DELETE needs to be filtered | 15:16 |
| mnaser | i figure whoever will be pushing for this will probably get to be the authoritive answer at the end of the day | 15:16 |
| dpawlik | by disabling* | 15:16 |
| diablo_rojo | Sorry am late, was hosting an Open Infra Live episode | 15:16 |
| gmann | mnaser: yeah we will be discussing that as next item which is important | 15:16 |
| fungi | dpawlik: however, according to the opensearch folks at amazon we talked to, kibana isn't going to work correctly through a read-only proxy. they suggested switching to a shared read-only account for queries | 15:17 |
| ricolin | sorry I'm late | 15:17 |
| dpawlik | fungi: on rdo we share the read only user account | 15:18 |
| gmann | shared read-only should work though | 15:18 |
| clarkb | right one of the biggest things that kept us from upgraded prior to losing help was new ES needs new Kibana and new Kiabana can't operate anonymously | 15:18 |
| fungi | something like what we do for the openstack-health subuinit database | 15:18 |
| clarkb | opensearch addresses this by open sourcing AAA tooling | 15:18 |
| fungi | s/subuinit/subunit/ | 15:18 |
| fungi | (though we actually have a query proxy in front of the mysql api for that database too, now that oi think about it, i should add that to the list in the pad) | 15:19 |
| dpawlik | clarkb: that's why we do a trick to inject header with user credentials to automatically login into the kibana | 15:20 |
| dpawlik | clarkb: by saying "operate" you mean just to make a query and check visualizations, right? | 15:21 |
| fungi | right, they alluded to that on the opensearch call... basically embed http basic auth creds | 15:21 |
| clarkb | dpawlik: no, it needed write access to the database which we've removed with the proxy | 15:21 |
| clarkb | anyway it sounds like their authentication and authorization tooling allows sufficient fine tuning to make kibana work | 15:22 |
| fungi | from what they were saying, new kibana sort of "drops privileges" when a user authenticates to it, but needs essentially administrative access through the api for other functions | 15:22 |
| dpawlik | fungi: right, there are some indexes that the user should be able to have write access to it | 15:23 |
| clarkb | I don't think kibana will be an issue. And if it is it sounds like there may be sufficient interest on the opensearch side for potentailly improving things | 15:24 |
| gmann | true | 15:24 |
| dpawlik | clarkb: +1 | 15:24 |
| clarkb | The bigger issue is figuring out updating ingestion so that it works against a modern system. Then operating and maintaining that system | 15:24 |
| clarkb | Since OpenSearch as a service leaves that to the user | 15:24 |
| gmann | wendar: clarkb how is their contract going to be, yearly? | 15:24 |
| wendar | Tom described it as "perpetual", and also said to chat with him if the current amount/year isn't enough (it probably will be) | 15:25 |
| gmann | clarkb: yeah. let's figure out where to place those which we will discuss next. | 15:25 |
| gmann | wendar: ok | 15:26 |
| gmann | I think we seems ok on opensearch on our requirements and later we can see what all we can truncate the things | 15:27 |
| gmann | now next question is on operating it | 15:27 |
| gmann | 2. Where to maintain the hosted ELK? OpenStack? or OpenDev? | 15:27 |
| gmann | Due to less/no long term maintainers for ELK and more focus on key services, the OpenDev team decided to cease maintenance for the ELK, Elastic-Recheck, and OpenStack-Health services. | 15:28 |
| TheJulia | I think there is a third option, spin up a new namespace on opendev because its use can be more generally applicable. | 15:28 |
| gmann | I added few option in L16 https://etherpad.opendev.org/p/elk-service-maintenance-plan | 15:28 |
| fungi | i think we're well past the time for opendev to continue being responsible for these services. we tried, we asked for help, we finally decided it was too far gone and have planned to shut it down | 15:28 |
| gmann | fungi: agree | 15:29 |
| TheJulia | so the determination then becomes, where does it need to live and the tooling operate, and much of that would be implementation detail based on re-engineering right? | 15:29 |
| fungi | yes, i believe so | 15:30 |
| fungi | at the moment, if something happens and the servers it's running on suffer a catastrophic failure, we have no way to rebuild what's there | 15:30 |
| gmann | current options: | 15:30 |
| gmann | Option1: Add it under TACT SIG | 15:30 |
| gmann | Option2: Add it in OpenStack QA. | 15:30 |
| TheJulia | so in essence, we're kind of spinning an entirely new project then | 15:30 |
| gmann | Option3: Start a new project or SIG. | 15:30 |
| gmann | or Option4: (for completeness) Stop relying on these services. but we want these so let's keep it for later | 15:31 |
| yoctozepto | Option2 is not feasible, we are already too small | 15:31 |
| clarkb | re this tooling being generally applicable, I think it totally is and tehre is a lot of neat stuff that can be done in the psace. But we've not seen interst from outside of openstack really | 15:31 |
| gmann | yoctozepto: yeah, same opinion from me too and listed in etherpad too | 15:31 |
| yoctozepto | ok | 15:31 |
| TheJulia | clarkb: could that also be the connoation that comes with the openstack name? | 15:31 |
| TheJulia | connatation | 15:32 |
| clarkb | TheJulia: maybe? What I've heard from the zuul devs is that it just isn't necessary for their workflows because Zuul's logging is much easier to sfit through | 15:32 |
| yoctozepto | gmann: but I can't see this in the etherpad, you sure you wrote it down? | 15:32 |
| gmann | yoctozepto: ah, missed. | 15:32 |
| clarkb | I think a certain scale is necessary before you cross the threshold where developer time is better spent learning lucene instead of grep | 15:33 |
| * yoctozepto glad it's not him being blind | 15:33 | |
| gmann | done | 15:33 |
| yoctozepto | thanks | 15:33 |
| fungi | the reason it's been useful for openstack is a matter of scale, there are numerous failures which occur a fraction of a percent of the time, but you need to run tens or hundreds of thousands of times to get a large enough sample size to isolate and classify them | 15:33 |
| gmann | yeah, scale is all key thing here | 15:33 |
| clarkb | Zuul being a much smaller project also has a stronger sense of ownership for issues that pop up. If my tests fail due to some random reason I go and debug it and hopefully fix it and many of the zuul devs do that here | 15:34 |
| fungi | the other projects in opendev just don't have the change volume openstack does, and don't run similar integration tests nearly as many times, so they lack sample size to make good use of this sort of solution | 15:34 |
| clarkb | With many more devs in openstack not everyone can be expected to do that and rechecks happen which allow a larger percentage of these things through long term | 15:34 |
| yoctozepto | ++ on all the thoughts | 15:34 |
| gmann | ditto, +1. and with the integration scale openstack has it is natural. | 15:35 |
| gmann | ok so we left with two option now | 15:35 |
| gmann | TACT SIG or new project/SIG under openstack | 15:35 |
| TheJulia | does it *have* to be under openstack? | 15:36 |
| gmann | for TACT SIG fungi its again you need to give opinion. | 15:36 |
| gmann | TheJulia: it is better if openstack is only user of it and no one else want it | 15:36 |
| fungi | TheJulia: it doesn't have to be an openstack project or sig, no | 15:36 |
| gmann | fungi: then new open infra project ? | 15:36 |
| wendar | TheJulia: It doesn't have to be under openstack, but openstack is currently the only user, so it makes some sense, at least as a starting point. | 15:36 |
| yoctozepto | it would look better under opendev to gather more folks around the solution | 15:37 |
| fungi | the software could still be generally applicable even if the instance of the service being run isn't used beyond openstack projects | 15:37 |
| TheJulia | gmann: it will never be able to gain external usage or adoption outside of openstack if we brand it openstack upfront | 15:37 |
| yoctozepto | even if only for naming sake | 15:37 |
| yoctozepto | TheJulia ++ | 15:37 |
| clarkb | TheJulia: wow that is an extremely pessimistic take | 15:37 |
| gmann | opendev seems not option so I think openstack is default then | 15:37 |
| jungleboyj | TheJulia: ++ | 15:37 |
| gmann | or what other option we have? | 15:37 |
| jungleboyj | clarkb: It is pessimistic but probably realistic. | 15:38 |
| wendar | We can always move it out of openstack later, if/when we start to generalize the code. | 15:38 |
| clarkb | sure but OpenDev the non openstack location for doing this work has said "hey lets try and figure this out" for a few years now | 15:38 |
| gmann | wendar: exactly. | 15:38 |
| clarkb | and literally we have had negative interest (the team has shrunk over that time) | 15:38 |
| fungi | the tact sig doesn't really have any "resources", it's effectively an umbrella to cover things people happen to be working on which didn't fit as opendev services but also didn't really make sense as an openstack project team | 15:38 |
| clarkb | I don't think calling it something other than openstack helps either is kinda my point there | 15:38 |
| TheJulia | clarkb: the name comes with a lot, good and bad unfortunately | 15:38 |
| gmann | fungi: we have maintainer now its just we need a place it acn better fit for now | 15:38 |
| wendar | The OpenSearch team even said they'd be willing to consider taking it on as a project, if it becomes generally useful. | 15:39 |
| TheJulia | wendar: that sounds like a great possibility | 15:39 |
| gmann | fungi: and if we again face no maintainer issue then it goes away | 15:39 |
| wendar | (But, there's quite a bit of work to do, before that would make sense anyway.) | 15:39 |
| fungi | we've been winding down all the services the opendev sysadmins were running outside of opendev itself, in order to be able to keep our core services in good shape. the only one which we don't currently have plans to discontinue (but would like to) is wiki.openstack.org | 15:39 |
| clarkb | at least putting it in openstack whee people seem to care would give it potential to survive | 15:39 |
| gmann | clarkb: indeed | 15:39 |
| gmann | and if more project care and we have more maintainer then we can things of opendev or at external place again | 15:40 |
| gmann | so let's go with the current situation 'only openstack need/care about it' | 15:40 |
| gmann | and openstack would not object if it goes at some central place for others to use | 15:41 |
| fungi | we have said in the past that we'd manage server resources at a low level for any project-specific efforts which needed them, but we stopped considering that viable some years back when it became apparent that people would build things which weren't long-term manageable, users would start to rely on them, then the services would be abandoned and the sysadmin group would be pressured to | 15:42 |
| fungi | keep them running (ask.openstack.org as a prime example) | 15:42 |
| gmann | so we have (will have) hosted service and maintainer to maintain it so place hardly matter for now and starting in openstack make sense to me and later we can again re-think on place based on interest of other projects. | 15:43 |
| yoctozepto | ok, so a SIG? | 15:43 |
| gmann | new SIG or TACT? | 15:44 |
| yoctozepto | Debuggability SIG | 15:44 |
| fungi | wiki.openstack.org is perhaps an even better example. we had volunteers from wikimedia foundation running it, they left, it wasn't really set up compatible with how we did our configuration management, so now it's in a really precarious state where basically nobody knows how to tend to it, its very outdated (probably rife with security holes) and we'd be hard pressed to rebuild it if | 15:44 |
| fungi | something happened to the server it's on | 15:44 |
| yoctozepto | fungi: good to know | 15:44 |
| TheJulia | fungi: sounds like everyone just needs to begin moving off of it (projects wise) | 15:44 |
| fungi | TheJulia: well, it's an example of what i don't want whatever this replacement is to become | 15:45 |
| spotz__ | Hey all | 15:45 |
| * TheJulia adds to ironic's PTG topic list | 15:45 | |
| TheJulia | fungi: ++ | 15:45 |
| gmann | I am fine on new SIG if fungi think it is ok and leave TACT SIG as it is as per its current scope ? | 15:46 |
| gmann | but for me TACT SIG seems more close and even fungi there helping on migration or any other question, sharing same IRC channel or so | 15:46 |
| fungi | each time we've proposed discontinuing the wiki server over the years, there's been uproar but no new volunteers to fix the problem. and the elastic-recheck/openstack-health discontinuation is at risk of going down the same path (though hopefully not, as we've learned those lessons i think?) | 15:46 |
| fungi | i'm fine with the coordination happening through the tact sig, as a peg to hang the sign on, but just be aware that doesn't come with any guaranteed resources | 15:47 |
| gmann | openstack-health we can again re-think if needed or not. QA is not using it so much as it used to be | 15:47 |
| TheJulia | fungi: yeah, we need to adapt and change processes, and it sounds like getting rid of the gearman bits would help, I hope at least. | 15:47 |
| clarkb | gmann: in fact I think the health services has been dead for a few months now and no one noticed :) | 15:48 |
| gmann | fungi: true, and same thing if there is maintainer issue then yes we re-think on it. Will not put everything on you. | 15:48 |
| gmann | clarkb: :) | 15:48 |
| gmann | let me bring it again in QA meeting on 'who need it' ? i raised it few month back but we did not decided | 15:49 |
| fungi | to be fair, hald of elastic-recheck has been broken for months/years so i don't think all of its functionality is being relied on, and sometimes the backend is down for a week with nobody noticing | 15:49 |
| fungi | s/hald/half/ | 15:49 |
| clarkb | fungi: yup it tends to get more use during periods of time like now with release candidates and stabilization and people caring about the gate | 15:50 |
| gmann | yeah | 15:50 |
| clarkb | then no one cares during the 3 months of merge everything as quickly as possible | 15:50 |
| gmann | ok so are out of time for other agenda | 15:50 |
| yoctozepto | (btw, I think TC should now concern itself with wiki going down to help TACT SIG too) | 15:50 |
| gmann | so as summary 1. OpenSearch is good option 2. TACT SIG is new place for hosted ELK maintenance | 15:51 |
| yoctozepto | (as I doubt it's common knowledge) | 15:51 |
| gmann | any more things to discuss on this, though I will keep it in agenda for next meeting too | 15:51 |
| clarkb | note it isn't just the wiki and the ELK stack. It is all the services right? This is why I continue to try and remind people that helping OpenDev ensures this doesn't happen to a growing list of services. But I think many have sort of accepted that ship has sailed at this point? | 15:52 |
| gmann | thanks for joining and great discussion on this clarkb fungi dpawlik wendar fungi | 15:52 |
| gmann | moving next | 15:52 |
| clarkb | Now I don't think OpenStack should be the only project to help either. Zuul does a bunch of help but primarily on the CI side. Airship and Starlginx could probably be involved more | 15:52 |
| gmann | #topic Project Health checks framework | 15:52 |
| gmann | clarkb: indeed. | 15:52 |
| gmann | ricolin: I think as we discussed in previous meeting, we are going to work on documentation in parallel to current tool right? | 15:53 |
| gmann | #link https://etherpad.opendev.org/p/health_check | 15:53 |
| ricolin | Indeed we have that action | 15:54 |
| gmann | ricolin: ok, any more updates or so you would like to share today? | 15:54 |
| ricolin | not yet starts it | 15:54 |
| gmann | ok, no issue. if we can have somthing by PTG then it is good to discuss there | 15:54 |
| ricolin | NP | 15:54 |
| gmann | moving next | 15:54 |
| gmann | #toppic OpenStack newsletter | 15:55 |
| gmann | we have two items there for newsletter, please add more if you think to highlight #link https://etherpad.opendev.org/p/newsletter-openstack-news | 15:55 |
| gmann | may be by tomorrow as deadline? diablo_rojo ? | 15:55 |
| clarkb | You should probably have something about the new release? | 15:56 |
| clarkb | Or maybe that is implied | 15:56 |
| gmann | clarkb: yeah not sure when it is going to publish before or after release ? | 15:56 |
| gmann | we usually add it explicitly if i remember correctly | 15:57 |
| diablo_rojo | gmann, actually its tuesday | 15:57 |
| diablo_rojo | for me to write the content | 15:57 |
| diablo_rojo | so preferably Monday | 15:57 |
| diablo_rojo | lol | 15:57 |
| gmann | diablo_rojo: ok then we can add it if it is released after Xena then add | 15:58 |
| gmann | #topic Open Reviews | 15:58 |
| gmann | #link https://review.opendev.org/q/projects:openstack/governance+is:open | 15:58 |
| gmann | this one to review and provide early feedback if you have any #link https://review.opendev.org/c/openstack/governance/+/810721 | 15:58 |
| diablo_rojo | I expect there is going to be a focus on Xena in the next one if not this one. We can mention it but I don't think I will be needing to spend a lot of time on that particular topic. | 15:59 |
| gmann | diablo_rojo: +1 | 15:59 |
| gmann | one last thing, next meeting is going to be Video call. | 16:00 |
| gmann | that's all from me today. | 16:00 |
| gmann | thanks all for joining | 16:00 |
| gmann | #endmeeting | 16:00 |
| opendevmeet | Meeting ended Thu Sep 30 16:00:25 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:00 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2021/tc.2021-09-30-15.00.html | 16:00 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2021/tc.2021-09-30-15.00.txt | 16:00 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2021/tc.2021-09-30-15.00.log.html | 16:00 |
| jungleboyj | Thanks! | 16:00 |
| dansmith | gmann: sorry again | 16:01 |
| dansmith | gmann: we were having a tree taken down.. appointment was at noon and they show up at 8am. imagine our surprise :/ | 16:01 |
| dansmith | actually before 8am.. chainsaws were running by 8. | 16:01 |
| gmann | dansmith: np!, I will try to summarize it over email in case. otherwise ELK topic we will continue in next week call too | 16:02 |
| diablo_rojo | Thanks gmann! | 16:02 |
| dansmith | gmann: okay I think the openinfra live thing overlaps with the tc meeting next week, so I might also be unable to attend that one, depending on how long it goes | 16:02 |
| gmann | dansmith: yeah it is exactly after the openinfra let's see. I am going to ask hosting help to yoctozepto | 16:03 |
| dansmith | ack | 16:03 |
| gmann | diablo_rojo: added a note there in etherpad. | 16:05 |
| diablo_rojo | gmann, thank you! | 16:05 |
| yoctozepto | gmann: thanks, and ok - I will only be watching it, not participating, can host the meeting | 16:07 |
| gmann | mnaser: fungi please review this project-config for new charm https://review.opendev.org/c/openstack/project-config/+/809012 | 16:07 |
| gmann | needed by governance patch | 16:07 |
| gmann | yoctozepto: thakns, I will add he details of call and agenda and let you to take care next. I will join but again depends on what time we finish the openinfra sessions | 16:08 |
| gmann | thanks | 16:08 |
| gmann | *the details | 16:08 |
| yoctozepto | sure thing | 16:09 |
| fungi | dansmith: gmann: technically the tc meeting starts the same time openinfra.live ends, but the show has a tendency to "run long" sometimes and can end up overlapping | 16:09 |
| dansmith | fungi: typ | 16:10 |
| dansmith | er, yup | 16:10 |
| gmann | yeah | 16:10 |
| dpawlik | thanks gmann! | 16:25 |
| gmann | dpawlik: your welcome, and thanks again to you for helping us on this. | 16:31 |
| gmann | ricolin: I added 'documentation part as ' TODO in project health check etherpad in case we do not forget #link https://etherpad.opendev.org/p/health_check | 16:32 |
| *** diablo_rojo is now known as Guest1421 | 17:02 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!