Skip to content

Conversation

@sbernhard
Copy link
Contributor

Without this PR, its is currently really broken. Without this PR, it does always! show 'Automatic' - except while editing hosts. For new/edit of Compute Profile or in the Create Host page - always 'Automatic' is shown. A user would never know what is really configured. This is because of [1].

If you create a host later, 'Automatic' is always displayed, regardless of which firmware is selected in the Compute Profile.

This change makes sure, that the selected firmware on the Compute Profile is the one which was saved previously and represents the value from the database while editing a existing Compute Profile.

On the Create Host page, it's a little bit more difficult, because the firmware is automatically chosed by the Compute Profile firmware and the PXE Loader field. To solve this and make it understandable for the user, a corresponding help message is shown while creating a host.

[1] https://github.com/theforeman/foreman/pull/10321/files#diff-c88b347f9af46e109987241498e9db3c776cc76433ffe3ba6f58ae1d8a74b9adR11

<%= field(f, :firmware, :disabled => !new_vm, :label => _('Firmware'), :label_help => _("Choose 'Automatic' to set the firmware based on the host's PXE Loader. If no PXE Loader is selected, it defaults to BIOS."), :label_size => "col-md-2") do
<%
firmware_type = compute_resource.firmware_type(f.object.firmware, f.object.secure_boot)
firmware_help_block = _("If Compute Profile is set to 'Automatic', the firmware selection below was already auto-selected based on the PXE Loader. Setting firmware to 'Automatic' will match the detected firmware based on the PXE Loader unless manually changed.") if new_vm && controller_name != 'compute_attributes'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Lennonka text review please (and for other texts as well)

Copy link
Member

@ekohl ekohl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We really should have written tests for this behavior.

Comment on lines +151 to +152
source = opts.delete(:source).to_s
unless source == 'compute_profile'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You only set the source in the form, but how will that play with the API? It feels to me we're breaking some layers here: the controller should ensure the model is passed correct data.

Copy link
Contributor Author

@sbernhard sbernhard Apr 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, the main problem is, that the same form is used for Compute Profiles and Create Host and, that the this magic process_firmware_attributes(args[:firmware], firmware_type) is done while
a) the form is created (Compute Profile form and Create Host form)
b) after the form was saved, the data is stored in the DB and the host is created on the compute resource

In my opinion, the process_firmware_attributes should only be done for Create Host and when saving the data in the compute resource.

I have not tested it right now, but when used with the API, the source should be nil and therefore the process_firmware_attributes should be used as usual and all data should be handled as before.

Update. tested with hammer:

[root@test-deploy-bernhard ~]# hammer compute-profile info --id 10
Id:                 10
Name:               xyz_api
Created at:         2025/04/28 12:12:47
Updated at:         2025/04/28 12:12:47
Compute attributes: 
 1) Id:               7
    Name:             1 CPUs and 2048 MB memory
    Compute Resource: vcenter.atix.local
    VM attributes:    {"firmware"=>"uefi_secure_boot", "cpus"=>"1", "volumes_attributes"=>{}, "interfaces_attributes"=>{}}

[root@test-deploy-bernhard ~]# hammer compute-profile values update --compute-profile-id 10 --compute-resource-id 1 --compute-attributes firmware=bios,cpus=1
Compute profile attributes updated.
[root@test-deploy-bernhard ~]# hammer compute-profile info --id 10
Id:                 10
Name:               xyz_api
Created at:         2025/04/28 12:12:47
Updated at:         2025/04/28 12:12:47
Compute attributes: 
 1) Id:               7
    Name:             1 CPUs and 2048 MB memory
    Compute Resource: vcenter.atix.local
    VM attributes:    {"firmware"=>"bios", "cpus"=>"1", "volumes_attributes"=>{}, "interfaces_attributes"=>{}}

[root@test-deploy-bernhard ~]# hammer compute-profile values update --compute-profile-id 10 --compute-resource-id 1 --compute-attributes firmware=automatic,cpus=1
Compute profile attributes updated.
[root@test-deploy-bernhard ~]# hammer compute-profile info --id 10
Id:                 10
Name:               xyz_api
Created at:         2025/04/28 12:12:47
Updated at:         2025/04/28 12:12:47
Compute attributes: 
 1) Id:               7
    Name:             1 CPUs and 2048 MB memory
    Compute Resource: vcenter.atix.local
    VM attributes:    {"firmware"=>"automatic", "cpus"=>"1", "volumes_attributes"=>{}, "interfaces_attributes"=>{}}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my opinion, the process_firmware_attributes should only be done for Create Host and when saving the data in the compute resource.

You're right: it should only be made concrete when the compute resource is touched.

