+1 to this. What I would like to know is their away we can do approval/check if certain requirements are met before a build kicks off, that may help enforce requirements.
On Fri, Jun 17, 2022, 4:56 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote:
So, when moving openshift apps this week, I really came to the
conclusion we should look at writing up some guidelines for openshift
apps. Perhaps it could have 'MUST' items and 'SHOULD' items and
'SUGGESTION' items.
I know I am coming at this from the operations side of things, so please
do share other viewpoints, but let me mention a few issues I see:
It's very difficult to tell what an application is running on:
- We should probibly forbid 'X:latest' because what the application is
running depends on when it was last built/deployed. (unless: see
below)
- A number of apps use images elsewhere (quay.io, etc). We have very
little way to tell whats in those or how they are made or if anyone is
still making them.
We have a few apps that rebuild/deploy on git changes, which is fine,
but doesn't do anything to keep their container env up to date/secure.
We have a number of apps that tigger on imagestream changes, but as far
as I can tell thats only changes in their image ('bodhi-base') not the
base image that it was built from ('fedora:36'). I'd like to see us
track base images and build/deploy when one changes. If we do that then
:latest might be ok to use, since we know automation took care of
updating it for us.
There's a number of applications using ubi (rhel's base image), which I
think might be worth recommending, especially if we start build/deploy
on base image changes. Likely Fedora base images will change more
quickly.
Currently we have some apps that were setup and probibly have not
changes in years, happily running the same old container image since
there was no reason to redeploy them.
Similarly, python versions are all over the place... python3.6, 3.8,
3.9, etc. Of course different apps will target different versions
sometimes, but it might be nice to make sure we are using a supported
version by whatever container image the app is using. (ie, gets security
fixes).
Our naming conventions are a bit all over the place too. Some apps have
$appname-build for buildconfig, some just $appname, some seperate
configs for seperate containers ($app-web, $app-frontend). Same for
deploymentconfigs.
Anyhow, I'll stop there... but hopefully everyone would be ok with such
a doc and then changing things to match it?
kevin
_______________________________________________
infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
