Hide Forgot
Description of problem: when we use API to register a new host into a hostgroup, without specifying the OS, the request is accepted instead of being rejected due to lack of needed params and hosts are registered with unexpected defaults. Version-Release number of selected component (if applicable): Satellite 6.1.6 How reproducible: 100% Steps to Reproduce: 1) if we create a new hostgroup without specifying architecture or OS (we can do the same via the webui even when there is marked a * for mandatory fields for arch and os): # hammer hostgroup create --name "AXE" --organizations "V-TS" API: https://localhost:8443/api/v2/hostgroups?search=AXE { "total": 28, "subtotal": 1, "page": 1, "per_page": 20, "search": "AXE", "sort": { "by": null, "order": null }, "results": [{"id":44,"name":"AXE","title":"AXE","subnet_id":null,"subnet_name":null,"operatingsystem_id":null,"operatingsystem_name":null,"domain_id":null,"domain_name":null,"environment_id":null,"environment_name":null,"compute_profile_id":null,"compute_profile_name":null,"ancestry":null,"puppet_proxy_id":null,"puppet_ca_proxy_id":null,"ptable_id":null,"ptable_name":null,"medium_id":null,"medium_name":null,"architecture_id":null,"architecture_name":null,"realm_id":null,"realm_name":null,"created_at":"2016-02-11T16:56:06Z","updated_at":"2016-02-11T16:56:06Z"}] } 2) If we specify an arch / OS / Media / partition save it, this is the output from API: { "total": 28, "subtotal": 1, "page": 1, "per_page": 20, "search": "AXE", "sort": { "by": null, "order": null }, "results": [{"id":44,"name":"AXE","title":"AXE","subnet_id":null,"subnet_name":null,"operatingsystem_id":2,"operatingsystem_name":"RHEL Server 6.7","domain_id":null,"domain_name":null,"environment_id":null,"environment_name":null,"compute_profile_id":null,"compute_profile_name":null,"ancestry":null,"puppet_proxy_id":null,"puppet_ca_proxy_id":null,"ptable_id":7,"ptable_name":"Kickstart default","medium_id":8,"medium_name":"Default_Organization/Library/Red_Hat_Server/Red_Hat_Enterprise_Linux_6_Server_Kickstart_x86_64_6_7","architecture_id":1,"architecture_name":"x86_64","realm_id":null,"realm_name":null,"created_at":"2016-02-11T16:56:06Z","updated_at":"2016-02-11T17:02:26Z"}] } 3) If we revert the modification, by putting all fields blank, this is the result from API: { "total": 28, "subtotal": 1, "page": 1, "per_page": 20, "search": "AXE", "sort": { "by": null, "order": null }, "results": [{"id":44,"name":"AXE","title":"AXE","subnet_id":null,"subnet_name":null,"operatingsystem_id":null,"operatingsystem_name":null,"domain_id":null,"domain_name":null,"environment_id":null,"environment_name":null,"compute_profile_id":null,"compute_profile_name":null,"ancestry":null,"puppet_proxy_id":null,"puppet_ca_proxy_id":null,"ptable_id":7,"ptable_name":"Kickstart default","medium_id":8,"medium_name":"Default_Organization/Library/Red_Hat_Server/Red_Hat_Enterprise_Linux_6_Server_Kickstart_x86_64_6_7","architecture_id":null,"architecture_name":null,"realm_id":null,"realm_name":null,"created_at":"2016-02-11T16:56:06Z","updated_at":"2016-02-11T17:03:57Z"}] } Actual results: By UI all appears blank, but from API all fields but Architecture are still populated . Expected results: The request should be rejected. Additional info:
Moving 6.2 bugs out to sat-backlog.
A user is allowed to create a hostgroup which can be used without Provisioning. You are correct that if you expect to use host groups only for provisioning, then you don't have extra validation that provisioning is actually enabled / configured correctly. I would suggest to change this to an RFE to setup provisioning enabled Host group.
Hi, the proposed change to this bugzilla looks to be already covered by this other RFE already opened: https://bugzilla.redhat.com/show_bug.cgi?id=1311931 In that bugzilla a complete approach is suggested, to remove the provisioning data at all, and have provisioning as a new item to be linked to a hostgroup if needed. The situation here is that the actual results is: By UI all appears blank, but from API all fields but Architecture are still populated . While a coherent behaviour would be that the request should be rejected.
Thank you for your interest in Satellite 6. We have evaluated this request, and we do not expect this to be implemented in product in the forseeable future. We are therefore closing this out as WONTFIX. If you have any concerns about this, please feel free to contact Rich Jerrido or Bryan Kearney. Thank you.