To try and move this forward a bit, why is a static id needed? Please see: http://fedoraproject.org/wiki/Packaging:UsersAndGroups#Soft_static_allocation for some of the questions you could answer to help FPC figure out if this is needed or a dynamic id will do the job.

This is to maintain consistency with other OpenStack components and filed at the request of a reviewer (https://bugzilla.redhat.com/show_bug.cgi?id=986615).

As it stands today, the savanna-api service is deployed on a single system, but is undergoing development to have a scale-out deployment architecture.

Consistency as it seems to be used in that review (other services in this field have static ids, therefore this service should as well) is not a reason to have a static id. It's possible the reviewer is operating on old assumptions about what constituted a need for a static id.

A need for consistency of the uid between installs of a service at different sites run by different administrators probably is a justifiable reason. Consistency between installs of a service on separate hosts within a single site may be justifiable but dynamic allocation may cover this case as well -- http://fedoraproject.org/wiki/Packaging:UsersAndGroups#Methods_of_pre-allocating (That page also explains that we need to be extremely stingy about giving out static ids because they're a very limited resource.)

So in order to evaluate this request, we need to know more about the use of the uid/gid being requested here. Are files going to be owned by this uid? Are the filesystems those files reside on going to be shared with other systems in a way that doesn't allow for mapping the ownership via their symbolic names?

My view, taking into account brief discussions with others in the upstream Savanna project, is that we can't currently justify a static id. However, we acknowledge the need may arise in the future and may re-open the request.