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

kctrl: Install kapp-controller from kctrl #1043

Open
ThomasVitale opened this issue Jan 8, 2023 · 0 comments
Open

kctrl: Install kapp-controller from kctrl #1043

ThomasVitale opened this issue Jan 8, 2023 · 0 comments
Labels
cli Issue for kapp-controller cli enhancement This issue is a feature request priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done.

Comments

@ThomasVitale
Copy link
Contributor

Describe the problem/challenge you have
This feature request, similar to #1001, aims at streamlining the onboarding experience when using Carvel packages.

Right now, the steps needed to setup an environment are the following:

  1. Install kapp-controller with kubectl or kapp (+ optional wait for readiness when using kubectl).
  2. Add a package repository with kctrl (+ create namespace).
  3. Install a package with kctrl.

Step 1 could be made more straightforward, without the need to reference the URL where the YAML manifests are published (found via lookup + copy/paste). Using kubectl to install kapp-controller leads to an additional step to check when the controller is actually deployed and ready (required before moving to step 2). Using kapp would solve that problem since it waits for it to be ready, but it means installing an additional tool.

In the context of onboarding people to Carvel, or when using Carvel to setup a demo/tutorial/workshop/training, the current experience could be improved and simplified (less cognitive load and less tools).

Describe the solution you'd like

I suggest extending the capabilities of the kctrl CLI so that it can be used to install kapp-controller. For example:

kctrl cluster init

The main goal is to improve the onboarding experience and for that no further arguments should be needed. But this could be further enhanced to provide additional capabilities for research or production-oriented scenarios. For example, the CLI could accept additional arguments to customise/configure the deployment. One example of that would be which version of kapp-controller to install.

kctrl cluster init --version 0.44.1

Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you want to help working on this issue.

@ThomasVitale ThomasVitale added carvel-triage This issue has not yet been reviewed for validity enhancement This issue is a feature request labels Jan 8, 2023
@rohitagg2020 rohitagg2020 added the cli Issue for kapp-controller cli label Jan 9, 2023
@renuy renuy added carvel-accepted This issue should be considered for future work and that the triage process has been completed priority/unprioritized-backlog Higher priority than priority/awaiting-more-evidence but not planned. Contributions are welcome. and removed carvel-triage This issue has not yet been reviewed for validity labels Feb 6, 2023
@100mik 100mik added priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. and removed carvel-accepted This issue should be considered for future work and that the triage process has been completed priority/unprioritized-backlog Higher priority than priority/awaiting-more-evidence but not planned. Contributions are welcome. labels Mar 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cli Issue for kapp-controller cli enhancement This issue is a feature request priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done.
Projects
Status: Unprioritized
Development

No branches or pull requests

4 participants