Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 76262 invoked from network); 5 Jan 2011 20:49:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 5 Jan 2011 20:49:54 -0000 Received: (qmail 57344 invoked by uid 500); 5 Jan 2011 20:49:54 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 57302 invoked by uid 500); 5 Jan 2011 20:49:54 -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 57295 invoked by uid 99); 5 Jan 2011 20:49:53 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Jan 2011 20:49:53 +0000 X-ASF-Spam-Status: No, hits=1.5 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of akarasulu@gmail.com designates 209.85.216.171 as permitted sender) Received: from [209.85.216.171] (HELO mail-qy0-f171.google.com) (209.85.216.171) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Jan 2011 20:49:47 +0000 Received: by qyk32 with SMTP id 32so16893530qyk.16 for ; Wed, 05 Jan 2011 12:49:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=nfERIZcxPVXWs+tx6rAWu8Il5hVEfa8hBUOPCTQeVqA=; b=kzFtxfOuBt6zDwer3PhooCsYgaig5XtclqtPNscLRH51B0MUB2ogiUrGXNBbj6OfcJ BBDDD7evGt/8y6/98db24g2Kl1aQAjlkjF0U51A7WxRLY8Y41uSb53M+k7OJ1EPmHqzI D/1HH1NbIdWLcJxcLO1RGu9+YrqtVc/jpKC/Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=uIUMdWcMDN5A6PKsZgC/KVEDjCzOocQqQr1NLX4rHCcq5z6N0yihscXbxiLyU+du+p acZunsR5zt8L4wFT1xeMMQPcUkwNl1GY8cA73sdMSR0SV0ySTT4xTWecM3l88u7VLNTu tnL68WC/fY7EH6eBerzUni9U9T60P8MmQ4AKE= MIME-Version: 1.0 Received: by 10.229.182.67 with SMTP id cb3mr20816203qcb.48.1294260566266; Wed, 05 Jan 2011 12:49:26 -0800 (PST) Sender: akarasulu@gmail.com Received: by 10.229.63.23 with HTTP; Wed, 5 Jan 2011 12:49:26 -0800 (PST) In-Reply-To: <4D24CF43.90805@apache.org> References: <4D24B4AC.6080604@gmail.com> <4D24CF43.90805@apache.org> Date: Wed, 5 Jan 2011 22:49:26 +0200 X-Google-Sender-Auth: SSwczbxlhVMko_WWQmn-jJKH7OE Message-ID: Subject: Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases From: Alex Karasulu To: Apache Directory Developers List , elecharny@apache.org Content-Type: multipart/alternative; boundary=00163630ed9b4c933104991f8568 X-Virus-Checked: Checked by ClamAV on apache.org --00163630ed9b4c933104991f8568 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jan 5, 2011 at 10:06 PM, Emmanuel L=E9charny = wrote: > On 1/5/11 8:17 PM, Alex Karasulu wrote: > >> On Wed, Jan 5, 2011 at 8:13 PM, Emmanuel Lecharny> >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 t= o 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 th= e DIB is. 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. So for those who want it, it should be provided by them on demand before an= y 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? (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 interfac= e > level > > Yeah but it can still take days depending on the DB size but should not be an issue with 90% of our users. --=20 Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu --00163630ed9b4c933104991f8568 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 5, 2011 at 10:06 PM, Emmanuel L=E9ch= arny <elecharn= y@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:

=A0 o Database Format
=A0 o Schema
=A0 o Replication Mechanism
=A0 o Configuration
=A0 o API Compatibility
=A0 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&#= 39;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 tha= t
the configuration can change, not its format (ie switching from XML to DIT<= br> 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 nex= t
?

Definitively, yes.


<= div>This is a bit worrisome to me but I cannot figure out why yet. Somethin= g in my gut that I have not translated into real consequences yet.

I can see advantages with such a tool which allows us t= o 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 d= epending on how big the DIB is.

However with modularity and OSGi these points become le= ss 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 go= es against the community dynamic: it's going to be a must do for those = accepting the policy. =A0

So for those who want it, it should be provided by them= on demand before any release takes place. That's kind of harsh.
<= div>
Instead if we respect the DB format and just release wit= h the right versioning schemes then we should be OK. If compatibility break= s then a major release can be done and tools can still be provided to migra= te optionally without requirement.

See my point here?

(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.

--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory S= erver :: http://directory.apache.or= g
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu
--00163630ed9b4c933104991f8568--