Document URL: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.7/html-single/provisioning_guide/index#provisioning-virtual-machines-kvm https://access.redhat.com/documentation/en-us/red_hat_satellite/6.7/html-single/provisioning_guide/index#provisioning-virtual-machines-kubevirt Section Number and Name: Chapter 9 and Chapter 12 - Prerequisites "A Satellite user account with the following roles" "A custom role in Satellite with the following permissions:" Describe the issue: The permissions mentioned in these two sections are not enough. e.g. if someone wants to use hostgroup or select domain, then won't be able to do so and many more. Suggestions for improvement: Rather than having two sections like that, have an entirely different section to cover the content of https://access.redhat.com/solutions/3412331 . It's applicable for Satellite 6.6 , 6.7 , 6.8. Additional information: NA
PR submitted for review: https://github.com/theforeman/foreman-documentation/pull/2292
(In reply to Sayan Das from comment #0) > Rather than having two sections like that, have an entirely different > section to cover the content of https://access.redhat.com/solutions/3412331 . The article hasn't been updated in years. The table of permissions in that article includes permissions related to Katello which has been deprecated. Are you still using it as a reference to customers instead of the official documentation?
Hello, Yes and that is simply because the permissions suggested in the docs are not adequate enough. Take an example of "Chapter 9. Provisioning Virtual Machines on KVM (libvirt)" from https://access.redhat.com/documentation/en-us/red_hat_satellite/6.13/html-single/provisioning_hosts/index#Provisioning_Virtual_Machines_on_KVM_provisioning We say this: ** A Satellite user account with the following roles: Edit hosts View hosts For more information, see Assigning Roles to a User in Administering Red Hat Satellite. ** A custom role in Satellite with the following permissions: view_compute_resources destroy_compute_resources_vms power_compute_resources_vms create_compute_resources_vms view_compute_resources_vms view_locations view_subnets For more information about creating roles, see Creating a Role in Administering Red Hat Satellite. For more information about adding permissions to a role, see Adding Permissions to a Role in Administering Red Hat Satellite. Even if I combine all the permissions mentioned above in one role and assign the role to a user, Still it will be impossible to deploy a host by impersonating that user. Our doc ( or the sections I had pointed out ) contains compute resource-specific permissions. In my opinion, We should have a generic section created where it would only be documented that, what all basic permissions required in a custom role, to create a host entry and submit it for build with all applicable options selected. And that Section should be referred to "Compute Resource" specific chapters in addition to what existing stuff we have there.
Thanks for confirming, Sayan. I have a work-in-progress version of a table I'd like to add to the guide: https://theforeman-foreman-documentation-preview-pr-2292.surge.sh/nightly/Provisioning_Hosts/index-satellite.html#permissions-required-for-provisioning_kvm-provisioning Is this what you'd like to see in the documentation? I'd like to make sure the update meets your expectations before taking it to Engineering for a review.
While the table looks great, I believe that table would be applicable for any type of deployment ( involving compute resources) but not just for KVM or Kubevirt\Openshift virtualization. So that table can live somewhere at a generic location in the same doc. And it can be referred to individual sections ( wherever needed ) We can even add some comments like, Users can skip the permissions related to "Compute resource" if only Bare-Metal system builds are expected to be done i.e. without using computer resources.
I can make the table appear at multiple places with variations based on the use case (KVM, Kubevirt, bare metal, etc.). The real challenge will be figuring out the permissions applicable to different use cases. I will now keep working on getting the complete list of permissions.