Container Layered Image Builds[0] (CLIBs) are going to be the first deliverable provided by the Fedora Project as an official delivery/release build artifact other than RPM. The first container implementation we're targeting is Docker. With RPMs, there are many guildelines in place on how to create them[1][2] for official inclusion for Fedora. We should really look into doing something similar for CLIBs. Below are a couple of links to draft docs to address some of these. I would like peer review on these docs as well as brainstorming on areas that might also need attention around this.
https://fedoraproject.org/wiki/PackagingDrafts/Containers https://fedoraproject.org/wiki/PackagingDrafts/Package_Review_Process_with_Containers
I look forward to feedback and continued discussion.
-AdamM
[0] - https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service [1] - https://fedoraproject.org/wiki/Package_Review_Process [2] - https://fedoraproject.org/wiki/Packaging:Guidelines
I guess we have to add more details about what all is allowed to be in the containers. Like can we get arbitrary things from Internet into those containers? Say a web application which is yet to be packaged in Fedora as an rpm.
We also have to define the relationships (and how) between the images. Like the Requires in the rpm spec files. We know for sure that most of the actual applications will require more than one container running.
Rest looks good to me.
Replying to [comment:1 kushal]:
I'm hoping, in the near future, to have a good way to identify specific upstream content as acceptable for direct inclusion in Fedora containers (well, not quite direct — I think we'd need some mechanism to cache/archive it locally).
In the meantime, it would be cool if we could allow both Fedora-content-only and Fedora + other legally okay and open source content in the system, but require the latter to be based on a Fedora Remix base image, which we should provide. (Or, possibly we have a layered image which replaces Fedora branding with the Fedora Remix branding.)
Looks like a good start. +1
That is a different aspect is it not? An individual developer should be able to build off the "official"/"blessed" base image and layer additional components to create a mesh of containers delivering that service. In a somewhat ideal world, the availability of CDK etc should encourage the producers of containers to seek formal inclusion in the registry.
Any non-trivial containerized service will have multiple containers being managed. The specific gate of requiring the application to be available as an RPM may or, may not provide the added benefit of build system integrity providing a semblance of security checks.
Replying to [comment:4 sankarshan]:
Replying to [comment:1 kushal]: I guess we have to add more details about what all is allowed to be in the containers. Like can we get arbitrary things from Internet into those containers? Say a web application which is yet to be packaged in Fedora as an rpm. That is a different aspect is it not? An individual developer should be able to build off the "official"/"blessed" base image and layer additional components to create a mesh of containers delivering that service. In a somewhat ideal world, the availability of CDK etc should encourage the producers of containers to seek formal inclusion in the registry.
It is actually very much part of this discussion as we are formalizing the way one can build up an image on official Fedora Infrastructure. As matthew mentioned in the comment above, we clearly have to define what can be called/build/distributed as Fedora image.
We also have to define the relationships (and how) between the images. Like the Requires in the rpm spec files. We know for sure that most of the actual applications will require more than one container running. Any non-trivial containerized service will have multiple containers being managed. The specific gate of requiring the application to be available as an RPM may or, may not provide the added benefit of build system integrity providing a semblance of security checks. I guess we both are saying the same things here.
I guess we both are saying the same things here.
Replying to [comment:2 mattdm]:
Replying to [comment:1 kushal]: I guess we have to add more details about what all is allowed to be in the containers. Like can we get arbitrary things from Internet into those containers? Say a web application which is yet to be packaged in Fedora as an rpm. I'm hoping, in the near future, to have a good way to identify specific upstream content as acceptable for direct inclusion in Fedora containers (well, not quite direct — I think we'd need some mechanism to cache/archive it locally). In the meantime, it would be cool if we could allow both Fedora-content-only and Fedora + other legally okay and open source content in the system, but require the latter to be based on a Fedora Remix base image, which we should provide. (Or, possibly we have a layered image which replaces Fedora branding with the Fedora Remix branding.)
The above sounds really good to me. Do you know if we have to get any clearance on this from the legal?
Replying to [comment:6 kushal]:
On the Remix branding as suggested above, I believe we'd be following the current trademark guidelines as written. The Fedora Council is the steward of the trademark guidelines, and in consultation with legal could relax them further if we found that to be important/useful in the new world of containers and layered images. I spoke briefly with Richard Fontana about this, and he suggested that the trademark policy as it stands is more strict than strictly legally necessary, should we choose to relax it.
Upstream Atomic an has (excellent) best practices guide in progress. The intention is for this to be upstream for docs for Fedora (and CentOS and RHEL).
Rendered version: http://docs.projectatomic.io/container-best-practices/ Source: https://github.com/projectatomic/container-best-practices
The idea is to take this and then add any Fedora-specific information on top of that. We'd feed any general changes back to the upstream docs. I recommend ratifying that approach in the Cloud WG and then taking it to FESCo for full approval.
For tracking changes to enable distribution of these guidelines with Fedora's special bits: https://github.com/projectatomic/container-best-practices/issues/89
I have opened a ticket with FESCo for review and feedback.
https://fedorahosted.org/fesco/ticket/1573
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VHXGAR2YMVSJXYZPWH5A27JFFFLRR3IG/
Approved by FESCo, closing ticket.
Log in to comment on this ticket.