Update. tested with hammer:

Is that tested with the patch?

Could you also test creation of the compute profile with firmware set to automatic? My expectation is that it'll store automatic and not process it.

Copy link
Contributor Author

@sbernhard sbernhard Apr 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it is with the patch. Here some more tests with the patch:

with automatic:

[root@test-deploy-master foreman]# hammer compute-profile create --name cp_automatic
Compute profile created.
[root@test-deploy-master foreman]# hammer compute-profile values create --compute-profile-id 6 --compute-resource-id 1 --compute-attributes firmware=automatic,cpus=1
Compute profile attributes are set.
[root@test-deploy-master foreman]# hammer compute-profile info --id 6
Id:                 6
Name:               cp_automatic
Created at:         2025/04/30 19:40:34
Updated at:         2025/04/30 19:40:34
Compute attributes: 
 1) Id:               3
    Name:             1 CPUs and 2048 MB memory
    Compute Resource: vcenter.local
    VM attributes:    {"firmware"=>"automatic", "cpus"=>"1"}

with bios:

[root@test-deploy-master foreman]# hammer compute-profile create --name cp_bios
Compute profile created.
[root@test-deploy-master foreman]# hammer compute-profile values create --compute-profile-id 8 --compute-resource-id 1 --compute-attributes firmware=bios,cpus=1
Compute profile attributes are set.
[root@test-deploy-master foreman]# hammer compute-profile info --id 8
Id:                 8
Name:              cp_bios
Created at:         2025/04/30 19:41:32
Updated at:         2025/04/30 19:41:32
Compute attributes: 
 1) Id:               5
    Name:             1 CPUs and 2048 MB memory
    Compute Resource: vcenter.local
    VM attributes:    {"firmware"=>"bios", "cpus"=>"1"}

the same thing happens without this PR, too BUT:
in case you have created a compute profile with firmware "bios" - in the comput profile UI it will show "automatic". If you then, on purpose or by accident (maybe because of a change of the cpu count or volumes) and press "save" -> it will save "automatic" as new value.
Same on the create host UI -> it will show automatic. in all cases.

Copy link

@Lennonka Lennonka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Further microcopy suggestions

Without this PR, its is currently really broken. Without this PR, it
does always! show 'Automatic' - except while editing hosts. For
new/edit of Compute Profile or in the Create Host page - always
'Automatic' is shown. A user would never know what is really configured.
This is because of [1].

If you create a host later, 'Automatic' is always displayed, regardless
of which firmware is selected in the Compute Profile.

This change makes sure, that the selected firmware on the Compute
Profile is the one which was saved previously and represents the
value from the database while editing a existing Compute Profile.

On the Create Host page, it's a little bit more difficult, because the
firmware is automatically chosed by the Compute Profile firmware and
the PXE Loader field. To solve this and make it understandable for the
user, a corresponding help message is shown while creating a host.

[1] https://github.com/theforeman/foreman/pull/10321/files#diff-c88b347f9af46e109987241498e9db3c776cc76433ffe3ba6f58ae1d8a74b9adR11
Copy link
Contributor

@nofaralfasi nofaralfasi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’ve noticed three issues:

  1. When creating a host on VMware or Libvirt without selecting a compute profile, the firmware defaults to BIOS instead of Automatic. This behavior is inconsistent with the Hammer/API, where the default is Automatic.

  2. When creating a compute profile with the firmware set to Automatic, assigning that profile to a host results in the host’s firmware being set to BIOS, rather than inheriting the Automatic value (as mentioned in your initial PR comment).

  3. When creating a compute profile with the firmware set to Automatic, and a Host Group with PXE Loader set to Grub2 UEFI SecureBoot, assigning that profile to a host still results in the firmware being set to BIOS, instead of resolving to UEFI Secure Boot via the Automatic logic.

So, currently, this PR only addresses the issue on the compute profile form and adds a comment to the host form, which actually increases complexity for users during host creation.

In my opinion, the issues with compute profiles and host creation are deeply interconnected and require a broader refactor, including proper test coverage.

Copy link

@Lennonka Lennonka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Microcopy acked. Thank you!

@sbernhard
Copy link
Contributor Author

  1. When creating a host on VMware or Libvirt without selecting a compute profile, the firmware defaults to BIOS instead of Automatic. This behavior is inconsistent with the Hammer/API, where the default is Automatic.

I have tested this again with the state of develop branch: the firmware is always Automatic (because of [1]). In the version before the secure boot changes, it was set to Automatic, too.
The behavior with this PR, is indeed that BIOS is selected. The root cause is, that this method is used [2] . In the current develop version, this is hidden because its always set to Automatic (see [1])

  1. When creating a compute profile with the firmware set to Automatic, assigning that profile to a host results in the host’s firmware being set to BIOS, rather than inheriting the Automatic value (as mentioned in your initial PR comment).

