How to proceed with the host module

[Fobhep]

The host module is surely one of the most desired modules, which do not exist yet. Currently we have an orphaned PR for the host module, last feedback was over a year ago. @mdellweg and me had today a little brainstorming and I want to propose a possible way to make some progress with this matter.

• [x] Step 1 create a host module that can create, switch on/off and delete a host, that was created from an exisiting host group. Either based on the current PR or create a new one form scratch - featuring @evgeni's refactoring.

• [x] Step 2 start writing a host_group module. host groups can be "incomplete", meaning we could slowly add functionality to it until it covers a "complete" host.

• [x] Step 3 Port the host-group functionality to the host-module

Of course your opinion @ismaelpuerto to this is highly appreciated, since you created a first PR for that.

I am not sure yet if there are any major drawbacks with that approach. However I am happy to hear your opinion @sean797 @evgeni @akofink @mdellweg. Feel free to add other people to the discussion!

[mdellweg]

I want to emphasize the possibility to commit small changes in this proceeding, which hopefully speeds up the process.

[evgeni]

I currently have no use for a host module, so whatever you can come up with is good for me ;)

One thing to keep in mind: the Host entity has one of the most complicated validations we have, so starting with just a few attributes for create/update is still a lot of work. Maybe start with a host that has managed=false and then add from there?

[akofink]

I also have no use for this module that I can think of. I'm definitely fine with an iterative approach, starting with a minimal module.

[ismaelpuerto]

Thanks for you work @Fobhep

[Fobhep]

Thanks for you work @Fobhep

:) happy to get your feedback/contributions in the next iterative amendments to host and hostgroup ;)

[evgeni]

given we have a basic host module now, should this be considered done?

[mdellweg]

I think we are in the middle of step 2 here.

[Fobhep]

yap - I agree with @mdellweg

[evgeni]

oki, thanks for the input!

[mdellweg]

We should at least mention #429, #389 and #366 here. I think, they establish that we can move to bullet-point 3 of this issue now.

[evgeni]

Yepp, I agree. Wonder if most of the params we have for host and hostgroup should move to a central place as both accept a huge list of identical params?

[akofink]

Also consider that host and hostgroup are extensible by Foreman plugins. Which of these plugin params should it support? Maybe we could offer a flexible interface that allows users to pass any random param?

[mdellweg]

If i recall @evgeni s recent talk correctly, that is what we wanted to go away from with the individual modules. Also we have parameters (like open_spap_proxy) that are only working (and hopefully so documented) in combination with certain plugins.

[akofink]

Right, I was more saying that we could have an additional_params dictionary, like this:

foreman_host:
  name: 'foo'
  ...
  additional_params:
    foreman_salt_environment:
      id: {{ salt_environment_id }}
    foreman_openscap_policy: xccdf_org.ssgproject.content_profile_hipaa

[evgeni]

Why additional instead of directly in the spec? Or would additional be free form and passed to the api without processing?

[evgeni]

Btw, i think we currently drop the params that don't match plugins (like scap) silently, we should warn the user here

[akofink]

Yes, I was thinking they would just be passed raw to the API. This way we wouldn't necessarily have to support all plugins within FAM. I'm not suggesting we do it, rather just consider it as an idea. :)

[gmangin]

Hey ! i tried to find a way to add interfaces_attributes but i didn't succeed. Tell me if you have an idea about. Thanks EDIT: i make it works with some modification of foreman_host.py, i can send the code to anyone who need it.

[evgeni]

with all the work @mdellweg did, I think when we have closed out https://github.com/theforeman/foreman-ansible-modules/issues/647 we can also safely close this one, right?

[evgeni]

step3 has been completed in #745

now f_host is only missing the following params:

• provision_method
• image
• capabilities
• interfaces(_attributes)

is that a new issue, or shall we put that here?

[Fobhep]

IMHO we can close this and create a new one for that.

[evgeni]

interfaces: https://github.com/theforeman/foreman-ansible-modules/issues/757 the others: https://github.com/theforeman/foreman-ansible-modules/issues/758

closing :fireworks: