-
Notifications
You must be signed in to change notification settings - Fork 18
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
fix: initial commit for loki updates #449
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haven't fully deployed yet but wanted to get these two comments out there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably also want to switch over to Secret
for this value - https://github.com/grafana/loki/blob/main/production/helm/loki/values.yaml#L112
src/pepr/loki/index.ts
Outdated
if (v13Config) { | ||
const currentDate = new Date(); | ||
|
||
if (new Date(v13Config.from) < currentDate) { | ||
// Calculate the new date 2 days in advance | ||
currentDate.setDate(currentDate.getDate() + 2); | ||
|
||
// Update the v13 schema configuration date | ||
v13Config.from = currentDate.toISOString().split("T")[0]; // Format as YYYY-MM-DD | ||
|
||
// Ensure limits_config exists and update allow_structured_metadata to false | ||
if (!lokiConfig.limits_config) { | ||
lokiConfig.limits_config = {} as LimitsConfig; | ||
} | ||
lokiConfig.limits_config.allow_structured_metadata = false; | ||
|
||
// Update the secret with the new config.yaml content | ||
secret.Raw.data["config.yaml"] = yaml.dump(lokiConfig); | ||
log.info(secret.Raw.data["config.yaml"], `Secret config.yaml updated successfully.`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there might be some missing logic here - but want to summarize my understanding of the cases and how we should be handling them:
- install/upgrade: the date (as set in this PR) would be a previous date (2024-06-04) and we would want to generate a future date, 2 days in advance as discussed to be safe with the way Loki handles this
- future upgrade: the date coming into the webhook would be our previous date (2024-06-04), we would want to set this to the date we already generated (probably could query the cluster for this?)
The key here is that we want to generate a date in the future once, but once we generate it once always use that date for future mutations (since the baseline applied from the chart will always be an older date). I think in the current state we would end up mutating this date any time it is in the past?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that is a good point that i totally misunderstood. I've updated so the date is only generated once and stored as an annotation in the secret for future reference.
Description
Updates for bringing in loki renovate updates
Related Issue
Fixes #308
Type of change
Checklist before merging