On Fri, Jun 26, 2020 at 07:51:25AM -0400, Stephen John Smoogen wrote:
On Thu, 25 Jun 2020 at 15:27, Pierre-Yves Chibon
> Good Morning Everyone,
> Just like every team we have technical debt in our work.
> I would like your help to try to define what it is for us.
> So far, I've come up with the following:
> - python3 support/migration
> - fedora-messaging
> - fedora-messaging schema
> - documentation
> - (unit-)tests
> - OpenID Connect
> What else would we want in there?
1. mailman3. currently running in a broken vm which was transported from PHX2.
2. OpenShift is currently running in openshift 3 and may need to move
to OS4 (I do not know eol for OS3)
June 2022... so we have time.
3. PDC is EOL software with a replacement needing to be dealt with
4. Our website setup and running is a multi hour ansible run mess
5. Our docs on website setup is a multi-hour mess
This should now be fixed.
6. We have NO working monitoring. It is going to take me a week to
it working and several months to replace it with something else
7. Any other vm's we shifted over from PHX2 to IAD2 versus rebuild
from scratch should be considered unmaintained debt
Good reminder. In addtion to mailman, notifs/FMN is in this boat.
8. Our staging needs to be designed from scratch and put in place
a rollout plan to replicate it in prod
9. OpenQA that Adam needs some specing out and work on it. It
currently requires running on a 10.0.0.0/16 network.. The problem is
that those IPs are also our running networks. This is causing leaks
which are causing problems with our switch and routers.
10. Our deployment infrastructure of kickstarts/pxe/tftp falls under
technical debt. It is based off of what we have been doing for 10+
years and it has broken a lot in this transition. When it works its
fine, and when it doesn't nothing works.
I'm not sure any more 'modern' thing here would be much better on the
hardware level. For vm's, yeah, there's some annoyances with
virt-installs which we should either track down and fix, or just go to
the 'use a cloud image and adjust it' mode.
I'll also add:
* datagrepper needs work. It's growing without bound and it's just a big
pile of messages. We could/should partition it at least and possibly
save it's data in a more clever way.