Yes, because [2] is used to determine firmware instead of setting it always to "Automatic".

  1. When creating a compute profile with the firmware set to Automatic, and a Host Group with PXE Loader set to Grub2 UEFI SecureBoot, assigning that profile to a host still results in the firmware being set to BIOS, instead of resolving to UEFI Secure Boot via the Automatic logic.

This is very interesting. I thought, it should pick the correct firmware with [2] but it doesn't.

So, currently, this PR only addresses the issue on the compute profile form and adds a comment to the host form, which actually increases complexity for users during host creation.

It makes it visible to the user what is currently on going without hiding some unexpected issues like:

  • create a profile with firmware "UEFI" and CPU count 2 -> Save.
  • edit the profile again and change the CPU count to 4 - and this is the only change you want to do -> save
    => afterwards, the compute profile has CPU count 4 and the firmware is saved with "Automatic" because the form does always show and use! 'Automatic'.

In my opinion, the issues with compute profiles and host creation are deeply interconnected and require a broader refactor, including proper test coverage.

Yes, this is something we can do but, the current behavior is a step backward and therefore I would suggest to improve the behaviour step by step.

The root cause of the overall issue is, that the process_firmware_attributes(args[:firmware], firmware_type) is used while creating the form and not only after saving the form and storing the value to the database. Unfortunately, I think, this is how this froms in foreman / rails works and I have no clue how to improve this.

[1] https://github.com/theforeman/foreman/pull/10321/files#diff-c88b347f9af46e109987241498e9db3c776cc76433ffe3ba6f58ae1d8a74b9adR11

[2] https://github.com/theforeman/foreman/pull/10321/files#diff-525a301145c328b1c4d2e6dd7668a9ce4b9f64edb7b2876a4cdebeb5ee2689f9R152

@nofaralfasi
Copy link
Contributor

@sbernhard Could you clarify what functionality was working before and is now broken as a result of the changes introduced in these PRs? #10321, #10324

@sbernhard
Copy link
Contributor Author

@sbernhard Could you clarify what functionality was working before and is now broken as a result of the changes introduced in these PRs? #10321, #10324

Sure:
Without the two mentioned PRs (10321 and 10324) on the compute profile page you selected firmware "EFI" and saved this. If you visit this compute profile again, it shows the selected firmware "EFI".
On the create hosts page, if you select a compute profile "EFI", the firmware is selected to "EFI".

Without these PRS (10321, 10324) and this PR (10529) we have at lease this issue:
On the compute profile page and firmware set to "Automatic" you visit it again, and the page shows "BIOS".
Same on the create host page you select the Automatic firmware compute profile and it shows "BIOS" as selected.

With 10321 and 10324, its always switchting to "Automatic" on the compute profile and on the create host page. For the user, it looks like its never possible to change to any other value than "Automatic".

The implementation before 10321,10324 had also some pretty bad issues, but at least it wasn't always just "Automatic". Like, in case you wantted to enforce BIOS or EFI on the compute profile, this wasn't changed automatically to "Automatic".

If we pick 10321, 10324 and 10529 we are, AFAIK, 100% correct on the compute profile page.

There is still the issue on on the create hosts page mentioned by you in your previous comment which I tried to address by the hint for the user on the create host page.

@nofaralfasi
Copy link
Contributor

Given that this PR introduces new bugs, I recommend holding off on merging it for now. Ideally, we should first focus on finding a way to resolve the issues introduced in PRs #10321 and #10324. Unfortunately, I don’t see a straightforward fix at the moment.

@sbernhard
Copy link
Contributor Author

Given that this PR introduces new bugs, I recommend holding off on merging it for now. Ideally, we should first focus on finding a way to resolve the issues introduced in PRs #10321 and #10324. Unfortunately, I don’t see a straightforward fix at the moment.

I would not recommend this. In my point of view, without this PR, its even more broken. Other may need to decide.

But, I had an idea to solve the last remaining things on the create host page. This would be possible to fix in another PR, too.

@stejskalleos stejskalleos removed their assignment Jun 24, 2025
@stejskalleos stejskalleos requested review from stejskalleos and removed request for stejskalleos June 24, 2025 13:11
@sbernhard
Copy link
Contributor Author

Fixed by #10550

@sbernhard sbernhard closed this Dec 5, 2025
@maximiliankolb maximiliankolb deleted the fix_37834 branch December 8, 2025 07:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants