You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Jan Lehnardt <ja...@apache.org> on 2010/06/15 17:22:53 UTC
Anything else for 1.0? (Was: Re: New code goes into trunk)
On 14 Jun 2010, at 23:18, Jan Lehnardt wrote:
>> To make sure I understand... did we agree to branch 1.0 from trunk?
>
> Nope, we agreed to cut 1.0 from 0.11.x. 0.11.x was in disarray for a brief time but my latest commits are supposed to have fixed that. I think we should go ahead and branch 1.0.x from 0.11.x after applying and merging what we believe are the last patches that need to make it into 1,0.0. I should be ready with this for my end by tomorrow night CEST.
And done :)
Which other issues or patches that are not in 0.11.x yet do
you think need to be addressed before we branch 1.0? I'd
like to hear from everybody here, especially the
non-committers.
Cheers
Jan
--
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by till <ti...@php.net>.
I'd like to second COUCHDB-780. :D
On Tue, Jun 15, 2010 at 7:22 PM, Randall Leeds <ra...@gmail.com> wrote:
> https://issues.apache.org/jira/browse/COUCHDB-780 relates to windows file
> issues as well as fixing a source of surprising unresponsiveness with big
> databases (finishing compaction, deleting, etc). This patch is the only one
> I'd really like to wrap up for 1.0.
>
> On Jun 15, 2010 9:16 AM, "Juhani Ränkimies" <ju...@juranki.com> wrote:
>
> On Tue, Jun 15, 2010 at 6:22 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
>> Which other issues or patches that are not in 0.11.x yet do
>> you think need to be addressed befor...
> Windows file handling problems
> (https://issues.apache.org/jira/browse/COUCHDB-86 and
> https://issues.apache.org/jira/browse/COUCHDB-326)
>
>
> -juhani
>
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by Randall Leeds <ra...@gmail.com>.
https://issues.apache.org/jira/browse/COUCHDB-780 relates to windows file
issues as well as fixing a source of surprising unresponsiveness with big
databases (finishing compaction, deleting, etc). This patch is the only one
I'd really like to wrap up for 1.0.
On Jun 15, 2010 9:16 AM, "Juhani Ränkimies" <ju...@juranki.com> wrote:
On Tue, Jun 15, 2010 at 6:22 PM, Jan Lehnardt <ja...@apache.org> wrote:
> Which other issues or patches that are not in 0.11.x yet do
> you think need to be addressed befor...
Windows file handling problems
(https://issues.apache.org/jira/browse/COUCHDB-86 and
https://issues.apache.org/jira/browse/COUCHDB-326)
-juhani
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by Juhani Ränkimies <ju...@juranki.com>.
On Tue, Jun 15, 2010 at 6:22 PM, Jan Lehnardt <ja...@apache.org> wrote:
> Which other issues or patches that are not in 0.11.x yet do
> you think need to be addressed before we branch 1.0? I'd
> like to hear from everybody here, especially the
> non-committers.
>
> Cheers
> Jan
> --
Windows file handling problems
(https://issues.apache.org/jira/browse/COUCHDB-86 and
https://issues.apache.org/jira/browse/COUCHDB-326)
-juhani
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by Filipe David Manana <fd...@gmail.com>.
#2 issue of https://issues.apache.org/jira/browse/COUCHDB-793
On Tue, Jun 15, 2010 at 4:22 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On 14 Jun 2010, at 23:18, Jan Lehnardt wrote:
>
> >> To make sure I understand... did we agree to branch 1.0 from trunk?
> >
> > Nope, we agreed to cut 1.0 from 0.11.x. 0.11.x was in disarray for a
> brief time but my latest commits are supposed to have fixed that. I think we
> should go ahead and branch 1.0.x from 0.11.x after applying and merging what
> we believe are the last patches that need to make it into 1,0.0. I should be
> ready with this for my end by tomorrow night CEST.
>
> And done :)
>
> Which other issues or patches that are not in 0.11.x yet do
> you think need to be addressed before we branch 1.0? I'd
> like to hear from everybody here, especially the
> non-committers.
>
> Cheers
> Jan
> --
>
>
--
Filipe David Manana,
fdmanana@gmail.com
"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men."
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by Noah Slater <ns...@tumbolia.org>.
Glad to have helped!
On 17 Jun 2010, at 18:01, Randall Leeds wrote:
> Oh! So now I feel silly. I'm quite sorry for the noise, Noah. You have found
> the source of my confusion. Somehow I didn't really know the distinction
> between shell variables and environment variables[1]. No wonder I was
> frustrated trying to follow you...
>
> The su man page didn't help with its -m flag. That's what sent me off track.
>
>
> All clear now. Just needed to export it.
>
> [1]
> http://www.fnal.gov/docs/UNIX/unix_at_fermilab/htmldoc/rev1997/uatf-62.html
>
> On Jun 17, 2010 3:43 AM, "Noah Slater" <ns...@tumbolia.org> wrote:
>
>
> On 17 Jun 2010, at 01:57, Randall Leeds wrote:
>
>> Okay. My issue here stems from the fact that I do...
> If you put this:
>
> export ERL_MAX_PORTS=1024
>
> Into this:
>
> /etc/default/couchdb
>
> Then running this:
>
> /etc/init.d/couchdb start
>
> Would pick up the value in the first example, and pass it to Erlang.
>
> So as far as I know, the CouchDB daemon is already configurable in the
> manner you describe. If the above does not work, then it should, and that is
> a bug. If you're not wanting to use the standard init system for CouchDB,
> then you are on your own in terms of setting up the correct environment for
> whatever system you have designed.
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by Randall Leeds <ra...@gmail.com>.
Oh! So now I feel silly. I'm quite sorry for the noise, Noah. You have found
the source of my confusion. Somehow I didn't really know the distinction
between shell variables and environment variables[1]. No wonder I was
frustrated trying to follow you...
The su man page didn't help with its -m flag. That's what sent me off track.
All clear now. Just needed to export it.
[1]
http://www.fnal.gov/docs/UNIX/unix_at_fermilab/htmldoc/rev1997/uatf-62.html
On Jun 17, 2010 3:43 AM, "Noah Slater" <ns...@tumbolia.org> wrote:
On 17 Jun 2010, at 01:57, Randall Leeds wrote:
> Okay. My issue here stems from the fact that I do...
If you put this:
export ERL_MAX_PORTS=1024
Into this:
/etc/default/couchdb
Then running this:
/etc/init.d/couchdb start
Would pick up the value in the first example, and pass it to Erlang.
So as far as I know, the CouchDB daemon is already configurable in the
manner you describe. If the above does not work, then it should, and that is
a bug. If you're not wanting to use the standard init system for CouchDB,
then you are on your own in terms of setting up the correct environment for
whatever system you have designed.
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by Noah Slater <ns...@tumbolia.org>.
On 17 Jun 2010, at 01:57, Randall Leeds wrote:
> Okay. My issue here stems from the fact that I don't consider using more
> than 1024 ports a specialist use case deserving of a custom wrapper. Having
> fifty replications with default options already goes beyond this limit.
>
> COUCHDB_OPTIONS could be used for command line flags with the change I
> proposed above, but ERL_MAX_PORTS is only set via the environment, which
> should be easily configured but is currently not.
If you put this:
export ERL_MAX_PORTS=1024
Into this:
/etc/default/couchdb
Then running this:
/etc/init.d/couchdb start
Would pick up the value in the first example, and pass it to Erlang.
So as far as I know, the CouchDB daemon is already configurable in the manner you describe. If the above does not work, then it should, and that is a bug. If you're not wanting to use the standard init system for CouchDB, then you are on your own in terms of setting up the correct environment for whatever system you have designed.
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by Randall Leeds <ra...@gmail.com>.
Okay. My issue here stems from the fact that I don't consider using more
than 1024 ports a specialist use case deserving of a custom wrapper. Having
fifty replications with default options already goes beyond this limit.
COUCHDB_OPTIONS could be used for command line flags with the change I
proposed above, but ERL_MAX_PORTS is only set via the environment, which
should be easily configured but is currently not.
On Jun 16, 2010 5:39 PM, "Noah Slater" <ns...@tumbolia.org> wrote:
On 17 Jun 2010, at 01:07, Randall Leeds wrote:
> On Wed, Jun 16, 2010 at 16:52, Noah Slater <nslat...
-1 on that.
The /etc/defaults/couchdb file is specifically for the init system.
You can pass arbitrary flags to Erlang using the ERL_FLAGS environment
variable. The script takes special care to make sure that Erlang shares its
environment. If you have a specific set of flags you wish to call as
standard, and you don't wish to use the init.d system, then I would advise
that you create a wrapper script for your particular use case.
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by Noah Slater <ns...@tumbolia.org>.
On 17 Jun 2010, at 01:07, Randall Leeds wrote:
> On Wed, Jun 16, 2010 at 16:52, Noah Slater <ns...@tumbolia.org> wrote:
>>
>> On 16 Jun 2010, at 23:59, Randall Leeds wrote:
>>
>>> I'd really like to sort out the situation with resource limits.
>>>
>>> My patch to allow setting a larger mochiweb connection limit was
>>> committed (COUCHDB-705), but currently there's no easy user story for
>>> increasing things like ERL_MAX_PORTS. I'd also be nice if we could
>>> allow people to pass arbitrary flags to the vm. For example, I only
>>> recently discovered how nice the +A option is. Unfortunately, the
>>> solution I have in production to avoid clobbering the init script is
>>> to have the couchdb user use bash as a login shell and export
>>> ERL_MAX_PORTS and ERL_ZFLAGS in .bash_profile. I think this is a
>>> really hackish thing to do to a daemon.
>>
>> Why can't we just use /etc/defaults/couchdb for this?
>
> We can. Currently the init script sources that and passes the relevant
> options directly. I'd be +1 on having the init script call couch much
> more blindly and let /usr/bin/couchdb deal with sourcing the defaults.
> This would obviate the need for passing arguments to erlang because
> ERL_(A|Z)?FLAGS could be used instead.
> I can write this if you don't have time, but your sh-fu is probably
> better than mine.
-1 on that.
The /etc/defaults/couchdb file is specifically for the init system.
You can pass arbitrary flags to Erlang using the ERL_FLAGS environment variable. The script takes special care to make sure that Erlang shares its environment. If you have a specific set of flags you wish to call as standard, and you don't wish to use the init.d system, then I would advise that you create a wrapper script for your particular use case.
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by Randall Leeds <ra...@gmail.com>.
On Wed, Jun 16, 2010 at 16:52, Noah Slater <ns...@tumbolia.org> wrote:
>
> On 16 Jun 2010, at 23:59, Randall Leeds wrote:
>
>> I'd really like to sort out the situation with resource limits.
>>
>> My patch to allow setting a larger mochiweb connection limit was
>> committed (COUCHDB-705), but currently there's no easy user story for
>> increasing things like ERL_MAX_PORTS. I'd also be nice if we could
>> allow people to pass arbitrary flags to the vm. For example, I only
>> recently discovered how nice the +A option is. Unfortunately, the
>> solution I have in production to avoid clobbering the init script is
>> to have the couchdb user use bash as a login shell and export
>> ERL_MAX_PORTS and ERL_ZFLAGS in .bash_profile. I think this is a
>> really hackish thing to do to a daemon.
>
> Why can't we just use /etc/defaults/couchdb for this?
We can. Currently the init script sources that and passes the relevant
options directly. I'd be +1 on having the init script call couch much
more blindly and let /usr/bin/couchdb deal with sourcing the defaults.
This would obviate the need for passing arguments to erlang because
ERL_(A|Z)?FLAGS could be used instead.
I can write this if you don't have time, but your sh-fu is probably
better than mine.
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by Noah Slater <ns...@tumbolia.org>.
On 16 Jun 2010, at 23:59, Randall Leeds wrote:
> I'd really like to sort out the situation with resource limits.
>
> My patch to allow setting a larger mochiweb connection limit was
> committed (COUCHDB-705), but currently there's no easy user story for
> increasing things like ERL_MAX_PORTS. I'd also be nice if we could
> allow people to pass arbitrary flags to the vm. For example, I only
> recently discovered how nice the +A option is. Unfortunately, the
> solution I have in production to avoid clobbering the init script is
> to have the couchdb user use bash as a login shell and export
> ERL_MAX_PORTS and ERL_ZFLAGS in .bash_profile. I think this is a
> really hackish thing to do to a daemon.
Why can't we just use /etc/defaults/couchdb for this?
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by Randall Leeds <ra...@gmail.com>.
I'd really like to sort out the situation with resource limits.
My patch to allow setting a larger mochiweb connection limit was
committed (COUCHDB-705), but currently there's no easy user story for
increasing things like ERL_MAX_PORTS. I'd also be nice if we could
allow people to pass arbitrary flags to the vm. For example, I only
recently discovered how nice the +A option is. Unfortunately, the
solution I have in production to avoid clobbering the init script is
to have the couchdb user use bash as a login shell and export
ERL_MAX_PORTS and ERL_ZFLAGS in .bash_profile. I think this is a
really hackish thing to do to a daemon.
COUCHDB-590 has been sitting idle for quite some time. I recently
discovered /etc/security/limits.conf and so I closed it as invalid and
distro specific. With that taken care of all we really need is
ERL_MAX_PORTS.
rnewson suggested I look at ejabberd. I found that they source
/etc/default/ejabberd in /usr/sbin/ejabberd. Couch doesn't do this,
which I actually sort of like, because it lets you launch couch by
hand without grabbing all those variables.
I'm thinking that anything after a "--" could be passed straight to
erlang, which covers flags like +A <n>. But how should one set an
arbitrary environment for couch? I'd be fine with something like
/etc/couchdb/environment which gets sourced by bin/couchdb.
Thoughts? I think it'd be unfortunate if this story wasn't sorted out
before 1.0.
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by Zachary Zolton <za...@gmail.com>.
+1 on #802. (I've already been bitten this)
On Wednesday, June 16, 2010, Jason Smith <jh...@couch.io> wrote:
> On Tue, Jun 15, 2010 at 22:22, Jan Lehnardt <ja...@apache.org> wrote:
>
>> Which other issues or patches that are not in 0.11.x yet do
>> you think need to be addressed before we branch 1.0? I'd
>> like to hear from everybody here, especially the
>> non-committers.
>
>
> I would love to see COUCHDB-802 go in. IMO it would be unfortunate to freeze
> the API where a _show and _update are incapable of mimicking the standard
> api (made quite powerful due to vhosts and rewrite).
>
> --
> Jason Smith
> Couchio Hosting
>
Re: Anything else for 1.0? (Was: Re: New code goes into trunk)
Posted by Jason Smith <jh...@couch.io>.
On Tue, Jun 15, 2010 at 22:22, Jan Lehnardt <ja...@apache.org> wrote:
> Which other issues or patches that are not in 0.11.x yet do
> you think need to be addressed before we branch 1.0? I'd
> like to hear from everybody here, especially the
> non-committers.
I would love to see COUCHDB-802 go in. IMO it would be unfortunate to freeze
the API where a _show and _update are incapable of mimicking the standard
api (made quite powerful due to vhosts and rewrite).
--
Jason Smith
Couchio Hosting