feat(rfc): RFC to replace Halyard #89
Conversation
The current recommended way to deploy Spinnaker is by using Halyard. While Halyard has greatly simplified some aspects of installing and configuring Spinnaker, it has a number of shortcomings that are particularly apparent when deploying to Kubernetes. This document proposes replacing Halyard with a smaller tool that integrates better into the Kubernetes ecosystem.
ezimanyi
requested review from
ajordens,
ethanfrogers,
plumpy and
robzienert
as code owners
There was a problem hiding this comment.
Excellent work @ezimanyi! I can't wait to see where this takes us in the future. I'm sure you've planned for this but I'd love to see us talk about this in the Kubernetes SIG and get a sense for how much of a lift it would be for those users to migrate.
| this would reduce both the maintenance burden on Halyard and the barrier to entry | ||
| to Spinnaker for users familiar with these tools. | ||
|
|
||
| ### Dynamic configuration |
There was a problem hiding this comment.
What is Spring Cloud Config's approach to the GitOps/IAC motivation @ethanfrogers mentioned above?
There was a problem hiding this comment.
I think in general the approach is that config files can live in a source repository, and the running service can directly reference that repository. In general, that works fine, as the config can be directly edited in the desired repo then be picked up by the service.
Where this doesn't interact well with Halyard is that it generates the service configs as transient files and then directly applies them; the generation of config is coupled to the deployment of that config. After the changes in this RFC, I could imagine someone wanting to use Spring Cloud config deciding to commit the files generated by Halyard Lite to a config repo. So the workflow would be:
- Edit the checked in hal config
- As part of the build step, run Halyard Lite to generate service configs, and also check those in
- Commit the full changes
Then when you deploy services, instead of deploying configs alongside them, just point them at your repo.
Let me know if this answers the question!
| configs as well as (possibly) some metadata about the Spinnaker deployment (ex: the versions | ||
| of containers to pull) but the exact format will be determined in concert with early consumers. | ||
| * The exact format of the Helm chart and Kustomize kustomization that will be provided to support | ||
| installation to Spinnaker remains unspecified. |
There was a problem hiding this comment.
Also: How do we correctly communicate that, yes, Spinnaker is k8s native via this work, without making non-k8s users feel abandoned or pressured to move onto k8s.
There was a problem hiding this comment.
One of my hopes with the stats collection is to be able to quantify these groups - how many deployments are going against which providers.
There was a problem hiding this comment.
I'm not sure I follow - are you implying that we're hoping k8s has significant enough adoption we don't need to address the rest?
There was a problem hiding this comment.
I've added a point to "Non-goals" to explicitly state that this document does not intend to deprecate non-Kubernetes install pathways (even as it focuses on making Kubernetes installs easier).
| individual microservices do have access to. | ||
|
|
||
| Halyard will reduce the scope of its validation efforts. It will focus on | ||
| validating the well-formedness of the Halyard config, but will no longer |
|
Love it, thanks for the detailed RFC @ezimanyi. |
| and make requests using them. Validating the well-formedness of the config will | ||
| involve both: | ||
| * Validating the structure of the config | ||
| * Performing simple validation on the values supplied in the config, such as |
There was a problem hiding this comment.
Halyard also performed some additional simple validation that doesn't fall into the well-formedness or auth* categories:
+ Get current deployment
Success
+ Get persistent store
Success
Validation in default.persistentStorage:
- WARNING Your deployment will most likely fail until you configure
and enable a persistent store.
Will simple checks like this still be in scope?
There was a problem hiding this comment.
I think checks like that would be in scope; I suppose that's a bit broader than just checking each individual value, but I could imagine things of the type "you must have at least one of X" configured would be in scope.
The current recommended way to deploy Spinnaker is by using Halyard. While Halyard has greatly simplified some aspects of installing and configuring Spinnaker, it has a number of shortcomings that are particularly apparent when deploying to Kubernetes. This document proposes replacing Halyard with a smaller tool that integrates better into the Kubernetes ecosystem.