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

Migration script v2 set remoteWrite remoteTimeout to 5s #1243

Merged

Conversation

pmalek-sumo
Copy link
Contributor

Description

Fill in your description here.

Testing performed
  • ci/build.sh
  • Redeploy fluentd and fluentd-events pods
  • Confirm events, logs, and metrics are coming in

@pmalek-sumo pmalek-sumo self-assigned this Dec 15, 2020
@pmalek-sumo pmalek-sumo requested a review from a team December 15, 2020 11:07
@pmalek-sumo pmalek-sumo added this to the v2.0 milestone Dec 15, 2020
@pmalek-sumo pmalek-sumo linked an issue Dec 15, 2020 that may be closed by this pull request
Copy link
Contributor

@sumo-drosiek sumo-drosiek left a comment

Choose a reason for hiding this comment

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

It would be nice to check if value is already set, but LGTM

@pmalek-sumo
Copy link
Contributor Author

It would be nice to check if value is already set, but LGTM

So I've tried a different approach with merging the temporary file that we work on with remoteWrite document (with specified 5s remoteTimeouts) but the problem with this is that it might overwrite other values in that tree.

Maybe there's a way of doing this in yq but I'm not familiar with it. I'm also not sure if we can iterate over elements with yq and then take action in the script.

Copy link
Contributor

@perk-sumo perk-sumo left a comment

Choose a reason for hiding this comment

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

I think we shouldn't change this value at all.
Just check the user config and in case it is set we should display the INFO that we've changed the default value to 5.

@pmalek-sumo
Copy link
Contributor Author

I think we shouldn't change this value at all.
Just check the user config and in case it is set we should display the INFO that we've changed the default value to 5.

Changed to just log if remoteWrite is set

@sumo-drosiek
Copy link
Contributor

Maybe there's a way of doing this in yq but I'm not familiar with it. I'm also not sure if we can iterate over elements with yq and then take action in the script.

It's possible in yq. We did it in upgrade-script for v1

echo
info "kube-prometheus-stack.prometheus.prometheusSpec.remoteWrite.[*].remoteTimeout is set"
info "Please note that we've set it by default to 5s in 2.0.0"
fi
Copy link
Contributor

Choose a reason for hiding this comment

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

We should inform if remoteTImeout is not set as well

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

or set it

Copy link
Contributor

Choose a reason for hiding this comment

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

It is set by default in values.yaml, no need to add this into migrated conf file.

@pmalek-sumo pmalek-sumo force-pushed the upgrade-script-v2-prometheus-remoteWrite-remoteTimeout branch from a6c05d0 to 205f3bf Compare December 16, 2020 11:18
Copy link
Contributor

@perk-sumo perk-sumo left a comment

Choose a reason for hiding this comment

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

👍

@pmalek-sumo pmalek-sumo merged commit 3dabbe9 into main Dec 16, 2020
@pmalek-sumo pmalek-sumo deleted the upgrade-script-v2-prometheus-remoteWrite-remoteTimeout branch December 16, 2020 11:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Prepare 1.x to 2.x migration script
4 participants