You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Benoit Chesneau <bc...@gmail.com> on 2011/07/22 13:56:47 UTC
create_target isn't working with the _replicator db
Hi all,
While testing the _replicator db I encounter an error when trying to
create the target db . Before opening a ticket I wanted to make sure
this wasn't expected or if it"s an error.
The error:
$ curl -XPUT -H"Content-Type: application/json" localhost:5984/a
{"ok":true}
$ curl -XPUT -d'{}' localhost:5984/a/doca
{"ok":true,"id":"doca","rev":"1-967a00dff5e02add41819138abb3284d"}
curl -XPUT -d'{}' localhost:5984/a/docb
{"ok":true,"id":"docb","rev":"1-967a00dff5e02add41819138abb3284d"}
$ curl -XPOST -d'{
"source": "a",
"target": "b",
"create_target": true
}' -H"Content-Type: application/json" localhost:5984/_replicator
{"ok":true,"id":"2f6df84e4a02978cf80424bce0000f1c","rev":"1-4b8c482da7ce243353493fb87e766428"}
enki:~ benoitc$ curl -XGET
localhost:5984/_replicator/2f6df84e4a02978cf80424bce0000f1c
{"_id":"2f6df84e4a02978cf80424bce0000f1c","_rev":"2-b557bd698ecebc359bd5f51b2691a2fd","source":"a","target":"b","create_target":true,"_replication_state":"error","_replication_state_time":"2011-07-22T13:49:21+02:00","_replication_id":"01e205795e3f5ad9968f51e6e1e61335"}
enki:~ benoitc$
Error:
<<"unauthorized to access database b">>}.
Retrying in 10 seconds
[error] [<0.867.0>] {error_report,<0.30.0>,
{<0.867.0>,crash_report,
[[{initial_call,{couch_rep,init,['Argument__1']}},
{pid,<0.867.0>},
{registered_name,[]},
{error_info,
{exit,
{unauthorized,<<"b">>},
[{gen_server,init_it,6},
{proc_lib,init_p_do_apply,3}]}},
{ancestors,
[couch_rep_sup,couch_primary_services,
couch_server_sup,<0.31.0>]},
{messages,[]},
{links,[<0.81.0>]},
{dictionary,[]},
{trap_exit,true},
{status,running},
{heap_size,610},
{stack_size,24},
{reductions,199}],
[]]}}
Let me know.
- benoît
Re: create_target isn't working with the _replicator db
Posted by Jan Lehnardt <ja...@apache.org>.
Hi Randall,
here's how I see this whole thing:
I think the replicator db API is superior to "old" API.
I think it is perfectly acceptable to have two APIs for the same thing in a transitional period.
I think we should eventually remove all specific code that handles _replicate and have the _replicator code implement _replicate (In fact that is what Benoit proposed initially and if I remember correctly, we all thought is was a good idea).
I think when we can (2.0 e.g.) we should deprecate the use of _replicate in favour of _replication and in a second step remove even the code that we wrote for the previous point.
Right now we are in a transitional period, and yes, that has disadvantages, but I don't see any immediate way out other than what we have planned or how we should have approached this differently. I believe everybody (certainly I am) is happy to discuss alternatives.
Cheers
Jan
--
On 22 Jul 2011, at 20:31, Randall Leeds wrote:
> On Fri, Jul 22, 2011 at 11:26, Randall Leeds <ra...@gmail.com> wrote:
>> On Fri, Jul 22, 2011 at 09:40, Benoit Chesneau <bc...@gmail.com> wrote:
>>> On Fri, Jul 22, 2011 at 5:54 PM, Filipe David Manana
>>> <fd...@apache.org> wrote:
>>>> On Fri, Jul 22, 2011 at 8:43 AM, Benoit Chesneau <bc...@gmail.com> wrote:
>>>>>
>>>>> Yup, but I think that's a bug then. I shouldn't have to set any
>>>>> userctx imo. If no admin has been set, every user is an admin except
>>>>> if we change the default behavior and then it's not consistent.
>>>>
>>>> This was discussed sometime before the 1.1.0 release in the security list.
>>>> And it's a principle of the least privileges by default (roles is an
>>>> empty list).
>>>>
>>>>
>>> I've no problem with that, it's even good. But other part of the API
>>> aren't consistent then. While _replicator is ok, I can still do this
>>> operation on _replicate. I propose to port the same behavior
>>> _replicate.OK for that?
>>
>> I'd definitely prefer they be consistent.
>> In fact, I've been arguing quietly for POST to _replicator to be
>> exactly the _replicate API and to deprecate the latter.
>> Isn't this possible?
>>
>
> What I mean to say is that I think it's absolute craziness to have two
> replication APIs.
> {persist: true} or something would have made more sense to me.
> ?block=true perhaps if we want the old one-shot, blocking. Persist on
> PUT or with {id: <replication_name>}, otherwise make it one-shot.
>
> I hate to be complaining like this after we've already released it
> with a different API, but I raised this a few times before 1.1 went
> out. I think two APIs for replication is ugly and confusing. A new
> CouchDB user has enough to digest without having to remember that
> _replicate is different from _replicator. I would have preferred we
> papered over the differences as described above and made _replicate
> use a database, rather than create a brand new path.
>
> </rant>
Re: create_target isn't working with the _replicator db
Posted by Randall Leeds <ra...@gmail.com>.
On Fri, Jul 22, 2011 at 11:26, Randall Leeds <ra...@gmail.com> wrote:
> On Fri, Jul 22, 2011 at 09:40, Benoit Chesneau <bc...@gmail.com> wrote:
>> On Fri, Jul 22, 2011 at 5:54 PM, Filipe David Manana
>> <fd...@apache.org> wrote:
>>> On Fri, Jul 22, 2011 at 8:43 AM, Benoit Chesneau <bc...@gmail.com> wrote:
>>>>
>>>> Yup, but I think that's a bug then. I shouldn't have to set any
>>>> userctx imo. If no admin has been set, every user is an admin except
>>>> if we change the default behavior and then it's not consistent.
>>>
>>> This was discussed sometime before the 1.1.0 release in the security list.
>>> And it's a principle of the least privileges by default (roles is an
>>> empty list).
>>>
>>>
>> I've no problem with that, it's even good. But other part of the API
>> aren't consistent then. While _replicator is ok, I can still do this
>> operation on _replicate. I propose to port the same behavior
>> _replicate.OK for that?
>
> I'd definitely prefer they be consistent.
> In fact, I've been arguing quietly for POST to _replicator to be
> exactly the _replicate API and to deprecate the latter.
> Isn't this possible?
>
What I mean to say is that I think it's absolute craziness to have two
replication APIs.
{persist: true} or something would have made more sense to me.
?block=true perhaps if we want the old one-shot, blocking. Persist on
PUT or with {id: <replication_name>}, otherwise make it one-shot.
I hate to be complaining like this after we've already released it
with a different API, but I raised this a few times before 1.1 went
out. I think two APIs for replication is ugly and confusing. A new
CouchDB user has enough to digest without having to remember that
_replicate is different from _replicator. I would have preferred we
papered over the differences as described above and made _replicate
use a database, rather than create a brand new path.
</rant>
Re: create_target isn't working with the _replicator db
Posted by Randall Leeds <ra...@gmail.com>.
On Fri, Jul 22, 2011 at 09:40, Benoit Chesneau <bc...@gmail.com> wrote:
> On Fri, Jul 22, 2011 at 5:54 PM, Filipe David Manana
> <fd...@apache.org> wrote:
>> On Fri, Jul 22, 2011 at 8:43 AM, Benoit Chesneau <bc...@gmail.com> wrote:
>>>
>>> Yup, but I think that's a bug then. I shouldn't have to set any
>>> userctx imo. If no admin has been set, every user is an admin except
>>> if we change the default behavior and then it's not consistent.
>>
>> This was discussed sometime before the 1.1.0 release in the security list.
>> And it's a principle of the least privileges by default (roles is an
>> empty list).
>>
>>
> I've no problem with that, it's even good. But other part of the API
> aren't consistent then. While _replicator is ok, I can still do this
> operation on _replicate. I propose to port the same behavior
> _replicate.OK for that?
I'd definitely prefer they be consistent.
In fact, I've been arguing quietly for POST to _replicator to be
exactly the _replicate API and to deprecate the latter.
Isn't this possible?
Re: create_target isn't working with the _replicator db
Posted by Benoit Chesneau <bc...@gmail.com>.
On Fri, Jul 22, 2011 at 5:54 PM, Filipe David Manana
<fd...@apache.org> wrote:
> On Fri, Jul 22, 2011 at 8:43 AM, Benoit Chesneau <bc...@gmail.com> wrote:
>>
>> Yup, but I think that's a bug then. I shouldn't have to set any
>> userctx imo. If no admin has been set, every user is an admin except
>> if we change the default behavior and then it's not consistent.
>
> This was discussed sometime before the 1.1.0 release in the security list.
> And it's a principle of the least privileges by default (roles is an
> empty list).
>
>
I've no problem with that, it's even good. But other part of the API
aren't consistent then. While _replicator is ok, I can still do this
operation on _replicate. I propose to port the same behavior
_replicate.OK for that?
- benoît
Re: create_target isn't working with the _replicator db
Posted by Filipe David Manana <fd...@apache.org>.
On Fri, Jul 22, 2011 at 8:43 AM, Benoit Chesneau <bc...@gmail.com> wrote:
>
> Yup, but I think that's a bug then. I shouldn't have to set any
> userctx imo. If no admin has been set, every user is an admin except
> if we change the default behavior and then it's not consistent.
This was discussed sometime before the 1.1.0 release in the security list.
And it's a principle of the least privileges by default (roles is an
empty list).
>
> - benoit
>
> - benoît
>
--
Filipe David Manana,
fdmanana@gmail.com, fdmanana@apache.org
"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men."
Re: create_target isn't working with the _replicator db
Posted by Benoit Chesneau <bc...@gmail.com>.
On Fri, Jul 22, 2011 at 4:59 PM, kowsik <ko...@gmail.com> wrote:
> If you have credentials and roles defined on the target DB, you need
> to set the the user_ctx in the _replicator doc. Something like this: {
> source ..., user_ctx: { roles: [ "admin" ] } }.
>
> K.
> ---
> http://blitz.io
> @pcapr
>
Yup, but I think that's a bug then. I shouldn't have to set any
userctx imo. If no admin has been set, every user is an admin except
if we change the default behavior and then it's not consistent.
- benoit
- benoît
Re: create_target isn't working with the _replicator db
Posted by kowsik <ko...@gmail.com>.
If you have credentials and roles defined on the target DB, you need
to set the the user_ctx in the _replicator doc. Something like this: {
source ..., user_ctx: { roles: [ "admin" ] } }.
K.
---
http://blitz.io
@pcapr
On Fri, Jul 22, 2011 at 4:56 AM, Benoit Chesneau <bc...@gmail.com> wrote:
> Hi all,
>
> While testing the _replicator db I encounter an error when trying to
> create the target db . Before opening a ticket I wanted to make sure
> this wasn't expected or if it"s an error.
>
> The error:
>
> $ curl -XPUT -H"Content-Type: application/json" localhost:5984/a
> {"ok":true}
> $ curl -XPUT -d'{}' localhost:5984/a/doca
> {"ok":true,"id":"doca","rev":"1-967a00dff5e02add41819138abb3284d"}
> curl -XPUT -d'{}' localhost:5984/a/docb
> {"ok":true,"id":"docb","rev":"1-967a00dff5e02add41819138abb3284d"}
> $ curl -XPOST -d'{
> "source": "a",
> "target": "b",
> "create_target": true
> }' -H"Content-Type: application/json" localhost:5984/_replicator
> {"ok":true,"id":"2f6df84e4a02978cf80424bce0000f1c","rev":"1-4b8c482da7ce243353493fb87e766428"}
> enki:~ benoitc$ curl -XGET
> localhost:5984/_replicator/2f6df84e4a02978cf80424bce0000f1c
> {"_id":"2f6df84e4a02978cf80424bce0000f1c","_rev":"2-b557bd698ecebc359bd5f51b2691a2fd","source":"a","target":"b","create_target":true,"_replication_state":"error","_replication_state_time":"2011-07-22T13:49:21+02:00","_replication_id":"01e205795e3f5ad9968f51e6e1e61335"}
> enki:~ benoitc$
>
>
> Error:
>
> <<"unauthorized to access database b">>}.
> Retrying in 10 seconds
> [error] [<0.867.0>] {error_report,<0.30.0>,
> {<0.867.0>,crash_report,
> [[{initial_call,{couch_rep,init,['Argument__1']}},
> {pid,<0.867.0>},
> {registered_name,[]},
> {error_info,
> {exit,
> {unauthorized,<<"b">>},
> [{gen_server,init_it,6},
> {proc_lib,init_p_do_apply,3}]}},
> {ancestors,
> [couch_rep_sup,couch_primary_services,
> couch_server_sup,<0.31.0>]},
> {messages,[]},
> {links,[<0.81.0>]},
> {dictionary,[]},
> {trap_exit,true},
> {status,running},
> {heap_size,610},
> {stack_size,24},
> {reductions,199}],
> []]}}
>
>
> Let me know.
>
> - benoît
>