Re: Applied for official Docker image

[Dave Cottlehuber <dc...@skunkwerks.at>]

On Tue, 26 Jan 2016, at 02:19 AM, Eli Stevens (Gmail) wrote:
> On Mon, Jan 25, 2016 at 11:10 AM, Alexander Shorin <kx...@gmail.com>
> wrote:
> > On Mon, Jan 25, 2016 at 9:59 PM, Eli Stevens (Gmail)
> > <wi...@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.

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/

Re: Applied for official Docker image

[Clemens Stolle <cl...@fastmail.com>]

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 <wo...@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" <ja...@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 <dc...@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
>>>> <kx...@gmail.com>
>>>> wrote:
>>>>> On Mon, Jan 25, 2016 at 9:59 PM, Eli Stevens (Gmail)
>>>>> <wi...@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/
>> 
>> 

Re: Applied for official Docker image

[Joan Touzet <wo...@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" <ja...@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 <dc...@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
> >> <kx...@gmail.com>
> >> wrote:
> >>> On Mon, Jan 25, 2016 at 9:59 PM, Eli Stevens (Gmail)
> >>> <wi...@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/
> 
> 

Re: Applied for official Docker image

[Jan Lehnardt <ja...@apache.org>]

> On 01 Feb 2016, at 08:18, Dave Cottlehuber <dc...@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 <kx...@gmail.com>
>> wrote:
>>> On Mon, Jan 25, 2016 at 9:59 PM, Eli Stevens (Gmail)
>>> <wi...@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/