Monitoring

modifications on the iac to make it work for the monitoring agent:

• we split piacere monitoring in two stages, as we were not able to run in a single playbook the galaxy instalation of a role and the usage of that role
• we added the loading of the piacere monitoring vars from the environment so that iem can fill them with the received deployment id and the details of the influxdb and wazuh manager
• for telegraf we added random string for the name if the keypair to avoid conficts
• besides after a security groups quota error we merge the 4 security groups into one, that possibly is more complex and less descriptive unfortunately.

requested review from @josu.diazdearcaya

assigned to @rpiliszek

added 1 commit

• 9facda8f - fixes the env variable or default

Compare with previous version

Wow, a lot is changing. Are you sure all the changes are actually necessary? Or are they more like optimizations? I am mostly unsure whether any Terraform changes are needed as it worked previously.

all terraform changes were motivated by errors, one is to avoid the error when trying to create an user with the same name. To do so I have used the resource ramdom string. The other one is due to a quota issue with the security policies, that was strange as there were only like 14 security policies. But if you have increase the quotas the second change can be omitted.

The split into requirements and not also looks optional to me.

Notifying ICG owner @debora.benedetto about the upcoming changes. I don't think we need/want to introduce these changes into ICG in a hurry but definitely something to consider for y2.

changed the description

added 1 commit

• 63686f8b - removes defaults and force to have value

Compare with previous version

added 2 commits

• 5687882a - removes defaults and force to have value
• 1d6a5345 - removes defaults and force to have value

Compare with previous version

added 1 commit

• 5145fe9d - removes defaults and force to have value

Compare with previous version

Are you sure about this line?

yes it is very necessary, those inputs are variables know by the iem for the actual deployment. Most of them are gather based on the output statements of the stages, but the DEPLOYMENT_ID is taken form the incoming request https://git.code.tecnalia.com/piacere/private/t51-iem/iem/-/blob/y1/iem-api/src/core/iem.py#L96.

The point is that it is consumed from the environment and not injected as a variable, unlike the other two.

the iem variable my_env is feed with the values of the outputs and additional details such as openstack credentials provided in the request https://git.code.tecnalia.com/piacere/private/t51-iem/iem/-/blob/y1/iem-api/src/core/iem.py#L91. Some of the values as you indicate are used as variables https://git.code.tecnalia.com/piacere/private/t51-iem/iem/-/blob/y1/iem-api/src/core/engine.py#L116 but others as the openstack credentials are used as environment variables. We use this second mechanisms to pass the DEPLOYMENT_ID to the ansible playbook.

Exactly, the DEPLOYMENT_ID is fed into Ansible regardless of what we say here. Hence why I suggested that it is not needed to be listed here.

not very sure that it is fed into ansible anyway, I have added it as I have seen in the terraform stage. There you can see the OPENSTACK parts are added there as inputs https://git.code.tecnalia.com/piacere/public/demos/icg-nginx-on-openstack-with-monitoring-agents/-/blob/master/terraform/config.yaml#L6 ... after reading the iem the self.validate function in this concrete case will never fail, as we always add the variable, so it can be removed from config and it will have no impact.

One comment before merge. Please confirm because this is the only point that confuses me now...

Ping @gorka.benguria @josu.diazdearcaya

I am merging and testing this one. We can revert the oddity later. Thanks.

approved this merge request

merged

mentioned in commit 447e1e85