cp_mgmt_host becoming cp_mgmt_hosts, discussion.

[boneyard]

recently ran a playbook i used many times before using cp_mgmt_host and got the deprecation warning, nice to be warned about this.

i looked into cp_mgmt_hosts and of course cant be against making things better. still there are some things i dont like. the current two states (present / absent) are just gone, making this not backwards compatible, is that really needed?

the documentation on cp_mgmt_hosts can use some work in my opinion, only merged is initially explained. some information about the others is under the round_trip boolean and in the examples. does it make sense at all to create this GATHERED state which does things different from the other states in the same module?

the last question that raises this for me, what about the other cp_mgmt_ modules? are we going to see the same approach there?

[Erik_Lagzdins · Accepted solution]

I can't speak on behalf of the developers, but the approach of the cp_mgmt_hosts module gives users more options to manipulate their data. I've found use cases to use both the cp_mgmt_host and cp_mgmt_hosts modules depending on the situation. I don't expect the cp_mgmt_host module to be removed.

The gathered option for the new cp_mgmt_hosts module can output a YML/JSON file with the list of all the host objects in your database. This output file can be reused immediately to recreate all the objects in another database, or manipulate specific fields in the output file and merge it back to the original database.

 I do expect other modules (network, group) to receive a similar update.