chore: update Elasticsearch stack to 9.5.0 - #2437
Conversation
|
Closing duplicate PR. The 9.5.0 version update is being applied directly to PR #2416. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f88edf4025
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| kubectl patch cronjob/ex-dev-jobs-cleanup-orphaned-data -p '{"spec":{"suspend": false}}' --namespace $DEV_NAMESPACE | ||
| kubectl patch cronjob/ex-dev-jobs-download-geoip-database -p '{"spec":{"suspend": false}}' --namespace $DEV_NAMESPACE | ||
| kubectl patch cronjob/ex-dev-jobs-maintain-indexes -p '{"spec":{"suspend": false}}' --namespace $DEV_NAMESPACE | ||
| kubectl patch cronjob/ex-dev-jobs-migration -p '{"spec":{"suspend": false}}' --namespace $DEV_NAMESPACE |
There was a problem hiding this comment.
Replacing the explicit migration job with this patch does not run migrations: k8s/exceptionless/templates/jobs.yaml gives this CronJob the intentionally non-runnable schedule 0 0 29 2 1 and labels it “never, only manually.” Consequently every development deployment now starts the API and workers without applying or validating the new version's migrations, and the deployment can still report success with pending schema/data migrations. Keep the explicit kubectl create job --from=cronjob/... and completion wait before scaling the workloads.
Useful? React with 👍 / 👎.
| if [[ "$GITHUB_EVENT_NAME" == "pull_request" ]] && | ||
| ! git diff --quiet "$PR_BASE_SHA"...HEAD -- build/docker/elasticsearch/9.x .github/workflows/elasticsearch-docker-9.yml; then | ||
| image_changed=true |
There was a problem hiding this comment.
When a fork pull request changes either watched Elasticsearch path, this branch waits 25 minutes for a content-addressed image that cannot be published by the added elasticsearch-docker-9.yml: that workflow only handles push events in its own repository, and GitHub also documents that “secrets are not passed to the runner when a workflow is triggered from a forked repository” (GitHub Actions secrets documentation). Since test-api, test-e2e, and docker-build all need this job, such external contributions deterministically time out instead of receiving CI; build the candidate in a trusted workflow or skip candidate-image resolution where publication is impossible.
Useful? React with 👍 / 👎.
|
1 participant
Summary
mainUpgrade Assistant report
A local 7.17.28 -> 8.19.15 -> 9.5.0 rehearsal was performed using Exceptionless-style indices:
organizations-v1projects-v1stacks-v1events-v1-*users-v1webhooks-v1migrationsThe 8.19 Upgrade Assistant reported critical
reindex_requiredfindings for indices created under 7.x. Starting 9.5.0 against the unreindexed volume failed as expected, requiring the old indices to be reindexed or archived/read-only before the upgrade.Fresh indices created directly on 9.5.0 produced no migration/deprecation findings.
Validation
git diff --checkpassedNotes
No speculative index-schema changes or application migration behavior were added. Existing 8.19 -> 9.x Upgrade Assistant remediation remains required for deployed data volumes.