Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1513058 - [RFE] Option to forcefully create host from satellite webui for non-admin users.
Summary: [RFE] Option to forcefully create host from satellite webui for non-admin users.
Status: NEW
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Provisioning
Version: 6.2.12
Hardware: x86_64
OS: Linux
medium vote
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact: Roman Plevka
Depends On:
TreeView+ depends on / blocked
Reported: 2017-11-14 16:50 UTC by Mahesh Taru
Modified: 2019-04-09 03:45 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3240261 None None None 2017-11-14 17:04:25 UTC

Comment 4 Lukas Zapletal 2018-03-09 09:47:35 UTC

When provisioning of discovery host fails, non-admin user needs permission to delete regular hosts in order to be able to reprovision host.


In the current design, discovered hosts and provisioned hosts share the interfaces table where MAC address must be unique. It is not possible to discover a host with MAC address which is present in satellite inventory - an error is returned.

This is the safe design decision - you don't want to allow users to overwrite provisioned hosts in satellite inventory to prevent data loss.


Give the user permission to delete the host, this can be achieved by setting ownership of the host to the non-admin user and giving permission to delete own hosts only. The user will only be given permission to delete his own hosts. This can be achieved with permission filters.


We are planning to change the design of how discovery hosts are stored in database in a way that discovery will never fail. But provisioning of a host wont be possible until a rogue host is deleted from the database - MAC address must be  unique (at least per subnet).

Comment 5 Bryan Kearney 2018-03-09 14:56:04 UTC

So, how would you suggest I handle this rfe?

Comment 6 Lukas Zapletal 2018-03-12 14:44:39 UTC
Since refactoring of provisioning hosts storage is not going to happen soon and it won't actually solve the problem after host is provisioned (but its in failed state), the most reasonable approach would be making sure that non-admin user is able to delete his/her own discovered and provisioned hosts. This should work out of box, let's ask CU if they are fine with that. If some changes are needed (e.g. explicitly change owner based on discovery rule), we can implement that.

Note You need to log in before you can comment on or make changes to this bug.