I think docker images would be good to have. Rather than reply to lots of little bits from various different mails, I'm just going to gather some general comments/questions here based on the previous mails.
- If I understand correctly Irina's proposal is essentially to create create RPMs/DEBs (for certain components at least, might not be as useful/necessary to others, see later) and then create docker images using them (configure yum/dnf/apt repo, call install?). To Jakub's point around doing things such as nightly RPMs, that could form part of it however we still wouldn't especially promote them to end users, much like the maven repo snapshots arent, as such interim builds are only meant to be known to folks tracking/partipating in development as we are only allowed to direct regular everyday users at project releases. - One thing I think worth some thought/discussion is versioning, e.g . what would the docker tags offered be. It looks like some projects do precise full-version tags to a specific 'major.minor.patch' release, as well as more general 'minor version' and 'major version' tags netting the latest release in a given stream. There might be some related behaviour there to decide on, e.g if using the OS package systems, would running an update result in moving to a newer component release in the stream. For some of those tag formats it could, while for others it should not. - If we do start offering images based on packages, then those packages and the related images essentially become 'convenience binaries' for the release that get created+tested by the project as part of the components release process. For bug fixes and functionality updates to be usable in images, there will need to be matching component releases to allow updating their packages and in turn images. I think this points to the project doing more [patch] releases for some of our components (i.e. ones we only do source release archives for), which I think would also be a very good thing. - Its true that having multiple base OS options would take maintenance. Only having one option on the other hand probably involves some decisions as to which (for a given component? Perhaps they might not all be the same?). I think this also probably gets into considering what people are looking for when they use a docker image. In the case of a server such as a broker some people might just want the port(s) listening and doing stuff to use/try-out a particular server and dont care what OS etc is under it, while others might care that that its on a particular OS variant (e.g one they use for all their other bits), and others still might only care that its as small an image as possible (somewhat combining the previous behaviours to an extent). - To the comments around the Java broker, I don't think creating packages for it is really necessary? From a quick look at some others images it doesnt seem unusual to have a Dockerfile set up to pull the existing binary release archive, verify its sigs, and extract+configure it in an appropriate location. Robbie On 13 June 2017 at 15:13, Irina Boverman <[email protected]> wrote: > Hi everyone, > > I would like to propose creating Docker images for Qpid components hosted > in Docker Hub, updated upon component release and maintained by the > project, and I would like to contribute to doing this. > > Availability of Qpid images will make it easier to consume/deploy Qpid > components and promote Qpid visibility. > > We can maintain docker scripts creating these images from the base OS > images and using Qpid installation methods consistent with the OS > distribution. A possible naming convention might be qpid/<component>/<OS>. > I registered the 'qpid' user on DockerHub to use if this seems reasonable. > For example, we could create qpid/dispatch/<OS> image, qpid/<broker>/<OS> > image, qpid/<client(s)>/<OS> image, etc. Initially I would look to support > Fedora/CentOS latest images and Qpid components as RPMs for them, then aim > to expand OS coverage for debian/Ubuntu/etc in the future. > > The goal would be to update Qpid images within a few days upon component > release (either directly or indirectly using yum/dnf from public > repositories). We could ask the Docker team to grant Qpid "official" status > when images have been stabilized. > -- > Regards, Irina. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
