-
Notifications
You must be signed in to change notification settings - Fork 16
Radius Upgrades with GitOps #99
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
base: main
Are you sure you want to change the base?
Radius Upgrades with GitOps #99
Conversation
Signed-off-by: willdavsmith <willdavsmith@gmail.com>
**Cons**: | ||
- Helm-specific, possibility of Helm breaking changes in the future | ||
- Have to build and integrate new container, `preflight`, into the Radius Helm chart | ||
- Code duplication between `preflight` container and `rad` CLI |
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.
Can you expand on this a bit more? Wouldn't the rad CLI just use help upgrade?
spec: | ||
containers: | ||
- name: preflight | ||
image: ghcr.io/radius-project/preflight:{{ .Chart.AppVersion }} |
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 feel like another image will bring other maintenance issues with it. Is this going to be installed with each rad init
and/or rad install
?
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.
One more image for air-gapped environments.
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.
There will have to be CLI changes to be able to set this image and tag.
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.
There needs to be a flag on rad install kubernetes to not install the preflight container
|
||
**Implementation**: | ||
- Create Job template with `helm.sh/hook: pre-install,pre-upgrade` | ||
- Package existing `pkg/upgrade/preflight` code from `pkg/upgrade/preflight/registry.go` |
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.
This will need to have a main.go and Dockerfile. I feel like it may be over-engineering at this point of rad upgrade kubernetes
and rad rollback kubernetes
.
- Simplest to implement and maintain, taps into Flux and ArgoCD resources and doesn't require large Radius Helm chart changes | ||
|
||
**Cons**: | ||
- Requires separate reconcilers for Flux vs ArgoCD |
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.
Can we at least have a Base reconciler for different GitOps implementations? Like base.go
and then flux.go
and argocd.go
may have different functions based on the need.
|
||
## Open Questions | ||
|
||
Q: Should we consider using the `rad` CLI directly in the `preflight` container? |
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.
Would this help with eliminating the duplicated code problem in option 1?
``` | ||
|
||
**Pros**: | ||
- Simplest to implement and maintain, taps into Flux and ArgoCD resources and doesn't require large Radius Helm chart changes |
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.
this seems more complex to implement
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.
Describe why the proposed option is the right option. Also, the design template has a section for "alternatives considered". I think the two options you do not recommend should be there with an explanation of why they are not recommended.
No description provided.