In the not too distant future, we will be offering Docker Layered Images as a "Tier 1" deliverable build artifact, in line with rpms. Along with that there needs to be some level of contributor guidelines as well as review process for new layered images.
I have written drafts of container guidelines and an enhanced review process page to incorporate reviews of container layered images. However, I am requesting feedback on the documents in general as well as advisement on any areas of the documents marked "FIXME" (mostly around bugzilla components and update process, as these are still left to be hashed out).
https://fedoraproject.org/wiki/PackagingDrafts/Containers https://fedoraproject.org/wiki/PackagingDrafts/Package_Review_Process_with_Containers
Thank you, -AdamM
Adding Naming Guidelines: https://fedoraproject.org/wiki/Draft/Packaging:DockerLayeredImageNamingGuidelines
The idea here is to follow the mainline naming guidelines but provide "overrides" for sections of the original document, without duplicating content so we don't have to maintain multiple wiki docs.
I think it might be good to run these by devel list and also FPC. Not sure FPC wants to have anything to do with them (since they are not packages), but they might want to have some input, or perhaps we might want to form a FCC (Fedora Container Comittee).
What about using rocket (rkt) instead of docker? Rocket claims to not show the security issues docker introduces to host machines.
Rocket had (or still has?) some issues with SELinux though and I wonder why it's not (yet) available for Fedora 23.
https://coreos.com/blog/rocket/
http://www.infoworld.com/article/3029682/application-virtualization/coreos-launches-rocket-10-directly-at-docker.html
http://koji.fedoraproject.org/koji/packageinfo?packageID=21775
Package review: https://bugzilla.redhat.com/show_bug.cgi?id=1169966
Replying to [comment:3 kevin]:
… perhaps we might want to form a FCC (Fedora Container Comittee).
FCC is already a reserved name in several instances. Maybe FeCoCo is better for us.
The Fedora Cloud SIG might be interested, too.
https://github.com/fedora-cloud/Fedora-Dockerfiles
https://github.com/fedora-cloud/Fedora-rktfiles
https://fedoraproject.org/wiki/Cloud_SIG
Replying to [comment:4 raphgro]:
What about using rocket (rkt) instead of docker? Rocket claims to not show the security issues docker introduces to host machines. Rocket had (or still has?) some issues with SELinux though and I wonder why it's not (yet) available for Fedora 23. https://coreos.com/blog/rocket/ http://www.infoworld.com/article/3029682/application-virtualization/coreos-launches-rocket-10-directly-at-docker.html http://koji.fedoraproject.org/koji/packageinfo?packageID=21775 Package review: https://bugzilla.redhat.com/show_bug.cgi?id=1169966
I'm not against targeting rkt in the future but for now all the work has been done for enabling docker and I'd like to round that out and finish it up before moving on to another container image format.
https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service
Replying to [comment:5 raphgro]:
Replying to [comment:3 kevin]: … perhaps we might want to form a FCC (Fedora Container Comittee). FCC is already a reserved name in several instances. Maybe FeCoCo is better for us. The Fedora Cloud SIG might be interested, too. https://github.com/fedora-cloud/Fedora-Dockerfiles https://github.com/fedora-cloud/Fedora-rktfiles https://fedoraproject.org/wiki/Cloud_SIG
I have brought this up with the Cloud SIG and have been working with them in the past, they provided feedback which lead the documents to here.
+1 I will bring this to the devel list for now and remove the Meeting keyword from the ticket until I get further feedback. I would love for there to be a Fedora Container Committee that is a parallel (but not necessarily disjoint) to what the FPC is. I'll bring that up in the email to the devel list.
devel list email thread: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VHXGAR2YMVSJXYZPWH5A27JFFFLRR3IG/
Replying to [comment:6 maxamillion]: …
Ack. My comment wasn't at all against the docker image format as such. As mentioned in the article, rkt is able to read the 3rdparty docker files, too. Just wanted to point to an important fact about the security issues with the docker process running as the root user, though SELinux is doing its best to catch the flaws for both types of containers.
Replying to [comment:11 raphgro]:
Replying to [comment:6 maxamillion]: … I'm not against targeting rkt in the future but for now all the work has been done for enabling docker and I'd like to round that out and finish it up before moving on to another container image format. Ack. My comment wasn't at all against the docker image format as such. As mentioned in the article, rkt is able to read the 3rdparty docker files, too. Just wanted to point to an important fact about the security issues with the docker process running as the root user, though SELinux is doing its best to catch the flaws for both types of containers.
+1
There's also work being done in upstream docker around runc + containerd in mainline docker which should allow for easier transition of non-priv containers either via the "new docker" or by runc itself. I don't know the current status of it all, but at least some of the containerd stuff made it into docker 1.11 so it definitely seems to be heading in that direction.
In today's meeting, its decided that AGREED: revisit this ticket next week
Is there any interest in enforcing any of these generic labels from Project Atomic?
https://github.com/projectatomic/ContainerApplicationGenericLabels
Also, as a point of reference. I did submit this to the devel mailing list a second time as per FESCo request.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SP2TIGP6H5NELZYHE65SEX5EPNYKZUQT/
The guidelines were approved in today's FESCo meeting. Thanks @maxamillion.
Login to comment on this ticket.