couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clemens Stolle <clemens.sto...@fastmail.com>
Subject Re: Applied for official Docker image
Date Mon, 01 Feb 2016 20:15:32 GMT
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 <wohali@apache.org>:
> 
> 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" <jan@apache.org>
>> To: dev@couchdb.apache.org
>> 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 <dch@skunkwerks.at>
>>> 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
>>>> <kxepal@gmail.com>
>>>> wrote:
>>>>> On Mon, Jan 25, 2016 at 9:59 PM, Eli Stevens (Gmail)
>>>>> <wickedgrey@gmail.com> 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/
>> 
>> 


Mime
View raw message