Bug #12461
closedCompute profiles are not applied when inherited
Description
This appears to be a UI/UX regression in 1.10 in connection with the "Unsetting attributes" feature.
Steps to reproduce:
1. Create a new host
2. Select a host group without a compute profile attached
3. Select a compute resource to deploy onto (VMware in our case)
Results: A compute profile is selected and greyed out, indicating it has been inherited and applied. However when you navigate to the "Virtual Machine" tab on the new host screen, it is apparent that the compute profile has not actually been applied.
Expected results: The compute profile field should not be selected and left active for the user to make a selection
Updated by Brandon Weeks about 9 years ago
This is actually a little worse than I thought, the compute profile is not applied even if there is a compute profile in the host group.
Steps to reproduce:
1. Create a new host
2. Select a host group with a compute profile attached
3. Select a compute resource to deploy onto (VMware in our case)
Results: A compute profile is selected and greyed out, indicating it has been inherited and applied. However when you navigate to the "Virtual Machine" tab on the new host screen, it is apparent that the compute profile has not actually been applied.
Expected results: The compute profile field should be applied when it is inherited from the host group.
Updated by Dominic Cleal about 9 years ago
- Translation missing: en.field_release set to 63
Updated by Dominic Cleal about 9 years ago
- Related to Bug #9591: Override puppet configuration on host level does not work if specified on host group added
Updated by Dominic Cleal about 9 years ago
Expected results: The compute profile field should not be selected and left active for the user to make a selection
It appears that #9591 removed the "include_blank" attribute on the compute_profile field, so there's no longer any way to have no compute profile. Adding this back appears, on the surface, to fix it.
This is actually a little worse than I thought, the compute profile is not applied even if there is a compute profile in the host group.
I can't reproduce this aspect on a libvirt compute resource, at least. The selection of a compute resource should trigger this AJAX request:
Started POST "/hosts/compute_resource_selected"
If you can enable SQL debugging (http://theforeman.org/manuals/1.10/index.html#7.2Debugging) then you should also see lookups of compute_attributes, e.g.
ComputeAttribute Load (0.1ms) SELECT "compute_attributes".* FROM "compute_attributes" WHERE "compute_attributes"."compute_resource_id" = 1 AND "compute_attributes"."compute_profile_id" = 4 LIMIT 1
Updated by Shimon Shtein about 9 years ago
There is a workaround for the issue for the meantime:
Select the hostgroup first, then the fields will be set to "inherit", and the system will behave as expected.
Updated by Dominic Cleal about 9 years ago
- Priority changed from Urgent to Normal
Brandon Weeks wrote:
Results: A compute profile is selected and greyed out, indicating it has been inherited and applied. However when you navigate to the "Virtual Machine" tab on the new host screen, it is apparent that the compute profile has not actually been applied.
Expected results: The compute profile field should not be selected and left active for the user to make a selection
Yes, this does seem to just be in the UI - it doesn't apply the profile.
Shimon Shtein wrote:
There is a workaround for the issue for the meantime:
Select the hostgroup first, then the fields will be set to "inherit", and the system will behave as expected.
I think this describes a slightly different issue, but perhaps from the same thing. If you select the compute resource first, then a host group without a profile, then it applies settings from the first profile in the list.
Updated by The Foreman Bot about 9 years ago
- Status changed from New to Ready For Testing
- Pull request https://github.com/theforeman/foreman/pull/2914 added
Updated by Shimon Shtein about 9 years ago
Problems that I have found in code:
1. AJAX requests are passing empty values for inherited fields (environment, compute_profile, puppet_proxy e.t.c), which interferes with the normal flow of hostgroup selection.
2. Hostgroup selection changes only the compute_profile, but does not affect the actual values of the "Virtual machine" tab.
Test cases:
1. With locations organizations enabled:
* go to /hosts/new
* Select organization (AJAX will be fired)
* Select a hostgroup
Expected: Environment field disabled with a value from the hostgroup shown
Actual: Environment field enabled, the value remains empty.
Didn't check it actually, but selection of compute resource in step 2 should lead to the same result.
2.
* Create a hostgroup with a compute profile that is not the first one (if you have 1-Small, 2-Medium, 3-Large use large or medium)
* Go to /hosts/new
* Select a compute resource
* Ensure that properties in "Virtual machine" tab are from the first compute profile
* Select the hostgroup from the first step
* Go to "Virtual machine" tab
Expected: properties are set according to large/medium profile.
Actual: properties are set according to small (first) profile.
Updated by Shimon Shtein about 9 years ago
- Status changed from Ready For Testing to Closed
- % Done changed from 0 to 100
Applied in changeset 95d706426644f40b7ed434d26bf237e643a17a1b.
Updated by Dominic Cleal about 9 years ago
- Related to Bug #12618: Compute profile overrides compute attributes provided in host form added
Updated by Dominic Cleal about 9 years ago
- Related to Bug #12659: Value cannot be overridden by unpressing the "inherit" button added
Updated by Tomer Brisker about 9 years ago
- Related to Bug #12793: organzation and location not saved for hostgroup added
Updated by Ori Rabin about 9 years ago
- Related to Bug #12794: Environment in host isn't saved added
Updated by Dominic Cleal almost 9 years ago
- Related to Bug #13004: Compute Profiles not Inheriting from nested host group added