About Partition, AdministrativePoints and the whole universe...

[Emmanuel Lecharny <el...@gmail.com>]

  Hi guys,

as I'm slowly refactoring the data structure we use to manage 
NamingContexts, I just realized that we may have a way to handle 
encapsulated partitions...

One of the Graal we were chasing was the possibility to define 
encapsulated partitions. Let me give you an example :

if we define dc=example,dc=org as a naming context, then we have to 
define a dedicated partition (be it JDBM, LDIF, HBase, in-memory, 
SQL-based). That's good, but if we want to define a sub-partition for, 
say ou=apache,dc=example,dc=org, we currenty can't. That means this 
ou=apache... thing will be stored in the same backend than the partition 
it's defined into (dc=example,dc=org).

We also have some issue currently, like DIRSERVER_1517 : we can't move 
an entry from one partition to another one (this is a bug)

Ok, how can we manage encapsulated partitions ? Here is one idea I had :
- what about leveraging the X500 administrative model ? We currently can 
manage AccessControl, CollectoveAttribute, SubSchema (even if we don't 
support it atm), TriggerExecution, so why not add a new role, the 
PartitionLayout role which defines a new partition starting at the 
defined Administrativepoint ?

So a partition is a role, defining the storage, and all of it's 
characteristics, using a subentry  for that. Of course, a PL AP won't be 
an Inner AP. We won't allow any subtree specification for this subentry, 
and the base will always be the AP.  It should work.

Now, a few more thoughts : the current partitions configuration is 
stored into the ou=config partition (a LDIF partition). How can we 
continue using this config partition in sync with the subentries ? What 
if subentries are just aliases pointing to the config partition ? As we 
have to load all the subentries at startup, it would be far easier to do 
that if they are stored into the config partition.

Ok, those are just ideas, but I think it can fit well with the big picture.

feel free to comment !

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

Re: About Partition, AdministrativePoints and the whole universe...

[Alex Karasulu <ak...@apache.org>]

On Mon, Aug 2, 2010 at 5:33 PM, Emmanuel Lecharny <el...@gmail.com>wrote:

>  Hi guys,
>
> as I'm slowly refactoring the data structure we use to manage
> NamingContexts, I just realized that we may have a way to handle
> encapsulated partitions...
>
> One of the Graal we were chasing was the possibility to define encapsulated
> partitions. Let me give you an example :
>
> if we define dc=example,dc=org as a naming context, then we have to define
> a dedicated partition (be it JDBM, LDIF, HBase, in-memory, SQL-based).
> That's good, but if we want to define a sub-partition for, say
> ou=apache,dc=example,dc=org, we currenty can't. That means this ou=apache...
> thing will be stored in the same backend than the partition it's defined
> into (dc=example,dc=org).
>
> We also have some issue currently, like DIRSERVER_1517 : we can't move an
> entry from one partition to another one (this is a bug)
>
>
Yep that's certainly a bug.


> Ok, how can we manage encapsulated partitions ? Here is one idea I had :
> - what about leveraging the X500 administrative model ? We currently can
> manage AccessControl, CollectoveAttribute, SubSchema (even if we don't
> support it atm), TriggerExecution, so why not add a new role, the
> PartitionLayout role which defines a new partition starting at the defined
> Administrativepoint ?
>
> So a partition is a role, defining the storage, and all of it's
> characteristics, using a subentry  for that. Of course, a PL AP won't be an
> Inner AP. We won't allow any subtree specification for this subentry, and
> the base will always be the AP.  It should work.
>
>
Very interesting idea - I never thought or imagined using the X.500 admin
model for this. However don't we need inner AP's if the point in the first
place is to have nesting and the partition is rooted at the AP?


> Now, a few more thoughts : the current partitions configuration is stored
> into the ou=config partition (a LDIF partition). How can we continue using
> this config partition in sync with the subentries ? What if subentries are
> just aliases pointing to the config partition ? As we have to load all the
> subentries at startup, it would be far easier to do that if they are stored
> into the config partition.
>
>
Yes this is a great idea. I agree with this approach at first sight. It
would be much easier and faster to pull out the subentries from the
configuration area but this creates some oddities though on second thought.
We basically have subentries located under the configuration area but they
are not subordinate to APs.  Technically subentries should subordinate to
APs according to implicit ditStructureRules built into the protocol.


