You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2007/01/18 12:16:57 UTC
[1.0.0 -> 1.0.1 Migration]
Hi,
we have had a discussion recently about the path we must follow when
migrating from 1.0.0 to 1.0.1 (when this version will be released). Some
tricky points have been raised :
1) Last changes to Attribute(s) have mad impossible to reuse the data stored
in a 1.0.0 ADS. This is my fault, and I think the best thing would be to
revert to the previous names for those classes (it was
LockableAttribute(s)Impl, renamed to Attribute(s)Impl). Of course, I will
also get rid of the added field in Attributes, which is not really critical
(it was added to be compliant with the JNDI interface, to support case
sensitive attributes name, and this is obviously a nonsense in LDAP
context). Last, not least, as those data are serialized, I must be sure that
the serialVersionUID are the same for those serializable classes. This
should do the trick. Did I missed anything ?
2) We have some user who emitted some concern regarding their existing
configuration and data. We should insure that both server.xml and
log4j.properties are not overwritten by the new one. This also include
schemas, and of course, data. I'm pretty confident that we could have a new
installer handling such burdens, but what we need is a volunteer to modify
it and tro check that it works well... Shemas migration could be trickier...
Any volunteer ?
3) Another idea would be to first export all the dataz from the current
1.0.0 install, and reimport them into the new 1.0.1 install. Guess how long
it could take with millions of entries ... However, do we have any user with
more than a few thousands entries ?
4) At this point, it would be good to know about real users, to be sure that
they are not impacted during migration process, and that we can dedicate
some time to support them. Even better if some of the courageous ('First
Mover Advantage') users can be alpha-testers ... wdyt?
5) It would be really great if we can coordinate a release with a newer
version of the site and of the doco. I must admit that Doco has been really
improved since 1.0.0, but the site still suX (tm). Any volunteer?
We are now not so far from this 1.0.1, with some nasty bugs remaining
(referrals, collective attributes, and a few others), so the migration
process should be addressed as soon as possible.
Any advice/idea/criticism/mockery welcomed (well, mockery, not so sure ;)
--
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [1.0.0 -> 1.0.1 Migration]
Posted by Trustin Lee <tr...@gmail.com>.
We might need an eternally unchanging way to specify the version of the
partition database so we can detect version conflict and perform automatic
data migration.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: [1.0.0 -> 1.0.1 Migration]
Posted by Trustin Lee <tr...@gmail.com>.
Ole,
Could you remove the following vcard attachment text when you reply? :)
Trustin
On 1/19/07, Ole Ersoy <ol...@yahoo.com> wrote:
>
> --- Alex Karasulu <ak...@apache.org> wrote:
>
> >
> >
> > Emmanuel Lecharny wrote:
> > >
> > > Hi,
> > >
> > > we have had a discussion recently about the path
> > we must follow when
> > > migrating from 1.0.0 to 1.0.1 (when this version
> > will be released). Some
> > > tricky points have been raised :
> > >
> > > 1) Last changes to Attribute(s) have mad
> > impossible to reuse the data
> > > stored in a 1.0.0 ADS. This is my fault, and I
> > think the best thing
> > > would be to revert to the previous names for those
> > classes (it was
> > > LockableAttribute(s)Impl, renamed to
> > Attribute(s)Impl). Of course, I
> > > will also get rid of the added field in
> > Attributes, which is not really
> > > critical (it was added to be compliant with the
> > JNDI interface, to
> > > support case sensitive attributes name, and this
> > is obviously a nonsense
> > > in LDAP context). Last, not least, as those data
> > are serialized, I must
> > > be sure that the serialVersionUID are the same for
> > those serializable
> > > classes. This should do the trick. Did I missed
> > anything ?
> >
> > No that sounds good E.
> >
> > > 2) We have some user who emitted some concern
> > regarding their existing
> > > configuration and data. We should insure that both
> > server.xml and
> > > log4j.properties are not overwritten by the new
> > one. This also include
> > > schemas, and of course, data. I'm pretty confident
> > that we could have a
> > > new installer handling such burdens, but what we
> > need is a volunteer to
> > > modify it and tro check that it works well...
> > Shemas migration could be
> > > trickier... Any volunteer ?
> >
> > This will not be easy to do. Like I said for
> > upgrades we should ask
> > people to use LDAP studio where we can replace jars
> > only and massage the
> > store.
> >
> > > 3) Another idea would be to first export all the
> > dataz from the current
> > > 1.0.0 install, and reimport them into the new
> > 1.0.1 install. Guess how
> > > long it could take with millions of entries ...
> > However, do we have any
> > > user with more than a few thousands entries ?
> >
> > Right this is in general a lousy thing to have to
> > do. 5 million entry
> > additions takes a few hours (~4). It will be
> > unacceptable in most large
> > directories and companies.
> >
> > > 4) At this point, it would be good to know about
> > real users, to be sure
> > > that they are not impacted during migration
> > process, and that we can
> > > dedicate some time to support them. Even better if
> > some of the
> > > courageous ('First Mover Advantage') users can be
> > alpha-testers ... wdyt?
> >
> > Yes that would be nice.
> >
> > > 5) It would be really great if we can coordinate a
> > release with a newer
> > > version of the site and of the doco. I must admit
> > that Doco has been
> > > really improved since 1.0.0, but the site still
> > suX (tm). Any volunteer?
> >
> > Yeah this is really critical for us. Why have we
> > not switched yet to
> > using confluence instead of the maven site?
> >
> > Alex
> >
> > > begin:vcard
> > fn:Alex Karasulu
> > n:Karasulu;Alex
> > org:Apache Software Foundation;Apache Directory
> > adr:;;1005 N. Marsh Wind Way;Ponte Vedra
> > ;FL;32082;USA
> > email;internet:akarasulu@apache.org
> > title:Member, V.P.
> > tel;work:(904) 791-2766
> > tel;fax:(904) 808-4789
> > tel;home:(904) 808-4789
> > tel;cell:(904) 315-4901
> > note;quoted-printable:AIM: alexokarasulu=0D=0A=
> > MSN: aok123@bellsouth.net=0D=0A=
> > Yahoo!: alexkarasulu=0D=0A=
> > IRC: aok=0D=0A=
> > PGP ID: 1024D/4E1370F8 BBCC E8D8 8756 2D51 C3D4
> > 014A 3662 F96F 4E13 70F8=0D=0A=
> >
> > x-mozilla-html:FALSE
> > url:http://people.apache.org/~akarasulu
> > version:2.1
> > end:vcard
> >
> >
>
>
>
>
>
> ____________________________________________________________________________________
> Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it
> now.
>
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: [1.0.0 -> 1.0.1 Migration]
Posted by Ole Ersoy <ol...@yahoo.com>.
I'm partially volunteering for the site stuff,
in the context of some of the stuff I had to say
regarding documentation earlier.
We may have an immidiate need to get information out
there (Allthough I would say that that immidiate need
should be driven by the need to make user support and
collaboration more efficient - so that if we are
seeing that specific items are slowing us down, then
we should push items that we can say "look here"
with).
What I mean by partially volunteering that is that I
will be creating a process and system around
documenting in microformats, so that precanned
templates can be used around defined documentation
tasks, showing how to use it and suggesting that we
use it.
This way we can document in the microformat we prefer,
specify rules for pulling the document into a larger
context, and were done.
My first thought of a larger context is something like
an Eclipse Help System.
It can be used right out of the box standalone.
However I intend to rebuild the Eclipse help so that
it becomes more of a collaboration portal, where users
can work in Eclipse on their desktop, but their
versioned changes in through the portal for
collaboration.
So I'm mentioning this because I personally am way
more effective documenting in a local desktop eclipse
context. I'm guessing others feel the same way.
My big concern is once something gets onto Confluence,
how is it going to get reused and updated efficiently.
My personal worka around for that is to just use APT,
put the stuff in my little cookbook microformat, and
point people to that document when they have
questions.
This way I now that later on I can pull my microformat
into a nice html transformation, and assemble it into
a larger context.
This way the works looks professional, gets indexed,
and requires minimum maintenance when it comes to
reformatting, restructuring, restyling, etc.
So I'm just floating this so that we are conscious of
it, so that those that are interested can prepare
their materials with this type of approach in mind for
later.
Start with the end in mind and work backwards.
Cheers,
- Ole
--- Alex Karasulu <ak...@apache.org> wrote:
>
>
> Emmanuel Lecharny wrote:
> >
> > Hi,
> >
> > we have had a discussion recently about the path
> we must follow when
> > migrating from 1.0.0 to 1.0.1 (when this version
> will be released). Some
> > tricky points have been raised :
> >
> > 1) Last changes to Attribute(s) have mad
> impossible to reuse the data
> > stored in a 1.0.0 ADS. This is my fault, and I
> think the best thing
> > would be to revert to the previous names for those
> classes (it was
> > LockableAttribute(s)Impl, renamed to
> Attribute(s)Impl). Of course, I
> > will also get rid of the added field in
> Attributes, which is not really
> > critical (it was added to be compliant with the
> JNDI interface, to
> > support case sensitive attributes name, and this
> is obviously a nonsense
> > in LDAP context). Last, not least, as those data
> are serialized, I must
> > be sure that the serialVersionUID are the same for
> those serializable
> > classes. This should do the trick. Did I missed
> anything ?
>
> No that sounds good E.
>
> > 2) We have some user who emitted some concern
> regarding their existing
> > configuration and data. We should insure that both
> server.xml and
> > log4j.properties are not overwritten by the new
> one. This also include
> > schemas, and of course, data. I'm pretty confident
> that we could have a
> > new installer handling such burdens, but what we
> need is a volunteer to
> > modify it and tro check that it works well...
> Shemas migration could be
> > trickier... Any volunteer ?
>
> This will not be easy to do. Like I said for
> upgrades we should ask
> people to use LDAP studio where we can replace jars
> only and massage the
> store.
>
> > 3) Another idea would be to first export all the
> dataz from the current
> > 1.0.0 install, and reimport them into the new
> 1.0.1 install. Guess how
> > long it could take with millions of entries ...
> However, do we have any
> > user with more than a few thousands entries ?
>
> Right this is in general a lousy thing to have to
> do. 5 million entry
> additions takes a few hours (~4). It will be
> unacceptable in most large
> directories and companies.
>
> > 4) At this point, it would be good to know about
> real users, to be sure
> > that they are not impacted during migration
> process, and that we can
> > dedicate some time to support them. Even better if
> some of the
> > courageous ('First Mover Advantage') users can be
> alpha-testers ... wdyt?
>
> Yes that would be nice.
>
> > 5) It would be really great if we can coordinate a
> release with a newer
> > version of the site and of the doco. I must admit
> that Doco has been
> > really improved since 1.0.0, but the site still
> suX (tm). Any volunteer?
>
> Yeah this is really critical for us. Why have we
> not switched yet to
> using confluence instead of the maven site?
>
> Alex
>
> > begin:vcard
> fn:Alex Karasulu
> n:Karasulu;Alex
> org:Apache Software Foundation;Apache Directory
> adr:;;1005 N. Marsh Wind Way;Ponte Vedra
> ;FL;32082;USA
> email;internet:akarasulu@apache.org
> title:Member, V.P.
> tel;work:(904) 791-2766
> tel;fax:(904) 808-4789
> tel;home:(904) 808-4789
> tel;cell:(904) 315-4901
> note;quoted-printable:AIM: alexokarasulu=0D=0A=
> MSN: aok123@bellsouth.net=0D=0A=
> Yahoo!: alexkarasulu=0D=0A=
> IRC: aok=0D=0A=
> PGP ID: 1024D/4E1370F8 BBCC E8D8 8756 2D51 C3D4
> 014A 3662 F96F 4E13 70F8=0D=0A=
>
> x-mozilla-html:FALSE
> url:http://people.apache.org/~akarasulu
> version:2.1
> end:vcard
>
>
____________________________________________________________________________________
Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now.
Re: [1.0.0 -> 1.0.1 Migration]
Posted by Alex Karasulu <ak...@apache.org>.
Emmanuel Lecharny wrote:
>
> Hi,
>
> we have had a discussion recently about the path we must follow when
> migrating from 1.0.0 to 1.0.1 (when this version will be released). Some
> tricky points have been raised :
>
> 1) Last changes to Attribute(s) have mad impossible to reuse the data
> stored in a 1.0.0 ADS. This is my fault, and I think the best thing
> would be to revert to the previous names for those classes (it was
> LockableAttribute(s)Impl, renamed to Attribute(s)Impl). Of course, I
> will also get rid of the added field in Attributes, which is not really
> critical (it was added to be compliant with the JNDI interface, to
> support case sensitive attributes name, and this is obviously a nonsense
> in LDAP context). Last, not least, as those data are serialized, I must
> be sure that the serialVersionUID are the same for those serializable
> classes. This should do the trick. Did I missed anything ?
No that sounds good E.
> 2) We have some user who emitted some concern regarding their existing
> configuration and data. We should insure that both server.xml and
> log4j.properties are not overwritten by the new one. This also include
> schemas, and of course, data. I'm pretty confident that we could have a
> new installer handling such burdens, but what we need is a volunteer to
> modify it and tro check that it works well... Shemas migration could be
> trickier... Any volunteer ?
This will not be easy to do. Like I said for upgrades we should ask
people to use LDAP studio where we can replace jars only and massage the
store.
> 3) Another idea would be to first export all the dataz from the current
> 1.0.0 install, and reimport them into the new 1.0.1 install. Guess how
> long it could take with millions of entries ... However, do we have any
> user with more than a few thousands entries ?
Right this is in general a lousy thing to have to do. 5 million entry
additions takes a few hours (~4). It will be unacceptable in most large
directories and companies.
> 4) At this point, it would be good to know about real users, to be sure
> that they are not impacted during migration process, and that we can
> dedicate some time to support them. Even better if some of the
> courageous ('First Mover Advantage') users can be alpha-testers ... wdyt?
Yes that would be nice.
> 5) It would be really great if we can coordinate a release with a newer
> version of the site and of the doco. I must admit that Doco has been
> really improved since 1.0.0, but the site still suX (tm). Any volunteer?
Yeah this is really critical for us. Why have we not switched yet to
using confluence instead of the maven site?
Alex