On Tue, May 24, 2022 at 06:24:10PM +0200, Aurelien Bompard wrote: > > Something like: > >> > >> Applications in Fedora Infrastructure may be deployed via non rpm > >> methods (as long as they obey licensing guidelines ( > >> https://fedoraproject.org/wiki/Infrastructure_Licensing )). For those > >> applications, creating and maintaining an rpm is optional. > >> > >> > > How about: > > > > Applications in Fedora Infrastructure need to be deployed in an auditable > > and repeatable way. These methods need to allow someone to determine which > > software was installed, when it was installed, and what it was meant to be > > done (example: rpms or podman build scripts for containers). The goal is to > > be kind to our future selves at 2 am who need to figure out why a critical > > application is broken and how to rebuild and redeploy as needed. Indeed! Although 'repeatable' has always been a bit mushy... > Yeah that seems sensible (although I'm not sure of the wording of "what it > was meant to be done", but I think I get it). Yeah, could be re-worded a bit/made more verbose. Perhaps: All deployments of software in Fedora Infrastructure MUST: * Be under an acceptable license ( https://fedoraproject.org/wiki/Infrastructure_Licensing ) * Be auditable (what versions of what things are in the deployment, for example: a koji task for a rpm build or a openshift build log for a pod) * Be Downgradable (allow rollback to a previous working version, for example with a rpm downgrade or a openshift pod rollout of old version) > This would satisfy apps built with s2i as long as they are pinning their > dependencies with something like poetry or pipenv. We are currently > standardizing on poetry but any would do as long as deps are pinned). As a package maintainer... I LOATHE pinning. ;( but I understand why in this case it makes things nicer... I don't know that we really need to pin everything as long as we have logs of what was used. Then if an upgrade causes breakage, we could just go back to a previous build, or _then_ pin something at a specific version to avoid a bug. > > For s2i based apps, I see two ways of ensuring repeatability, one being > stricter but more transparent than the other: > 1. have the buildconfig track a production branch upstream, and rely on the > build log to know which exact commit was built > 2. have the buildconfig specify the commit hash, and change the buildconfig > each time we want to deploy a new prod version > > Option 2 is more transparent because the commit to build is a var in > ansible, but it means updating ansible each time we want to make a prod > deployment. > The workflow for option 1 is simpler because it's just a start-build, but > we'll need the logs to know which commit in the prod branch was actually > built, and it may be cumbersome to dig up during if something goes wrong. > > Any preference? As a dev I would be happy with both, they are still > infinitely easier than building RPMs. Option 1 being easier for devs, my > lazy self leans towards it, but Option 2 is fine as well. > Another option that I did not think of? I'm fine with either. It might be we should decide this on a app by app basis? ie, some not very important app, or some new app thats building all the time could use method 1, and something thats really important and established could use method 2. Method2 is much nicer for freezes, if we decide anything openshift wise freezes. ;) On Tue, May 24, 2022 at 01:15:20PM -0400, Ben Cotton wrote: > On Mon, May 23, 2022 at 6:17 PM Stephen Smoogen <ssmoogen@xxxxxxxxxx> wrote: > > > > Applications in Fedora Infrastructure need to be deployed in an auditable and repeatable way. These methods need to allow someone to determine which software was installed, when it was installed, and what it was meant to be done (example: rpms or podman build scripts for containers). The goal is to be kind to our future selves at 2 am who need to figure out why a critical application is broken and how to rebuild and redeploy as needed. > > I like this approach. I don't think there's real value in requiring > that everything be packaged as an RPM, but we do want to make sure we > can re-deploy correctly. > > What are the implications for pinning requirements here? Should we > require that each application require specific versions of > dependencies? I don't love that idea, but I love even less the idea of > a stealthy change to a package turning our infrastructure into a > cryptocurrency rig. Well, I don't think thats too likely... more likely would be a new build would cause some breakage due to a dep upgrading. As long as we record what deps were used, it should be easy to then pin things or roll back to a previous version until it's fixed. In fact, pinning could result in more chance of security issues... if you pin everything and avoid security updates. I'd prefer pinning just the bare amount we need to... kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
