Hi Joan, you’re absolutely right that a docker container should only run a single node. That’s what we should do in the future. Right now it starts up the dev cluster with three nodes. I think that’s reasonable for the 2.0 „alpha-be-careful-testing-only“ version, though, as it shows off the new cluster capabilities quite nicely and makes it extremely easy for people to take a look at the upcoming 2.0.
Clemens > Am 01.02.2016 um 18:43 schrieb Joan Touzet <[email protected]>: > > I've not been following this message trail carefully, but I have a question. > > Does the docker image run 3 instances within the same image, or is it a > single node version? The reason I ask is that, in deployment, which is > where I would expect docker to shine, you'd **NEVER** want to run 3 > nodes on the same machine. It basically removes the entire clustering > feature from CouchDB. > > I'm happy to explain more if it's not clear why having the default docker > image as a single node is strongly preferable. > > -Joan > > ----- Original Message ----- >> From: "Jan Lehnardt" <[email protected]> >> To: [email protected] >> Sent: Monday, February 1, 2016 10:22:42 AM >> Subject: Re: Applied for official Docker image >> >> >>> On 01 Feb 2016, at 08:18, Dave Cottlehuber <[email protected]> >>> wrote: >>> >>> On Tue, 26 Jan 2016, at 02:19 AM, Eli Stevens (Gmail) wrote: >>>> On Mon, Jan 25, 2016 at 11:10 AM, Alexander Shorin >>>> <[email protected]> >>>> wrote: >>>>> On Mon, Jan 25, 2016 at 9:59 PM, Eli Stevens (Gmail) >>>>> <[email protected]> wrote: >>>>>> The intent was to hopefully have the build scripts, etc. folded >>>>>> back >>>>>> into the main repo to make it easier for future releases to have >>>>>> official packages, but I think that everyone was too focused on >>>>>> core >>>>>> 2.0 issues to get too involved in packaging (and also enough >>>>>> changed >>>>>> that it was probably too early to get it right). >>>>> >>>>> Hm...nice! Do you have these build scripts? We can put them into >>>>> our >>>>> repo now even for 1.6 state. That would be still better than >>>>> start >>>>> whole work from scratch and I think we can make these builds >>>>> official >>>>> via CI services that will run Ubuntu anyway. >>>> >>>> I don't have the scripts, as the only formal deliverable from >>>> earlier >>>> was a working Ubuntu 12.04 package of 1.6.1 (and we wouldn't have >>>> had >>>> a use for the scripts in any case, as we're not interested in >>>> building >>>> CouchDB ourselves, hence contracting that out to someone who knows >>>> what they're doing). >>>> >>>> I'll let Dave comment about the new work, once we've got a >>>> contract >>>> hammered out, and he's been able to devote some time to the >>>> project. >>>> Again, it might be a bit before that happens. >>>> >>>> Cheers, >>>> Eli >>> >>> The scripts are public[1] and we could merge them happily if it >>> makes >>> sense where they go to. I should explain briefly how these are >>> built, as >>> this >>> is relevant. >>> >>> The repo master branch includes the unpacked couchdb release >>> tarball in >>> the root, and a /debian/ folder with all the magic pixie dust. On >>> each >>> new >>> release (whether of couchdb, updating packaging, or re-packaging >>> for >>> a new ubuntu release), do the following: >>> >>> - spin up a compatible Ubuntu box >>> - provision with ansible [2] >>> - bare clone the repo >>> - check out only the /debian/ packaging directory (patches, >>> dependency >>> info) >>> - unpack the new couchdb release >>> - commit the "changes" to git >>> - futz around with init scripts, systemd and whatever until couchdb >>> works >>> >>> There's no particular reason why this shouldn't work for 2.0, more >>> detail in >>> the associated wiki[3]. >>> >>> I updated the repo for 1.6.1 and supporting wily + xenial [4], the >>> main >>> change >>> is integrating systemd changes and complying with the latest debian >>> packaging tools, so this is a good base to continue from. >>> >>> I'm not sure where these scripts would go in our ASF world, but >>> they >>> should >>> be kept in step with any releases. >> >> I’d put them in couchdb.git/build-aux for now, that’s where I keep >> scripts >> that are run during configure/make. If this should be its own repo, >> we can >> apply for couchdb-package.git or something. >> >> Would the ./build-aux directory work for now? >> >> Best >> Jan >> -- >> >> >> >>> >>> Finally, anybody wishing to contribute to the ppa or the build repo >>> is >>> welcome >>> just email me (PPA) or send a PR (build repo). >>> A+ >>> Dave >>> >>> [1]: https://github.com/dch/couchdb-launchpad >>> [2]: https://gist.github.com/dch/86982e187e97a9b23bf5 >>> [3]: >>> https://github.com/dch/couchdb-launchpad/wiki/creating-the-package >>> [4]: https://launchpad.net/~couchdb/+archive/ubuntu/dev/ >>> [5]: https://launchpad.net/~couchdb/ >> >>
