Changing the feature handling to be more like the official Icinga2 way?

NeverUsedID commented 4 years ago

Hi there,

what do you all think about changing the behavior of i2_custom_features to use the feature-available folder instead of the features-enabled folders and use the original icinga command "icinga2 feature enable/disable" to manage the features?

Changes needed:

i2_custom_features

[ ] i2_custom_features need to create new feature configs inside features-available instead of features enabled.
[ ] Maybe rename i2_custom_features to i2_create_features

I would add another variable to make it possible to name the config file other then the feature. F.e. name the file for the ApiListener "api" too.

i2_features

[ ] i2_features need to use the icinga command to enable/disable commands instead of deleting them, directly in the folder.
[ ] i2_feature need to get config option like i2_custom_feature, but instead of replacing the feature like i2_custom_features will do, it will regex replace lines in the exiting configs.
[ ] Add "enabled: true/false" as config variable
[ ] Maybe renaming i2_features to i2_manage_features

Maybe add a "disable_none_managed: true" variable to remove all conf files in features-enabled before configuring. Still not sure, how to do that without doing it on every run.

Example:

i2_manage_features:
  disable_none_managed: "true"
  api: 
    enable: true 
    config: 
      accept_commands: "true"
  notifications:  
    enable: false

aflatto commented 4 years ago

We aim to have a "one source of truth" for the configuration and nullify the need for manual changes as that is harder to track and manage.

The whole idea is to manage the features from Ansible and not the cli so the feature-enabled is the correct location to make the file modification.

So the idea that we allow the use of the CLI is counter to the goal of this project.

NeverUsedID commented 4 years ago

My plan was not to use the cli command for manual changes in general, but stay inline with Icinga behavior. There was already a disscussion at the offical powershell-module because of that and that somtimes this makes debugging difficult: https://github.com/Icinga/icinga2-powershell-module/issues/52

If you are on the system and you want to debug a problem, "icinga2 feature disable ApiListener" will delete the feature and you will not be able to aktivate it again, until someone with the permission will redeploy it with ansible.

It would also be possible to just copy the feature to features-available and then create a link with ansible, but i tought, why not using the existing command for it.

aflatto commented 4 years ago

I understand your intention and the reason why that use case might seem as the change is needed, but on the whole the idea was the use the playbooks to manage the configuration and avoid the case of two places manipulating the configuration of a node.

The files in the features-available are created in the installation already, so the features-enabled is the correct place to create the files if you want to enable a feature. If you do have a custom ( not icinga supported ) feature then you can add the functionality to create a symlink to the other directory, but from the official stand point there is no need to alter the behaviour of the playbook.

Icinga / ansible-icinga2