Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Message-ID: <4D24E042.7030405@apache.org>
Date: Wed, 05 Jan 2011 22:18:58 +0100
From: =?ISO-8859-1?Q?Emmanuel_L=E9charny?= <elecharny@apache.org>
Reply-To: elecharny@apache.org
Organization: The Apache Software Foundation
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [DISCUSS] [Release Scheme] Contract/Policy with users for
 releases
References: <AANLkTi=FHepcTbRFxwEQYzOTXmn3KqaosG826+m0pZMO@mail.gmail.com>
	<4D24B4AC.6080604@gmail.com>
	<AANLkTingdgnmtfa-3UrYt9boeksKA2BoZAnM_rx6=evK@mail.gmail.com>
	<4D24CF43.90805@apache.org>
 <AANLkTinztyODocid1kRBUnfb8GrBu_jterdwZ7EtGKDz@mail.gmail.com>
In-Reply-To: <AANLkTinztyODocid1kRBUnfb8GrBu_jterdwZ7EtGKDz@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

On 1/5/11 9:49 PM, Alex Karasulu wrote:
> On Wed, Jan 5, 2011 at 10:06 PM, Emmanuel L�charny<elecharny@apache.org>wrote:
>
>> On 1/5/11 8:17 PM, Alex Karasulu wrote:
>>
>>> On Wed, Jan 5, 2011 at 8:13 PM, Emmanuel Lecharny<elecharny@gmail.com
>>>> wrote:
>>>   On 1/5/11 6:49 PM, Alex Karasulu wrote:
>>>> So when considering compatibility we have to consider several things
>>>>> besides
>>>>> just APIs and SPIs:
>>>>>
>>>>>    o Database Format
>>>>>    o Schema
>>>>>    o Replication Mechanism
>>>>>    o Configuration
>>>>>    o API Compatibility
>>>>>    o Plugins - We have pseudo plugins like Partitions, Interceptors and
>>>>> Handlers that users can alter which involve SPIs.
>>>>>
>>>>>   I would get the Database Format and Configuration out of the equation.
>>>> It's
>>>> up to us to provide tools to migrate from one format to the other. Don't
>>>> get
>>>> me wrong : when I say that configuration is out of the equation, I mean
>>>> that
>>>> the configuration can change, not its format (ie switching from XML to
>>>> DIT
>>>> is possible between to major releases, not between two minor releases).
>>>>
>>>>
>>>>   Will this be transparent to the user? Meaning can he just upgrade the
>>> software and the migration will occur without any change in their
>>> workflow,
>>> or anything noticeable in performance, wait time on startup? More
>>> specifically:
>>>
>>> (1) Does the user have to run a tool to migrate from one version to the
>>> next
>>> ?
>>>
>> Definitively, yes.
>>
>>
> This is a bit worrisome to me but I cannot figure out why yet. Something in
> my gut that I have not translated into real consequences yet.
>
> I can see advantages with such a tool which allows us to change these
> formats and configurations. But the disadvantage is the one off of having to
> figure out if you need the tool with every minor or micro release. It's yet
> another one off and the tool make take a day to run depending on how big the
> DIB is.

We are not likely to change those DB formats often. We did it 3 times in 
6 years, and it was for some major refactoring, I can't foresee any 
small modification that could be needed soon.

However, I do think that at some point, this might be necessary to ofter 
such a tool. It's too easy to rely on our user to get their data 
exported and reimported using a LDIF file, as it has some consequence : 
the operational attributes will be modified.

> However with modularity and OSGi these points become less problematic.
>
> If this is set as the policy then this tool must always be provided. Those
> who push this as the way then need to be held responsible for providing the
> tool when needed. That sort of goes against the community dynamic: it's
> going to be a must do for those accepting the policy.
Same opinion here.
> So for those who want it, it should be provided by them on demand before any
> release takes place. That's kind of harsh.
>
> Instead if we respect the DB format and just release with the right
> versioning schemes then we should be OK. If compatibility breaks then a
> major release can be done and tools can still be provided to migrate
> optionally without requirement.
>
> See my point here?
yes. But again, such a modification is not likely to happen, is not part 
of the contract, and can be manage if we provide a migration tool. It's 
quite a common practice in the industry, and should not be a burden. It 
should even not require a major release, IMO.
>   (2) If a user has 100 Million entries and there's a migration operation
>>> running with this take say a few hours to start up the server?
>>>
>> This should be a low level tool, so it should act on the Backend interface
>> level
>>
>>
> Yeah but it can still take days depending on the DB size but should not be
> an issue with 90% of our users.
The day we have a user with 100 million entries, trust me, we will have 
other issues than just dealing with the migration of its database :)


-- 
Regards,
Cordialement,
Emmanuel L�charny
www.iktek.com