> Ok, those are just ideas, but I think it can fit well with the big picture.
>
> feel free to comment !
>
>
Very interesting thought but I think we need to think about this a bit more.
I have also some ideas on implementing nested partitions and  a new
organization in the backend to partitions which will facilitate handling
entry relocations across partitions as well as cross partition aliases. More
to follow in the coming days.

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

Re: About Partition, AdministrativePoints and the whole universe...

[Emmanuel Lecharny <el...@gmail.com>]

  On 8/2/10 8:27 PM, Kiran Ayyagari wrote:
> On Mon, Aug 2, 2010 at 8:03 PM, Emmanuel Lecharny<el...@gmail.com>  wrote:
>>   Hi guys,
>>
>> as I'm slowly refactoring the data structure we use to manage
>> NamingContexts, I just realized that we may have a way to handle
>> encapsulated partitions...
>>
>> One of the Graal we were chasing was the possibility to define encapsulated
>> partitions. Let me give you an example :
>>
>> if we define dc=example,dc=org as a naming context, then we have to define a
>> dedicated partition (be it JDBM, LDIF, HBase, in-memory, SQL-based). That's
>> good, but if we want to define a sub-partition for, say
>> ou=apache,dc=example,dc=org, we currenty can't. That means this ou=apache...
>> thing will be stored in the same backend than the partition it's defined
>> into (dc=example,dc=org).
> so this kind of partition won't be shown as a naming context anymore,
> its base is always dc=example,dc=org from a user POV, is that right?

It will be a NamingContext, and will appear as so in the rootDSE.


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

Re: About Partition, AdministrativePoints and the whole universe...

[Kiran Ayyagari <ka...@apache.org>]

On Mon, Aug 2, 2010 at 8:03 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
>  Hi guys,
>
> as I'm slowly refactoring the data structure we use to manage
> NamingContexts, I just realized that we may have a way to handle
> encapsulated partitions...
>
> One of the Graal we were chasing was the possibility to define encapsulated
> partitions. Let me give you an example :
>
> if we define dc=example,dc=org as a naming context, then we have to define a
> dedicated partition (be it JDBM, LDIF, HBase, in-memory, SQL-based). That's
> good, but if we want to define a sub-partition for, say
> ou=apache,dc=example,dc=org, we currenty can't. That means this ou=apache...
> thing will be stored in the same backend than the partition it's defined
> into (dc=example,dc=org).
so this kind of partition won't be shown as a naming context anymore,
its base is always dc=example,dc=org from a user POV, is that right?
>
> We also have some issue currently, like DIRSERVER_1517 : we can't move an
> entry from one partition to another one (this is a bug)
>
> Ok, how can we manage encapsulated partitions ? Here is one idea I had :
> - what about leveraging the X500 administrative model ? We currently can
> manage AccessControl, CollectoveAttribute, SubSchema (even if we don't
> support it atm), TriggerExecution, so why not add a new role, the
> PartitionLayout role which defines a new partition starting at the defined
> Administrativepoint ?
sounds like a cool idea
>
> So a partition is a role, defining the storage, and all of it's
> characteristics, using a subentry  for that. Of course, a PL AP won't be an
> Inner AP. We won't allow any subtree specification for this subentry, and
> the base will always be the AP.  It should work.
>
> Now, a few more thoughts : the current partitions configuration is stored
> into the ou=config partition (a LDIF partition). How can we continue using
> this config partition in sync with the subentries ? What if subentries are
> just aliases pointing to the config partition ? As we have to load all the
> subentries at startup, it would be far easier to do that if they are stored
> into the config partition.
+1, it is better to make it as a alias and keep the config in
configuration partition
>
> Ok, those are just ideas, but I think it can fit well with the big picture.
>
> feel free to comment !
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>

thanks Emmanuel

Kiran Ayyagari