Description of problem: Some organizations can provide a user with escalated privileges that can do all the stuff required to install and configure OpenStack and are not root. packstack should use that user. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I think PackStack should provide the ability to select the user you want to use. If the person using it has a user called 'bob' they want PackStack to use, then that's what it should do. Likewise, if the user _wants_ to use root, PackStack should use root. Of course, for non-root users we'll need sudoers set up properly and we'll need to document how to do that. But for root, it should remain as it does today w/o need for sudo. For ease of use, I would suggest that root still remains the default. Since PackStack is not targeting enterprise datacenters, and is instead intended for PoC deployments, this seems reasonable. This is different than the issues with root provisioning via RHEV-M, since that targets enterprise datacenters not just PoC's
From a documentation POV I would envisage that organizations with such setups may also desire/require an accurate list of the commands that the utility needs sudo access to run as opposed to giving it the ability to run anything it wants through root.
We can do this, but note The reality is we're going to have to give a user access to run puppet with sudo access, which basically opens up what that user can do to pretty much anything.
I wonder how this could be handled taking into account that we'll require root privileges for certain operations (see bug #999923)
Given that packstack is for PoC's and not production usage, I think we should close this bug as WONTFIX personally. It's just not as high priority as originally thought now that we are focusing on things like Foreman for more production environments.