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

Helmsman roadmap #321

Closed
sami-alajrami opened this issue Oct 25, 2019 · 18 comments
Closed

Helmsman roadmap #321

sami-alajrami opened this issue Oct 25, 2019 · 18 comments
Labels
stale The issue has not been active for more than 90 days and maybe no longer applicable.

Comments

@sami-alajrami
Copy link
Contributor

@luisdavim @mkubaczyk (and others), I have drafted a document outlining a potential roadmap for improvements and new features in Helmsman as it moves to support helm v3.
https://docs.google.com/document/d/1tpOnR_DvVUczJQFnnY9FCAYaFn55PqWURmNFdzh-pHk/edit?usp=sharing

I would love your feedback and input on this and we might schedule a hangout to finalize it and break it down into backlog tasks and milestones.
The aim is to help guide community contributions towards a common goal.

@mkubaczyk
Copy link
Collaborator

I really like the idea of drawing a map for the product. While Helm v3 will change drastically the way helm works, since we have helm-tiller on the board, the changes will mainly focus on removing redundant tiller-aware part of code. I've started working on it, but some more important things came up and had to stop my work.
I'm up to prioritze the features you've marked and also reorder them in form of descending "coolness" for users.

@mkubaczyk
Copy link
Collaborator

I'd also go through all the issues still open and close most of the ones being inactive or not confirmed to get broader view of current state

@luisdavim
Copy link
Collaborator

luisdavim commented Oct 25, 2019

Looks good to me, only one concern about enforcing the GitOps model, my current use case for Helmsman is no GitOps. I have a controller that manages a desired state CRD and generates k8s jobs that run Helmsman to apply the state, one desired state per namespace. And I use the tillerless mode for this.

@luisdavim
Copy link
Collaborator

I was going to work on some cleaning and refactoring but if you're already working on helmv3 it might conflict. My plan was to convert some of the functions into object methods of the release and desired state objects and maybe group some of the code into packages.

@mkubaczyk
Copy link
Collaborator

@sami-alajrami I'll need some help with preparing CI for helm 3. Maybe even an access for me to circleci and other places that would help do that?

@sami-alajrami
Copy link
Contributor Author

@sami-alajrami great to see the momentum going on that .. I am not sure I can sort the circleci access since it's tied to Github organization.
I won't be available much until Friday next week .. but if you need my help for specific tasks, I will try to help as quickly as I can. I think my help would be needed to push a new helmsman-test image if needed and for setting env vars and other settings in circleci. The rest should be doable directly in the repo. And circleci job logs should be publicly available.
I plan to dedicate Friday 20th and the weekend after to help here. But will try to help earlier if you need any CI support. Just tag me along!

@mkubaczyk
Copy link
Collaborator

mkubaczyk commented Dec 10, 2019

@sami-alajrami yes, the bare minimum would be unblocking the CI parts for helm v3 with proper test image to run tests against helm 3.
And then we’d need a way to start releasing betas and rc for helmsman with helm 3 support.
I’d skip helmsman 2.x version and go directly for 3.0.0 to be planned. I’d also move current master branch to some helm2 legacy one (to keep it and provide fixes for) and make new helmsman 3 a master branch to start releasing betas as quickly as possible. :-) just let us know how to operate and how you see it

We can’t afford missing this sweet spot where people are starting to choose their deployment manager for helm 3 :-)

@sami-alajrami
Copy link
Contributor Author

Sounds good to me .. I think you can do the branch changing whenever you feel the helm 3 is taking shape (perhaps do it right away - create a helmsman 1.x branch from master and push it, then merge your PR when it's ready) and we carry on development from there on master.
We will need to update the circleci config for maintaining the two branches, but I guess configuring the helm2 branch pipeline can wait til next week. We should focus on master (helm3 ) for the next few days.
If you have a new dockerfile for the helmsman-test image, push it somewhere and I will build and push the image so that it's usable in CI.

@mkubaczyk
Copy link
Collaborator

Thank you for engagement. I think we can try out the image from test files from branch holding the v3, it has just updated helm to 3 and one plugin, no additional changes were needed

@sami-alajrami
Copy link
Contributor Author

praqma/helmsman-test:helm3 is now pushed based on the dockerfile in your PR.

@mkubaczyk
Copy link
Collaborator

great, finally got tests passing for the first time :-)

@mkubaczyk
Copy link
Collaborator

@sami-alajrami build on dockerhub for newest commit (which is merge of helm-v3 branch) has failed and I can't even see what was wrong. Will you help please sort it out? :-)

@sami-alajrami
Copy link
Contributor Author

it was a temporary glitch in CircleCI , a reRun without changes has worked fine.

@badeball
Copy link

Introduce an import option in the DSF to import other DSFs from local directory or other git repos.

  • This will help us introduce some best practice for deploying several apps/stacks to a single cluster by different teams from different git repos.

Absolutely loving this. I've been looking into different ways of doing ephemeral clusters for local development in a distributed architecture. Tested out armador, but eg. the lack of branch support makes me hesitant.

@kferrone
Copy link

Any chance to consider loading non Helm manifests? For example if some service has a url and all you have to do is kubectl apply -f https://someurl.com/somemanifest.yaml. Maybe this helmsman could simply load some ad-hoc configs just because . . .
Maybe we just have some non helm files in the same repo as one which will use the helmsman. Sure don't want to bash file those and then bash file the helmsman. But for now, I will bash file them.

@sami-alajrami
Copy link
Contributor Author

@kferrone that is tracked in #360 .. I am working on this issue and will create a PR soon.

@kferrone
Copy link

@kferrone that is tracked in #360 .. I am working on this issue and will create a PR soon.

Oh wow! Ya'll are on top of it. Goodbye really big bash file!
Thanks

@github-actions
Copy link

This issue has been marked stale due to an inactivity.

@github-actions github-actions bot added the stale The issue has not been active for more than 90 days and maybe no longer applicable. label Aug 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale The issue has not been active for more than 90 days and maybe no longer applicable.
Projects
None yet
Development

No branches or pull requests

5 participants