From dev-return-41170-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Sat Jul 14 23:03:43 2012
Return-Path:
X-Original-To: apmail-directory-dev-archive@www.apache.org
Delivered-To: apmail-directory-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by minotaur.apache.org (Postfix) with SMTP id 0D0FCD2D4
for ; Sat, 14 Jul 2012 23:03:43 +0000 (UTC)
Received: (qmail 11085 invoked by uid 500); 14 Jul 2012 23:03:42 -0000
Delivered-To: apmail-directory-dev-archive@directory.apache.org
Received: (qmail 11036 invoked by uid 500); 14 Jul 2012 23:03:42 -0000
Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: "Apache Directory Developers List"
Delivered-To: mailing list dev@directory.apache.org
Received: (qmail 11029 invoked by uid 99); 14 Jul 2012 23:03:42 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 14 Jul 2012 23:03:42 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=5.0
tests=RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of elecharny@gmail.com designates 74.125.82.44 as permitted sender)
Received: from [74.125.82.44] (HELO mail-wg0-f44.google.com) (74.125.82.44)
by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 14 Jul 2012 23:03:36 +0000
Received: by wgbdr13 with SMTP id dr13so4186316wgb.1
for ; Sat, 14 Jul 2012 16:03:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=message-id:date:from:reply-to:user-agent:mime-version:to:subject
:references:in-reply-to:content-type:content-transfer-encoding;
bh=4VUHc1AfQ4Yjn/VFiH8vVz+aAPJ5N6TnLzpCfNwLnE4=;
b=AY3ObYkLV9k5adN9bWaHqqeciHqRnVcWAuWrw1rG2KDn+SBVz6q+pexkmaXUNGBZCQ
OmeWXb/ghN5z8XBrodnvGtYaLELedpfC5DAfTuyhfrWMyRGrTtTMOT6BAF3aKRICFns9
HoKJFlzDc436iC+LuchsoACLeVv7laQxU2pZcYEf7TtVSGfW6XFS3/HX+vQQepGaZBZU
zrnVS9cB2Hzss+VFc0rp8XMHnVcZwgqS7ix3GpIJZnIIRWsUoFAZn6pfbnkfRtrBKOLx
P2+BAjvb/28tMM4bitLPnXSM60LAxxXfTCAQ1w4H1ChS5vNqx1mk5uS5NcjvxDS/pw1o
PBgw==
Received: by 10.180.83.105 with SMTP id p9mr7474277wiy.12.1342306994819;
Sat, 14 Jul 2012 16:03:14 -0700 (PDT)
Received: from host-001.darty (170.102-227-89.dsl.completel.net. [89.227.102.170])
by mx.google.com with ESMTPS id fr4sm18036776wib.8.2012.07.14.16.03.14
(version=SSLv3 cipher=OTHER);
Sat, 14 Jul 2012 16:03:14 -0700 (PDT)
Message-ID: <5001FAB5.5090302@gmail.com>
Date: Sun, 15 Jul 2012 01:03:17 +0200
From: =?UTF-8?B?RW1tYW51ZWwgTMOpY2hhcm55?=
Reply-To: elecharny@apache.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: Apache Directory Developers List
Subject: Re: Question about Replication of Config Partition and Schema Partition
References:
In-Reply-To:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Checked: Checked by ClamAV on apache.org
Le 7/14/12 9:13 PM, Göktürk Gezer a écrit :
> Hi Devs,
>
> Here i share my findings on LDAP replication in terms of OSGI layer.
>
> - First of all i found nothing related to replicating configuration of
> LDAP Server on any RFC related to replication. So replicating configuration
> is only ApacheDS's concern because it keeps its configuration as DIT data.
Absolutely. RFC 4533 says nothing about how to implement replication nor
how to manage the replication configuration.
> I don't know OpenLDAP yet but don't think its the same, right?
It's clearly different, but not that much.
> And i
> believe we shouldn't let administrators to initiate replication under
> ou=config base. It is not standart and it is not wise.
The ida we had was to manage configuration using an Administrative Area.
This is not yet implemented though, so we ended up with managing
replication under ou=config atm.
> Simply replicating
> configuration will first break the replication aggreement between servers
> anyway ! You should set some filters on config partition entries to whether
> replicate them, but this would be improper in terms of design IMO.
Whe you setup replication, you tell the local server with which remote
server you want to replicate. Obviously, you don't want to replicate
such localized information. Now, you can still consider that we share a
global configuration between all the servers, in which you just name
each server, with the assoictaed informations (IP, port, etc), and now
you can setup a replication mechanism in which you express each
configration using thoses names. For instance, if you have 3 servers A,
B and C, you may have the shared configuration where A -r> B, B-r> C,
B-r>A. This configuration can be replicated as is on , B and C, because
each server will now which replication is of interest to itself.
> - But i'm not against on replicating configuration completely. Some one
> would want to simply clone the server in its entirety. ( This is not
> touched by RFC as i see ) Because our OSGI distribution is Karaf based, we
> can use Karaf Cellar here. Cellar is used to keep multiple Karaf instances
> synched in terms of Bundles,Features, and Configuration.(We can't use its
> configuration aspects because we're keeping our component configurations in
> ApacheDS itself). I quickly looked through its functionality and code. It's
> incomplete but promising. Most importantly it provides API to initiate
> Karaf Instance replication.(Again not complete). So when replication system
> is revisited we can make use of Cellar.
> - I looked at Apache ZooKeeeper a bit, and we should definetely leverage
> it in our LDAP replication system. It is simply a distributed data and
> notification system for clusters. It has strength in node management in
> clusters and good for implementing infrastructure related parts of
> replication system.
>
> So i see no threat to OSGI from LDAP Replication. However i believe
> ou=config should be excluded from replication in any scenario.
Not sure.
> I believe if
> we're gonna provide some way to replicate some ApacheDS instance's runtime
> layout, we should not do it by LDAP Replication. Because :
>
> - It is not just config partition manages the server anymore.
> - We just can't be sure that 2 server having the same configuration will
> have same runtime behavior, because they might have different composition
> of bundles.
> - Replicating ou=config is hell of a job because of site specific
> configuration parameters.
Unless the server can detect which configuration applies to itself.
Bottom line, there are a very litte set of information a server needs to
keep local :
- its IP address
- its port
- its name
The name will be used to identify the configuration that applies to the
local server.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com