Puiterwijk (talk | contribs) No edit summary |
Puiterwijk (talk | contribs) (OSBS in future) |
||
| Line 27: | Line 27: | ||
* The previous point is made particularly worse if the application is not packaged into Fedora/EPEL, as we would have to track it down. | * The previous point is made particularly worse if the application is not packaged into Fedora/EPEL, as we would have to track it down. | ||
These reasons together are why we are saying "no" to running any containers in the Fedora Infrastructure at this moment. | These reasons together are part of why we are saying "no" to running any containers in the Fedora Infrastructure at this moment. | ||
As | As we have said to pretty much everyone that has asked about this: as soon as we have a way to create the containers inside the Fedora Infrastructure, | ||
we can start looking into adopting it, but until that point is here we can't even consider it. | we can start looking into adopting it, but until that point is here we can't even consider it. | ||
| Line 38: | Line 38: | ||
== Future == | == Future == | ||
Once OSBS is enhanced to feature an audit chain for things added to the build pipeline via either download inside the buildroot or via distgit addition then we will be able to take advantage of it. | |||
Do note that as soon as the build system is fixed, we can start looking into it. | Do note that as soon as the build system is fixed, we can start looking into it. | ||
It is the very first requirement that's needed before we can even begin looking at it, but it is by no means the only requirement. | It is the very first requirement that's needed before we can even begin looking at it, but it is by no means the only requirement. | ||
Latest revision as of 15:35, 19 April 2016
Why is the Fedora Project Infrastructure not using containers in their infrastructure?
This page is currently in progress, and is by no means an exhaustive list at this moment
This page is currently only my (puiterwijk's) opinion, and is not yet endorsed by the rest of the Fedora Infrastructure team
We often get the question whether Fedora Infrastructure runs any container-based applications, or if we will.
We are getting this question asked so often, that we decided to write down what the reasons are we are at this time not using containers, and what would need
to be done to make this ever happen.
Nine out of ten times this question pops up, it's because the person asking us wants us to host a new application/service they really want to use. The very first question the Fedora Infrastructure team will ask is: "Is it packaged for RHEL/EPEL?", because that is one of our infrastructure requirements to hosting something. This requirement is what most often triggers the container question, because the people asking for us to host that service will say "How about I package it inside a container? Then I don't need to package it in RHEL/EPEL.".
From the outside, let me answer this question: NO. This does NOT suffice our requirement for packaging.
The problem here is the build system (not controlled/auditable, since this will be built on people's personal machines. Also, people are very likely to inject raw tarballs with the application in it into the build process.
The main problem with having people build their own containers is that, whether or not they package the stuff up or if they download the tarball in the build script, we have:
- No way to audit the builds: there is no way to know for sure how the container is built
- No way to rebuild the container in case an update is released
- The previous point is made particularly worse if the application is not packaged into Fedora/EPEL, as we would have to track it down.
These reasons together are part of why we are saying "no" to running any containers in the Fedora Infrastructure at this moment. As we have said to pretty much everyone that has asked about this: as soon as we have a way to create the containers inside the Fedora Infrastructure, we can start looking into adopting it, but until that point is here we can't even consider it.
What about the new OSBS system that's going to be launched soon?
This system still allows people to drop random tarballs into the build environment, or even download those from the internet. This means that at this moment, the OSBS build system as planned to go into production soon is NOT suitable, as it does not solve the previously mentioned issues.
Future
Once OSBS is enhanced to feature an audit chain for things added to the build pipeline via either download inside the buildroot or via distgit addition then we will be able to take advantage of it.
Do note that as soon as the build system is fixed, we can start looking into it. It is the very first requirement that's needed before we can even begin looking at it, but it is by no means the only requirement.