[FEATURE] Make bake_agent configurable when creating a new host

[ms0mmer]

Describe the festure
The API call for creating a new host, has a parameter "bake_agent", that can be set to true to "bake the agents for the just created hosts".
Adding this as an optional parameter to the host module would eliminate the need to rebuild the agent in a seperate task and replicate the behaviour when creating a new host in GUI.

Component Name
checkmk.general.host

Ansible Version

Paste verbatim output from ansible --version between triple backticks.

ansible [core 2.14.18]
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.9/site-packages/ansible
  ansible collection location = /root/.ansible/collections:/usr/share/ansible/collections
  executable location = /bin/ansible
  python version = 3.9.25 (main, Apr 17 2026, 00:00:00) [GCC 11.5.0 20240719 (Red Hat 11.5.0-14)] (/usr/bin/python3)
  jinja version = 3.1.2
  libyaml = True

Collection Version

Paste verbatim output fromansible-galaxy collection list between triple backticks.

checkmk.general       7.7.0

Environment
RHEL9
Checkmk 2.4

Screenshots

[robin-checkmk]

Spontaneous response: What is wrong with a handler calling the bakery module, if one or more hosts were created/modified?

[ms0mmer]

Where (in my opinion) it would really shine is with the checkmk.general.agent role, if you have "checkmk_agent_add_host: true".
I don't think it's currently possible to fire the handler in between the creation of the host and the install of the agent when using the role.

Having this option, the new host would automatically get it's agent package assigned (instead of generic or vanilla) with no further steps to be taken.

[robin-checkmk]

I see. My main concern is adding the same functionality in differend places, which makes it maintenance hell.
So I would say no to a new option of the host module. Use a handler instead, that is the Ansible way.
But you raise a good point for the agent role, as users would have to modify a copy of the role for this.

As adding a variable to generally enable automtic baking and a handler to do the baking is not too hard, would you want to do the honors yourself? At least rephrase this issue please, then you or I can work on the sensible functionality.

Thanks for raising this!

[ms0mmer]

Thank you for your quick answer.

Please don't get me wrong, I'm not a Python developer. But as far as I understand it, checkmk.general.host encapsulates the API call associated with the host's creation in the create function

ansible-collection-checkmk.general/plugins/modules/host.py

Lines 700 to 705 in 2cf3ce9

	if not data.get("nodes"):
	result = self._fetch(
	code_mapping=HostHTTPCodes.create,
	endpoint=HostEndpoints.create,
	data=data,
	method="POST",

and the checkmk.general.agent role just calls that "create" via checkmk.general.host .

ansible-collection-checkmk.general/roles/agent/tasks/Linux.yml

Lines 53 to 67 in 2cf3ce9

	- name: "{{ ansible_facts['system'] }}: Ensure Host is present in the correct Folder."
	checkmk.general.host:
	server_url: "{{ checkmk_agent_server_protocol }}://{{ checkmk_agent_server }}:{{ checkmk_agent_server_port }}/"
	site: "{{ checkmk_agent_site }}"
	validate_certs: "{{ checkmk_agent_server_validate_certs | bool }}"
	api_user: "{{ checkmk_agent_user }}"
	api_secret: "{{ __checkmk_agent_auth }}"
	folder: "{{ checkmk_agent_folder }}"
	name: "{{ checkmk_agent_host_name }}"
	state: "present"
	become: false
	register: __checkmk_agent_create_result
	delegate_to: "{{ checkmk_agent_delegate_api_calls }}"
	when: checkmk_agent_add_host | bool
	notify: "Activate changes"

Wouldn't it then be better to have the API related parameter (bake_agent) in checkmk.general.host - where the API call lives - and let the checkmk.general.agent role just do it's thing, as it does now. Trusting the host create function to do its job, be it bake or not bake?

[robin-checkmk]

I see your point and it is generally a good one and arguments can be made for it.

However, here are my concerns:

• For the agent role, we still need to make it configurable, if you want an agent to be baked or not.
• The functionality can be surprising and we would need to make it default to false.
• We would also need to provide guard rails for Checkmk Community and older versions.
• When using Ansible the "handler way" makes more sense, as you likely are touching more than one host at a time.
  • Even if that is not the case, the cost of a "bake handler" is not different to the single option.

I'll leave this open for others to partake, as we currently have two in my opinion equally valid approaches and I woul like to see, what others think.

If you or I find the time, we can already give the agent role implementation a shot, as that will be needed one way or the other to enable your use case.

[robin-checkmk]

I checked with some colleagues (who are also users of the collection and one is a former Ansible developer) and got more good feedback:

• Idempotency: Which state would the host module return, when triggering agent baking?
• Performance: They emphasized that for every single host a full bakery run would be triggered.

While pondering this, I realized there are even more challenges: If you are using the agent updater, you do not only want to bake, but to bake and sign your agents. This cannot be done without the key id and passphrase, which then need to be configured.

So while I see the benefit for your use case, I am hesitant to implement this even in the agent role, as it introduces significantly more complexity if done right.

To put it into contrast: To achieve your goal, there is a simple solution: Run the agent role twice and bake agents in between (automatically as well of course). This produces your desired state. Or you start using the agent updater, which can be registered by one agent role run and then takes care of updating your agent to the fitting configuration.

To conclude: In my role a BDFL of this project, I deem the value added too low to justify the complexity of the necessary code changes for the time being. I am willing to keep this issue open for a while to give the community a change to challenge my decision (or support it).