Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow charts to be optional when deploying trento-web #17

Merged
merged 2 commits into from
Jan 24, 2024

Conversation

rtorrero
Copy link
Contributor

This PR makes use of the env var added in trento-project/web#2147 to disable the usage of the new charts feature by introducing the enable_charts var. The variable has a default value of true (it shouldn't be necessary to set it true as it's already true by default in trento-web but I think it helps to make it more obvious)

@CDimonaco something I noticed is that you used CHARTS_ENABLED for the env var, where we usually use the form ENABLE_<something> for such things, if it's ok by you, could we change this for uniformity?

@rtorrero rtorrero marked this pull request as ready for review January 16, 2024 15:37
@CDimonaco
Copy link
Member

@rtorrero the enable of charts should be an and condition between the availability of prometheus and the charts enabling, otherwise we could end in inconsistencies

@rtorrero
Copy link
Contributor Author

@rtorrero the enable of charts should be an and condition between the availability of prometheus and the charts enabling, otherwise we could end in inconsistencies

I thought about this, but what if a user wants to use his existing prometheus installation instead of having us deploy ours? The other way around is also applicable (though a bit more unlikely): what if a user wants to collect metrics with prometheus but doesn't want the charts feature?

@CDimonaco
Copy link
Member

I think this is an edge case scenario, it's true that the user can provide his prometheus, so we can say that it's true when the charts enabled variable is true AND the install prometheus variable or whatever is provided, so false or true we have the user that has an explicit choice, wdyt?

@rtorrero
Copy link
Contributor Author

rtorrero commented Jan 17, 2024

I think this is an edge case scenario, it's true that the user can provide his prometheus, so we can say that it's true when the charts enabled variable is true AND the install prometheus variable or whatever is provided, so false or true we have the user that has an explicit choice, wdyt?

I think I get what you mean, is the following correct?

| CHARTS_ENABLED                     | PROMETHEUS_ENABLED   | Outcome                                                                             |
|---------------------------------------------|--------------------------------------|-----------------------------------------------------------------------------|
| true                                               | true                                       | Charts are enabled, Prometheus is provisioned          |
| true                                               | false                                      | Charts are enabled, Prometheus is not  provisioned  |
| false                                              | true                                       | Charts are disabled, Prometheus is provisioned         |
| false                                              | false                                      | Both Charts and Prometheus are disabled                   |
| <unspecified>                             | true                                       | Charts are enabled,  Prometheus is provisioned         |
| <unspecified>                             | false                                      | Charts are disabled, Prometheus is not provisioned  |                    
| true                                               | <unspecified>                     | Charts are enabled, Prometheus is provisioned          |
| false                                              | <unspecified>                     | Charts are disabled, Prometheus is not provisioned  |

@CDimonaco
Copy link
Member

I think this is an edge case scenario, it's true that the user can provide his prometheus, so we can say that it's true when the charts enabled variable is true AND the install prometheus variable or whatever is provided, so false or true we have the user that has an explicit choice, wdyt?

I think I get what you mean, is the following correct?

| CHARTS_ENABLED                     | PROMETHEUS_ENABLED   | Outcome                                                                             |
|---------------------------------------------|--------------------------------------|-----------------------------------------------------------------------------|
| true                                               | true                                       | Charts are enabled, Prometheus is provisioned          |
| true                                               | false                                      | Charts are enabled, Prometheus is not  provisioned  |
| false                                              | true                                       | Charts are disabled, Prometheus is provisioned         |
| false                                              | false                                      | Both Charts and Prometheus are disabled                   |
| <unspecified>                             | true                                       | Charts are enabled,  Prometheus is provisioned         |
| <unspecified>                             | false                                      | Charts are disabled, Prometheus is not provisioned  |                    
| true                                               | <unspecified>                     | Charts are enabled, Prometheus is provisioned          |
| false                                              | <unspecified>                     | Charts are disabled, Prometheus is not provisioned  |

Yep, let's keep in mind that in 99% of cases both of them will be true, and now in charts web code we have something to thing about multiple prometheus instance but it's not something related to the installation method

Copy link
Member

@EMaksy EMaksy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey man nice, thanks a lot. Just left a comment about the naming. Besides this --> LGTM!

Copy link
Contributor

@arbulu89 arbulu89 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I personally think that we are overdoing things.
If we put the descriptions of the variables correctly, they will be used OK.
So the enable_charts could be: Enable/Disable charts displayed based on Prometheus metrics. A prometheus installation is required, setting "provision_prometheus" to true or providing an externally installed prometheus url in "prometheus_url"

playbook.yml Outdated
@@ -53,12 +53,10 @@

- name: Provision prometheus
become: true
vars:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do you remove this?
what's the default value of it if the user doesn't set it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I keep the vars: section here it breaks the logic that checks if the value is defined to set a default if it's not. We can put it back as it was but this would break the behavior that Carmine suggested

README.md Outdated
@@ -245,7 +245,7 @@ These variables are the defaults of our roles, if you want to override the prope
| provision_postgres | Run the postgres provisioning contained into postgres role, set to false if you provide an external postgres to the services | "true" |
| provision_rabbitmq | Run the rabbitmq provisioning contained into rabbitmq role, set to false if you provide an external rabbitmq to the services | "true" |
| provision_proxy | Run the nginx provisioning for exposing all the services, se to false if you don't want to expose the services or you have already in place a reverse proxy infrastructure | "true" |
| provision_prometheus | Run the prometheus provisioning used by trento to store metrics send by agents | "true" |
| provision_prometheus | Run the prometheus provisioning used by trento to store metrics send by agents | true when enable_charts is true or undefined |
Copy link
Contributor

@arbulu89 arbulu89 Jan 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the default value should be true, The other conditions should be explained in the description.
The same goes for enable_charts.
The current descriptions are really difficult to understand for me at least

@rtorrero
Copy link
Contributor Author

I personally think that we are overdoing things. If we put the descriptions of the variables correctly, they will be used OK. So the enable_charts could be: Enable/Disable charts displayed based on Prometheus metrics. A prometheus installation is required, setting "provision_prometheus" to true or providing an externally installed prometheus url in "prometheus_url"

I guess you are proposing here to decouple them and simply set them both to true by default? this was the original solution, for me it's up to @CDimonaco , I don't have a strong opinion here.

@arbulu89
Copy link
Contributor

arbulu89 commented Jan 23, 2024

@rtorrero If that was the original solution, yes, that's what I would do.
If somebody disables prometheus manually, without providing a installed prometheus url, leaving the charts enabled, I would say it is his fault.
Because anyone, even with this code, can put prometheus to false and charts enabled to true, and still have inconsistencies.
I think that the description is accurate, is all we need to do.

PD: as well, because this crossed dependency I see is extremely strange

@CDimonaco
Copy link
Member

@arbulu89 I agree with you, we can go this way to simplify also the code

I was promoting the other way around but reflecting rn, it's better to go through the easy way

@rtorrero rtorrero force-pushed the allow-charts-optional branch from 18403fb to 2fe03f9 Compare January 23, 2024 18:43
@rtorrero rtorrero requested a review from arbulu89 January 23, 2024 18:45
Copy link
Contributor

@arbulu89 arbulu89 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

@rtorrero rtorrero merged commit b91ad0a into main Jan 24, 2024
10 checks passed
@stefanotorresi stefanotorresi deleted the allow-charts-optional branch January 25, 2024 13:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants