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

Reconsider CLI defaults #392

Open
fernando-villalba opened this issue Apr 26, 2024 · 4 comments
Open

Reconsider CLI defaults #392

fernando-villalba opened this issue Apr 26, 2024 · 4 comments

Comments

@fernando-villalba
Copy link

Issue

Creating a cluster with civo kubernetes create creates a cluster with defaults. This is phenomenal use of convention over configuration so the user doesn't need to input too many flags or commands to create a cluster.

However we should perhaps reconsider the defaults used here, right now this is what it does:

  1. Create a cluster with 3 g4s.kube.medium nodes --> We should probably make the g4s.kube.xsmall the default. 3 nodes may be okay, although perhaps 2 is more conservative.
  2. Randomly pick a name for the cluster --> This is phenomenal, no need to change
  3. Randomly pick a Linux distro for cluster --> I don't think this is a good thing as it changes the nature of the cluster too much.
  4. Create a firewall/s for the cluster --> This is also okay, but cluster deletion should clean these, or at least provide an option to do so. Will create another ticket for this.

(Not sure if I am missing other defaults)

In addition, the UI should be aligned with the defaults the CLI provides.

Acceptance Criteria

  1. Reconsider changing the defaults to create a cluster that's as cheap as possible for generalised workloads.
  2. Make the OS deterministic, don't randomize it.

Cluster defaults should be

  • As secure as possible.
  • As cheap as possible.
  • Catering to general needs of the public wishing to test a cluster or use for quick, simple workloads. We perhaps shouldn't assume that the defaults are for heavy workloads, or even for production workloads as in those scenarios a user may want more fine grained settings
  • The nature of the cluster should be predictable, randomizing the OS prevents that.

Another option could be to create templates for different types of configs, for example:

  • ML
  • Production
  • Test
  • Budget
  • Etc

But this is out of the scope of this ticket.

harsh082ip added a commit to harsh082ip/cli that referenced this issue Jul 11, 2024
@harsh082ip
Copy link

Hi Team,

I have addressed several aspects of this issue:

Set the default node size to g4s.kube.xsmall
Set the default number of nodes to 2
Ensured firewall rules are correctly applied during cluster creation
However, I was unable to find a way to make the OS selection deterministic. There doesn't seem to be any mention of this in the API documentation. Could you provide guidance on how to achieve this?

Regards,
Harsh

@harsh082ip
Copy link

I have made a PR regarding this issue,
Please review it
@haardikdharma10 @fernando-villalba

@harsh082ip
Copy link

#441

@harsh082ip
Copy link

Please refer this 👆👆

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants