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

[proposal] A windows k8s Swiss army knife as a utility in the carvel family #163

Closed
jayunit100 opened this issue Jan 11, 2021 · 6 comments
Closed

Comments

@jayunit100
Copy link

I would like to propose a new tool to the carvel ecosystem: A windows bolt on command line tool, that you can add to any cluster-api (or non cluster-api based) cluster. For lack of a better name, id call this wanzu to start.

The functionality of this tool would include:

  • Building windows images and uploading them to various clouds as ISOs.
  • Bolting 'windows' nodes on to a CluterAPI cluster (wrapper to clusterctl/ powered by ytt templates)
  • Validating a windows cluster with a few simple smoke tests (wrapper to e2e.test)

I have no idea wether the carvel ecosystem supports proposals, but... in case it does, that's my pitch :) !

@jayunit100 jayunit100 changed the title [proposal] windows-bolt-on [proposal] A windows k8s Swiss army knife as a utility in the carvel family Jan 11, 2021
@jayunit100
Copy link
Author

We have, some rough prototyping in place for this as is, but happy to share more if anyone wants to catch up some time. Also happy to close if this doesn't fit in with the overall carvel model.

My reason for thinking this is perfect for carvel is that, windows clusters are:

  • highly heterogenous
  • require complex update machinery, so they can't be stamped with robot automation easily

The thus really benefit alot from modular tool that can be mixed and matched into different various downstream workflows.

@cppforlife
Copy link
Contributor

@jayunit100 if im reading this right, this tool seems to be angled towards supporting windows for clusterapi. i have a feeling that this may be a better fit under clusterapi umbrella?

@jayunit100
Copy link
Author

it's not capi specific at all , but yes I do believe some capi awareness will be important in it.

Also... I don't think going through kubernetes-sigs/ is worth it as it's not going to be benefited/driven by a heavyweight process .

But if it's not relevant we can just do it on a personal GitHub .

@cppforlife
Copy link
Contributor

@jayunit100 i dont think proposed functionality would fit well into carvel at this point since we are curating general purpose tools that also have fairly stable API boundaries:

Building windows images and uploading them to various clouds as ISOs.

tools like packer already allow you to do this (if packer didnt exist i could potentially see building a tool like that but it wouldnt necessarily be specific to windows). it's not clear what we would add here.

Bolting 'windows' nodes on to a CluterAPI cluster (wrapper to clusterctl/ powered by ytt templates)

this doesnt feel like an independent tool but more of a plugin to clusterctl (if not something that ought to be handled to by clusterctl directly since for users of clusterapi, linux vs windows machine mgmt should have same UX).

Validating a windows cluster with a few simple smoke tests (wrapper to e2e.test)

this functionality may be more fitting as a plugin to https://github.com/vmware-tanzu/sonobuoy/

@jayunit100
Copy link
Author

closing

@microwavables microwavables transferred this issue from carvel-dev/carvel-community Jul 12, 2021
@microwavables
Copy link
Member

moved from /carvel-community to /carvel as we are merging the two into one

@github-actions github-actions bot added the carvel triage This issue has not yet been reviewed for validity label Jul 12, 2021
@aaronshurley aaronshurley removed the carvel triage This issue has not yet been reviewed for validity label Nov 30, 2021
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

4 participants