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

Support Argo CD Core installation using this chart #1823

Open
patrickshan opened this issue Feb 3, 2023 · 7 comments
Open

Support Argo CD Core installation using this chart #1823

patrickshan opened this issue Feb 3, 2023 · 7 comments
Labels
argo-cd enhancement New feature or request on-hold Issues or Pull Requests with this label will never be considered stale

Comments

@patrickshan
Copy link

Is your feature request related to a problem?

No

Related helm chart

argo-cd

Describe the solution you'd like

This is basically a copy of original issue: #910 which has been closed.

Support for installing Argo CD Core released in 2.1 via this Chart, would be great.

Describe alternatives you've considered

There are manual installation options currently as well as Kustomize but would be nice to continue to use this Chart to install Argo CD Core.

Additional context

No response

@patrickshan patrickshan added the enhancement New feature or request label Feb 3, 2023
@pdrastil pdrastil added argo-cd on-hold Issues or Pull Requests with this label will never be considered stale labels Feb 18, 2023
@joaocc
Copy link

joaocc commented Jun 6, 2024

Hi. Is there any update on this? Alternatively, any discussion or topic where we can find more about the problems of using the base chart to configure core mode by disabling specific components? Thx

@crstian19
Copy link

I am trying to disable the notifications controller but using enabled: false does not disable it, however dex with enabled: false does work. 🤔

@tijmenstor
Copy link

I am both surprised and not surprised that this issue is still open and untouched for more than a year. The 'core' mode of ArgoCD does not seem to get a lot of love, considering there is a running bug for more than a year too that does not seem too hard to resolve.

On the topic of this issue, it seems there is two ways of approaching this:

  • Take it up into the existing chart

It depends on how you want to implement this. You could either go for an approach where everything is settable according to the 'core' mode, e.g. I can disable/enable certain parts and CRDs. The other approach is having a single setting

core:
  enabled: true

Which would enable/disable anything you need for you. This does require a lot of logic to be added into the Chart that is (quite frankly) complex and annoying to maintain.

  • Create a new chart for core mode

Split off a completely new chart only for the 'core' mode. This would have no impact on the existing Chart, so no complexity needs to be added. The crux here is that there is then another Chart with very similar logic to the main argo-cd Chart. A third option could be even better perhaps.

  • Split up all ArgoCD components into sub-charts

This will allow us to reuse the ArgoCD components in a 'standard' Chart and a 'core' Chart. Updates to internal components are being taken upstream into both Charts, which means the duplicate maintenance is gone.

Then again, this does not seem to have any traction at all, although I'd have no problem putting energy into making this work.

@tijmenstor
Copy link

Shamefully pinging @pdrastil. What do you think about the above? I'd love to work on this and make a PR, but I need to know if it is not wasted effort in the end. I think the Argo Charts can seriously benefit from having this implemented, as Core mode will most likely get more traction with how accessible edge computing and Kubernetes is becoming.

@pdrastil
Copy link
Member

pdrastil commented Aug 1, 2024

@tijmenstor Hi - I think that core part is something we are missing and it should be possible to achieve with toggle switches in current manifests when looking into upstream kustomization.

IMHO I would go for something like this:

global:
  installation: standard | core | <something-else>

where installation determines which set of yaml manifests should be applied. We kinda have this flavouring in place for different ingress implementation and for new alpha version of application controller that runs as Deployment with different set of env variables compared to StatefulSet. I would do similar thing here as Core installation is another flavour. WDYT?

@tijmenstor
Copy link

@pdrastil first of all, thanks for responding so quick!

As for the implementation, I am totally fine with that approach. I think it is the toughest perhaps to maintain in the long run with the amount of logic that it could add, but it is also then the easiest to use by the user themselves. If we agree on this, can I put effort into it to make it available from the Chart?

Another question, you link to the upstream Kustomization in the ArgoCD repository. Is that one still correct? The docs recommend installing the single manifest. I am a bit confused as to which one is the actual source of truth right now.

Many thanks!

@pdrastil
Copy link
Member

pdrastil commented Aug 2, 2024

@tijmenstor There is a note in single manifest file that it has been auto-generated and I would say kustomize folder will be source for the generator. Contributions are welcome if you want to take a look / compare what are differences to standard version of manifests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
argo-cd enhancement New feature or request on-hold Issues or Pull Requests with this label will never be considered stale
Projects
None yet
Development

No branches or pull requests

5 participants