On Fri, Jun 17, 2022 at 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.
>
Fedora's images churning more often is a good thing, not a bad thing.
And frankly, I would not recommend RHEL UBI for a few reasons:
1. It's hard to get things fixed in a timely fashion
2. The content set is too reduced from RHEL
3. We already control the Fedora content, so we should use those
Dogfooding is important, as is self-sufficiency. Inability to do both
makes it much more difficult for others to reuse our stuff.
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
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
