On 19 June 2017 at 13:57, Rob Godfrey <[email protected]> wrote: > 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?
I would say so yes, one of my later items was relating to that aspect. > 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. > Yep > >> - 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). > Yes the specifics of any particular package should also be discussed seperately. I'd say we are still at the point of this discusssion that things can be discussed in tandem with regard to Docker images and whether they go that way. > >> 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? > I'm not sure there is any consistent precedent, more a variety of different appaches. Some dont mention OS at all, ones choose one, others have a couple with perhaps Alpine being there for low size. For some it also looks like images, though 'Docker official', aren't necessarily maintained by the projects but rather the Docker community instead. Some others it seems dont have a direct set of images at all but perhaps do see popular images for related offerings built on them. > >> >> - 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] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
