-
Notifications
You must be signed in to change notification settings - Fork 21
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
Use CAPI capability of Flux's HelmRelease to install apps into target cluster #226
Conversation
a6bf801
to
9311595
Compare
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.
@Schnitzel @wahabmk Do we want to keep it as an example just for one template? If not, I think we'd better separate it as a subchart and inject it into all of our templates.
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 it is a good idea to separate out the YAML for installing custom apps and injecting it into all HMC templates. We could do it either:
- By creating
hmc/templates/apps
folder with the app YAMLs (nginx, cert-manager, etc) and extending thetemplates-generate
make target to copy the YAML files fromhmc/templates/apps/
into each HMC template underhmc/templates/<template-name>/templates/apps/
. This way we won't have to manage and version a separate helm chart for the apps (if that is desirable). - Or we could make a separate Helm chart (perhaps library chart) with the app YAMLs and include it as a versioned subchart dependency into each HMC template.
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'm ok with having it right now inside a specific template without a subchart or anything. We're are doing this first version really to just to proof that we can install helmcharts into a target cluster from a template. So lets get it in as we have it here.
The whole thing of having helmcharts installed across all clusters will come with the extended version of State Management that Martin and I are working on defining.
createNamespace: true | ||
remediation: | ||
retries: -1 | ||
values: |
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.
@Schnitzel @wahabmk Do we want to allow overrides for some/all values? I think it also makes sense to allow enabling/disabling of those releases.
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.
Do we want to allow overrides for some/all values?
I am leaning towards the opinion that we should not control what value overrides to allow/disallow for these apps. Reason being that if we want these HMC templates to be publicly available, anybody should be able to override these values (as per their needs) to values other than what we have used or unused as default.
I think it also makes sense to allow enabling/disabling of those releases.
Agreed
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.
yea agree we should let the customer overwrite anything they want (especially in this current iteration). In the future we might have tighter managed templates by mirantis that will not allow any changes, but here it's ok.
hmc.mirantis.com/managed: "true" | ||
spec: | ||
chart: cert-manager | ||
version: ">=v1.12.3" |
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.
@Schnitzel @wahabmk do we want automatic upgrades here?
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 good point. I should remove the >=
and just pin it to a specific version.
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.
yea agree, we should not have auto updates, let's pin it.
1a4b54c
to
3639741
Compare
3639741
to
8206e8c
Compare
1a76cb4
to
0859873
Compare
|
||
# Optionally install apps defined under | ||
# templates/apps into target cluster | ||
installApps: false |
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 make this by default true? I think its just easier to demo.
Also let's rename installApps
to installBeachHeadServices
which is the term we want to use for these type of applications
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.
@wahabmk Oh also, can we rename the folder templates/apps
to templates/beachheadservices
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.
couple of small things from my side, the rest is great
3992589
to
a5de0c3
Compare
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.
Great! thank you very much!
Use CAPI capability of Flux's HelmRelease to install apps into target cluster
Description
There is no change in HMC code needed to use the CAPI capability of Flux Helm Controller to install applications into target cluster. So this PR adds the following to the
templates/aws-standalone-cp
chart as an example of how to use this feature with HMC:cert-manager
which references aHelmRepository
type source.nginx-ingress
which references anOCIRepository
type source.Manual Testing
Management Cluster
The Flux objects for cert-manager and nginx-ingress are created and reconciled in the management cluster:
Target Cluster
The CRDs for cert-manager and nginx-ingress have been installed:
The controller deployments for both and their respective secrets (that have release info) are present in each's respective namespace: