Hey! Just following up on this thread. What's the status?
thanks, -K On Tue, Jul 11, 2017 at 11:27 AM, Robbie Gemmell <[email protected]> wrote: > On 29 June 2017 at 17:52, Irina Boverman <[email protected]> wrote: >> Thank you all who thoughtfully responded to this proposal. This is a >> summary as I understood it and my comments regarding these points. >> >> (1) Qpid community is in favour of creating and maintaining docker images >> for cpp/java brokers >> and dispatch router. OS choice is less important, as long as the user can >> connect to the broker/router port. We only need to support one OS choice. >> >> I think this is a good start. It covers a use case when someone wants to >> test or deploy client apps against broker/router conveniently running as a >> docker service. >> >> I think there might be another use case for those users who want to develop >> client apps in a known environment with client libraries already installed >> for them to work with. I think the OS choice is important to these users >> because they may have a preference/better knowledge of this particular OS. >> Please consider this use case. >> >> (2) Docker images should be of minimal size. >> >> As a concept, I fully agree with it. However, community support for >> official images also makes sense to me. These images go through review and >> testing, as well as, get patches for CVEs. There is a whole infrastructure >> in place in Fedora to build docker images, etc following best practices >> from OCI. >> >> Official images range in size between 120 to 200 mb, and have 10+ mil of >> downloads, so the size does not appear to be an obstacle to adopting them. >> It is my opinion that future official images will evolve to be better >> aligned with how they are used, for example "server" and "workstation", etc. >> >> REPOSITORY TAG IMAGE ID >> CREATED SIZE >> docker.io/ubuntu latest ebcd9d4fca80 >> 6 weeks ago 117.9 MB >> docker.io/debian latest e5599115b6a6 >> 5 months ago 123 MB >> docker.io/centos latest 67591570dd29 >> 6 months ago 191.8 MB >> docker.io/fedora latest a1e614f0f30e >> 6 months ago 197.1 MB >> >> We can also modify the base image to remove some items if we think they are >> not needed. >> > > I think using a base OS image is fine, and your text and Justin's link > suggests there are likely to be improvements in some regards in this > area too. There is also nothing stopping a further image as minimal > size option based on Alpine etc, but obviously components would need > to work and be supported there first and it wasn't clear that is > currently always true. > >> My personal preference is to start with fedora image because this >> distribution has latest upstream releases for qpid packages, and I am the >> maintainer for a number of these packages. > > I think we possibly need some clarity around the end result here, as > it could strongly influence this particular area. > > For images to be considered 'official' Apache Qpid artifacts > maintained directly by the project, they and their Qpid related > contents would really need to be fully managed in concert with the > projects release process. For example, if such an image were utilising > packages to incorporate their relevant Qpid bits then I think it > follows those packages would similarly need to be considered > 'official' and handled similarly. Utilising the Qpid packages from > Fedora distributions for example, wouldn't be appropriate in an > 'official Apache Qpid' image since they are not directly managed > artifacts of the Apache Qpid project. > > There wouldn't be an issue in simply considering such images to be a > community-created convenience binaries based on the projects source > release, as e.g. the existing Fedora packages themselves already are, > but they wouldn't be considered 'official' Apache Qpid artifacts. It > is worth saying this isn't particularly unusual, for example httpd > direct people to their source releases but do reference various third > party binaries for Windows users, and don't seem to be involved with > the docker images for httpd, with members of the docker community > instead handling that. > > I think either approach works here, having distribution based packages > obviously has certain advantages for users and the project, so its > probably more of a question around what people are actually expecting > and/or looking to contribute towards here. > >> Fedora community is also working on its own docker registry (it will have >> stable and test registries), has koji support for building images and >> guidelines for naming and versioning them. >> >> (3). What upstream releases will be dockerised? >> >> I would like to propose to start with latest released version. We will >> maintain at most 1 version at any time. All code necessary to create these >> images should be included in the upstream source repository starting with >> the next release. We will provide security patches for it as needed (and >> possibly will need patch releases). I am not sure if it will be possible to >> remove older releases from docker registries (TBD). >> >> (4) What will be used to configure docker images? >> >> We can use env to configure brokers/router, similar to what was done here: >> https://hub.docker.com/r/scholzj/qpid-cpp/ (courtesy of Jakub Scholz). >> >> References: >> >> #Changes/Layered Docker Image Build Service >> https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service#Policies_and_guidelines >> >> #Fedora Docker Layered Image Build Service by Adam Miller >> https://blog.openshift.com/wp-content/uploads/Introducing-Docker-Layered-Image-Build-Service.pdf >> >> #OpenShift Commons Briefing #57: Fedora Docker Layered Image Build Service >> by Adam Miller >> https://www.youtube.com/watch?v=HHm0L6Fw5nk >> >> #Layered Image Build System >> https://docs.pagure.org/infra-docs/sysadmin-guide/sops/layered-image-buildsys.html >> >> #Atomic Reactor: Python library with command line interface for building >> docker images. >> https://github.com/projectatomic/atomic-reactor >> >> #Fedora Docker Layered image build service now available blog >> https://communityblog.fedoraproject.org/fedora-docker-layered-image-build-service-now-available/ >> >> #Example of container build: cockpit >> https://koji.fedoraproject.org/koji/packageinfo?packageID=17959 >> >> #Container:Guidelines >> https://fedoraproject.org/wiki/Container:Guidelines >> >> #Fedora container repo >> https://src.fedoraproject.org/cgit/container/ >> >> #Building a modular Linux OS >> https://docs.pagure.org/modularity/ >> >> #projectatomic/container-best-practices >> https://github.com/projectatomic/container-best-practices >> >> #Container Best Practices >> http://docs.projectatomic.io/container-best-practices/ >> >> #Red Hat Image Naming Policy >> https://github.com/projectatomic/ContainerApplicationGenericLabels/blob/master/vendor/redhat/names.md >> >> #Guidelines for Naming Fedora Packages (including docker images) >> https://fedoraproject.org/wiki/Packaging:Naming?rd=Packaging:NamingGuidelines >> >> #OCI: open container initiative >> https://www.opencontainers.org/ >> >> #Changes/FedoraDockerRegistry >> https://fedoraproject.org/wiki/Changes/FedoraDockerRegistry >> >> #Creating minimal Docker images from dynamically linked ELF binaries >> http://blog.oddbit.com/2015/02/05/creating-minimal-docker-images/ >> >> #Why docker images should be small >> https://opensolitude.com/2015/05/13/docker-images-should-be-small.html >> >> Regards, Irina. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- -K --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
