Hi all, So a couple of questions I'd like clarity on surrounding this... I see that we just need a Dockerfile in dist-git and fedpkg container-build can work from the existing git repo but is this intended to be supported or do we need to provide a fresh review request and then only build from the dist-git docker namespace, rather than rpm? Where there is no existing lower layer that would be useful (eg httpd+mod_php+mod_ssl) is it permitted to have a container that installs httpd, mod_php and mod_ssl for a PHP based application? What is considered acceptable for volumes specified in the dockerfile? Anywhere data or config is expected? How should we provide instructions on how to run the container? Just a readme.md in dist-git? Actually include something in the container? Is an entrypoint of ["/sbin/init"] permitted to make use of systemd for handling zombies and service unit files? This of course would then limit the container to docker hosts that have oci-systemd-hook to work properly if so, but massively simplifies things for services. As a real world example I'd like to get out there I'm testing out a container in the Fedora build infrastructure for owncloud. Here's what I was playing with last night: http://pkgs.fedoraproject.org/cgit/rpms/owncloud.git/tree/Dockerfile Here's the task from koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=16992119 Does the --scratch option actually do anything, as it doesn't seem reflected in that build? That particular build can be tested and run by: docker run -d -P candidate-registry.fedoraproject.org/f25/owncloud:rawhide-docker-candidate-20161220120656 on any docker host that has the systemd oci hook. It would be very useful to be able to provide some sort of upfront readme/document that lists volumes used to persistence etc to aid updates in future mapping to the same (named?) volume. I think we need some of this detail added to the container build guidelines for review reasons. James _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
