Test request - assign host group to a host that is not build managed

Could someone please validate a use case for me, I’m sure this used to work, but before I start to re-trace my steps as to where this has stopped working, someone validating it for me would be appreciated.

Problem:
unable to assign a host group to a puppet client checking into foreman’s puppet master when I select the host, click edit, I assign a hostgroup to the host (as the default is blank) and click submit, the button is pressed, but the action is not executed, and the screen does not return back out of “edit” mode. I can see the submission in the production log. if I then hit refresh / open the web interface in another window and view the host, the hostgroup is still not assigned.

Expected outcome:
foreman hostgroup is set once submit is pressed and web interface returns to view mode out of edit mode.

Foreman and Proxy versions:
1.24.3 foreman and proxy

Foreman and Proxy plugin versions:

Distribution and version:
Centos 7.8.2003

Other relevant data:
Validated this with a few raspberry pi’s and a intel nuc running debian 10 - if I setup the hosts to be ‘managed’ (tricky to bluff for the pi’s but possible) foreman then sets the hostgroup as expected, so the issue is only with unmanaged hosts.

This may be a long shot, but are you clicking the submit button immediately after the hg change? can you try waiting for a minute before clicking submit and see if it is still an issue? My thinking here is that when you change hostgroup, an ajax call is triggered to update other form fields accordingly (e.g. parameters), and maybe if you click submit right away you are submitting the form before it had a chance to be update.

%100 not - I’m leaving it a good 60 seconds between assigning the host group and actually hitting submit.

the production log shows that it’s unable to update (but no error or feedback on screen) that it can’t update because there is no install media assigned to that hosts operating system.

eg:

2020-06-01T19:20:55 [W|app|425fc9dd] Not queueing Host::Managed: [“Medium must belong to host’s operating system”]
2020-06-01T19:20:55 [W|app|425fc9dd] Not queueing Host::Managed: [“Medium must belong to host’s operating system”]
2020-06-01T19:20:55 [W|app|425fc9dd] Not queueing Host::Managed: [“Medium must belong to host’s operating system”]
2020-06-01T19:20:55 [E|app|425fc9dd] Failed to save: Medium must belong to host’s operating system

the more you work through this the more you go down the rabbit whole eg: their must be a pxe profile assigned to that hosts operating system etc etc, to the point where you have to actually “manage” the host.

Looks like for some reason the validation is failing but doesn’t indicate it in the UI. Is it possible that the hostgroup sets a medium for the host which conflicts with the operating system set for it?

1 Like

this is a really good spot, this is the same bug as where the hostgroup is locked to a deployment target and can’t be unset - the target was not set, but it was defaulting to a libvirt target, and a libvirt target had the OS set, so the bug that forces a host to a deployment target was setting a medium, which was failing validation which was stopping this, which explains why it has worked in the past, but no longer works. I’ll try to find that bug and add this situation to it and try to get it bumped into priority.

thanks for the eyes on this, I’d totally missed it because it was supposed to be “unset” but it was that same bug forcing the deployment target that was triggering it.

We are encountering the same bug, also with the same version of foreman. Any chance for a workaround ?

Correcting the media in hostgroups doesn’t work for us. The media_id was still in the hosts Table of the database. Setting the value of medium_id to null solved the problem.