On 19 June 2017 at 14:16, Robbie Gemmell <[email protected]> wrote:
> I think docker images would be good to have. > > +1 > 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?). If this is the proposal then does that also mean that these rpms/debs will also have some sort of official status? If so would we want to document/vote that as well? > 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. > > Agreed - IIUC it would actually be against Apache policy to make available any "official" binary that was not just a convenience build of a voted release. > - 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. It seems to me that discussion on use of OS packaging systems and our versioning within them is worthy of a separate discussion / proposal (and may be a pre-requisite for building docker images for some components, if that is the way we wish to go). > 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. > +1 > > - 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). > Agreed - are there any precedents in other Apache projects that we think it would be useful to follow? > > - 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. > This also make sense to me. As a consumer of Java components, the use of OS package systems would seem unnecessary here. Do we have a list of the components/combinations which we think it would make sense to produce/support docker images for? -- Rob > > 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] > >
