A replica doesn't get a range of ID's to assign until the first time it needs one. It gets this range from the master it was created from. Since you had already shut that master down there was nowhere to get this range of IDs, hence the error.

You can  use the ipa-replica-manage command to set a range, though it is important that it not overlap with any other masters or IDs already issued (in your case this barely applies).

My understanding is that Tomas's complaint is mainly about usability: This behavior can be logical from implementation's point of view but definitelly surprises unsuspecting admin/user.

We have discussed this with Tomas and agreed that this warrants at least command to get the ranges to the new replica (+ I would say necessary doc note).

The reasoning behind that is quite straighforward:
Admin expects the replica to function just fine when the older replica is down. That is the reason why he is creating replica in first place, so anything which breaks this assumption is bad.

(In reply to Rob Crittenden from comment #1)
> A replica doesn't get a range of ID's to assign until the first time it
> needs one. It gets this range from the master it was created from. Since you
> had already shut that master down there was nowhere to get this range of
> IDs, hence the error.
> 
> You can  use the ipa-replica-manage command to set a range, though it is
> important that it not overlap with any other masters or IDs already issued
> (in your case this barely applies).

One immediate question occurred to me: Could the replica easily get its ID range as part of the creation process? Could it be the default behavior to prevent this bug (and possibly other, related bugs) from occurring?

From the user's perspective, it is always better to work out things like this under the hood if possible rather than documenting a limitation that is counter-intuitive, especially for newcomers.

However, just a documentation update is certainly an option here.

The "best" way to get a range is to let DNA do it (to have locking, etc.)

When a range is assigned half of the current server's range is given. There are some installs that want to centralize all object creation on a few servers, so assigning a range can deplete range significantly.

The question isn't so much "can we?" as it is "should we?"

Rob, are you saying that server is not able to deal with situation where it's own range is depleted?

I could be the underlying problem.

AFAIU the initial master, yes, since it has no other server to ask for additional values. A replica will ask it's creator for more values if it runs out, assuming that server is accessible.

The underlying problem is that ranges aren't assigned until they are needed, and that is somewhat for a reason, as stated above.

ipa-replica-manage has DNA range commands which can help resolve issues that come up, and when a replica is deleted an attempt is made to recover any range it has assigned.

Tomas and me thinks that current behavior is not user friendly so I'm trying to figure out how it could be improved.

What prevents the original master from requesting part of the range back from another replicas (which received fractions of the range from the original master)?

This will help, yes. We are tracking the request in Bug 1029640. There is still a chance it would be fixed in RHEL-7.2.

I would suggest closing this Bugzilla as duplicate to the bug above.

I would say that bug 1029640 is a pre-requisite for fixing this bug, not a duplicate. 

We could freely distribute ranges during ipa-replica-install when bug 1029640 is closed because there will much smaller change that something will go wrong.

(My understanding is that the original reason why ranges were not distribured during replica installation - i.e. range depletion - will not be valid anymore, is that right?)

This is happening in the field, too:
https://www.redhat.com/archives/freeipa-users/2015-May/msg00515.html

Upstream ticket:
https://fedorahosted.org/freeipa/ticket/5070

The bug doesn't have high enough priority in comparison to other IdM bugs/RFEs for 7.4. Moving to next release. Without sufficient justification it can be moved again later.

With ipa-healthcheck we certainly can have a rule that warns that this replica has no ranges yet. We also could have Web UI popup/warning telling the same and telling that shutting down a master of this replica would cause problems as no sub-range is allocated yet.

It means there are two tickets out of this bug that could be fixed.

Another note -- for POSIX IDs we have now the range in a replicated subtree. This means that all replicas have information about ranges and can do a decision whether a range is allocated to them.

This BZ has been evaluated multiple times over the last several years and we assessed that it is a valuable request to keep in the backlog and address it at some point in future. Time showed that we did not have such capacity, nor have it now nor will have in the foreseeable future. In such a situation keeping it in the backlog is misleading and setting the wrong expectation that we will be able to address it. Unfortunately we will not. To reflect this we are closing this BZ. If you disagree with the decision please reopen or open a new support case and create a new BZ. However this does not guarantee that the request will not be closed during the triage as we are currently applying much more rigor to what we actually can accomplish in the foreseeable future. Contributions and collaboration in the upstream community and CentOS Stream is always welcome!
Thank you for understanding.
Red Hat Enterprise Linux Identity Management Team