The openstack-manila RPM installs the manila but doesn't set a specific UID. useradd -r -g manila -G manila,nobody -d %{_sharedstatedir}/manila -s /sbin/nologin -c "OpenStack Manila Daemons" manila Other projects, e.g. Glance, do set a consistent UID. Is this something you want to do for manila? Other bugs have been opened in the past about the same issue and have been fixed. https://bugzilla.redhat.com/show_bug.cgi?id=1115948
John, do you have any specific, concrete examples of problems that would be caused *for manila* if uids are not consistent across nodes and deployments? I took this issue to #RDO and was pointed to meeting logs [1] from January 2016 in which it was decided that because there is no authority for reserving uids for OpenStack projects, this would no longer be done. I raised some theoretical/hypothetical objections [2] but unless there are concrete reasons that we need a fixed uid (as I think there are for nova with shared backing storage for libvirt) I don't think we'll get much traction. Do you know of any similar issues for ceph? [1] https://meetbot.fedoraproject.org/rdo/2016-01-13/rdo_meeting_(2016-01-13).2016-01-13-15.02.log.html [2] http://eavesdrop.openstack.org/irclogs/%23rdo/%23rdo.2017-10-24.log.html#t2017-10-24T20:31:29
Tom, Thank you for looking into this. We're hitting an issue where consistent UIDs would be nice when trying to resolve the problem described at: https://review.openstack.org/#/c/509020/10/puppet/services/ceph-base.yaml@137 We want to set up permissions on a ceph keyring with ACLs as per CVE 2017-12155. If the username doesn't exist yet, because of the order of operations between diff puppet modules that create the key vs create the user to read the key, then we wanted to use the UID as a workaround. There are other solutions in theory, e.g. ensure one operation happens before the other but I'm not sure what that's like in practice. Keith (kschinck) is looking into that approach and is on the CC for this bug so he should comment how feasible it is to pursue that method. He's currently testing with usernames. I think the next step here is to get his input. Thanks, John
Tom, For OS deployed machines, since the user does not exist when Ceph is configured, symbolic names cannot be used at the point the ACL command is ran or the user ownership is set on the file. The manila user does not exist until the service is configured. A consistent username to UID mapping will allow the patch to use the UID of the to be created user. glance is always 161, nava is 162 Keith
Let me explain what's the issue in setting UIDs. There's no central authority to define the mapping between services/UID, which means that there's no way to prevent conflicts but to use dynamically allocated UID. As for Nova, glance, they were packaged in Fedora which then still allowed static UIDs and where they do maintain such registry. Since, they deemed that dynamic UID was the way to go, and people who still wanted to ensure consistent UID over a cluster have better ways to do so (E.g: users database stored through LDAP). If there's no other way (I mean a reason stronger than Nice To Have), then you have to find UID/GID that nobody uses accross RHEL, RHEL-based products, Fedora. And that includes everything that is currently available through repo.
In light of Haikel's explanation Keith is taking a different approach to the problem he describes in https://bugzilla.redhat.com/show_bug.cgi?id=1506023#c5 and for now at least we've decided that consistent uids across deployments and products is not a requirement. Closing with "won't fix."