With DNA configured for allocating POSIX uids with an MMR setup we see the range split in half with every new replica provisioned. This is expected.
It appears that if a replica is deleted then its range is lost. Is there a way to recover this range?
Since each has a start/max value, I guess what we'd have to do is find whatever server has the closest min value and extend the max value on that master. I'm assuming we'll need to delegate writing to the DNA config entry, which I'm a little uncomfortable with.
Is it also safe to assume that this wouldn't require a restart?
Would it be better to instead write a tool to help manage the DNA ranges?
thanks
rob
On 02/20/2013 02:33 PM, Rob Crittenden wrote:
With DNA configured for allocating POSIX uids with an MMR setup we see the range split in half with every new replica provisioned. This is expected.
It appears that if a replica is deleted then its range is lost. Is there a way to recover this range?
Yes, but it's not handled automatically by DNA.
Since each has a start/max value, I guess what we'd have to do is find whatever server has the closest min value and extend the max value on that master. I'm assuming we'll need to delegate writing to the DNA config entry, which I'm a little uncomfortable with.
DNA configuration for each server has an active range as well as an on-deck range. The active range is defined by the "dnaNextValue" and "dnaMaxValue" attributes. The on-deck range is defined by the "dnaNextRange" attribute, which takes a value in the form "<start>-<end>" ("500-1000" would be an example). I would recommend giving the range of a deleted replica to the on-deck range of another replica instead of trying to extend it's active range. That way you don't have to deal with problems where you don't have another master with an adjacent range.
The on-deck range is used internally by DNA when a range transfer takes place. If a replica hits the configured low-water mark (the "dnaThreshold" attribute), it will request a range transfer from another replica. It might still have some active range values left to use, so it puts the transferred range on-deck and swaps it to the active range once the active range is fully exhausted. When you are trying to choose a server to reassign the deleted replica range to, you should make sure it doesn't already have another range on-deck.
Is it also safe to assume that this wouldn't require a restart?
Correct. Dynamic changes will work fine.
Would it be better to instead write a tool to help manage the DNA ranges?
It could certainly help make things easier.
-NGK
thanks
rob
389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Nathan Kinder wrote:
On 02/20/2013 02:33 PM, Rob Crittenden wrote:
With DNA configured for allocating POSIX uids with an MMR setup we see the range split in half with every new replica provisioned. This is expected.
It appears that if a replica is deleted then its range is lost. Is there a way to recover this range?
Yes, but it's not handled automatically by DNA.
Since each has a start/max value, I guess what we'd have to do is find whatever server has the closest min value and extend the max value on that master. I'm assuming we'll need to delegate writing to the DNA config entry, which I'm a little uncomfortable with.
DNA configuration for each server has an active range as well as an on-deck range. The active range is defined by the "dnaNextValue" and "dnaMaxValue" attributes. The on-deck range is defined by the "dnaNextRange" attribute, which takes a value in the form "<start>-<end>" ("500-1000" would be an example). I would recommend giving the range of a deleted replica to the on-deck range of another replica instead of trying to extend it's active range. That way you don't have to deal with problems where you don't have another master with an adjacent range.
The on-deck range is used internally by DNA when a range transfer takes place. If a replica hits the configured low-water mark (the "dnaThreshold" attribute), it will request a range transfer from another replica. It might still have some active range values left to use, so it puts the transferred range on-deck and swaps it to the active range once the active range is fully exhausted. When you are trying to choose a server to reassign the deleted replica range to, you should make sure it doesn't already have another range on-deck.
Is it also safe to assume that this wouldn't require a restart?
Correct. Dynamic changes will work fine.
Would it be better to instead write a tool to help manage the DNA ranges?
It could certainly help make things easier.
I have the feeling we'll have to do both.
First we hunt up a server that doesn't have an on-deck setting. If we find one we put the value there.
I guess otherwise we warn about lost range. Then we'd need a tool for one to manage said range.
rob
389-users@lists.fedoraproject.org
-
Nathan Kinder -
Rob Crittenden