Halyard is gone… kustomize is the way
Long ago, in a galaxy far, far at the start of the project, halyard was a tool created to make installation and management of Spinnaker easier. At the time, all the possible configuration options, the various deployment targets, duplicate configurations, etc. made Spinnaker difficult to install and operate. This has changed over the last few years, and it’s time to remove halyard from the project.
As part of this, please checkout the https://spinnaker.io/docs/releases/next-release-preview/ as there are some major changes incoming for the upcoming releases, including the removal of halyard. There WILL be more major changes coming and removals of deprecated components of Spinnaker.
First, realize that halyard was an abstraction around configuration options. I still recall the first time I ran into “what the heck” moments using halyard, where I was trying to set configuration directly, and the names in halyard had no match in the actual configuration or code used by the services. This meant that end users would get sometimes conflicting results on their configuration and had to dive into multiple locations to determine what to set, which file, which property name, or even what values could work. It made figuring out how to configure Spinnaker VERY difficult.
Get Jason McIntosh’s stories in your inbox
Join Medium for free to get updates from this writer.
What’s worse was that with halyard, there wasn’t a well documented method to store and deploy your configurations. Many users would implement custom storage of the halyard folder, then runjobs or custom tooling to deploy it afterwards. Halyard was a service and CLI tool and made deploying spinnaker non-standard. Armory (now harness) produced an operator to wrap halyard in a CRD that could be deployed like any other manifest, and though popular and enabled a more git focused configuration approach, it kept the same problems that halyard had — custom abstractions, complexities of those abstractions, etc.
Next, ADDING those abstractions, maintaining them took a lot of time and energy. These would continuously add complexities to release of new features or configuration options that rapidly made simple changes difficult, and unmaintainable. This abstraction and the non-matching of configuration properties caused a lot of issues for users over the years. It didn’t support a good gitops style flow of configuration, failed to handle a lot of edge cases, made deploys take longer, etc.
Last, with recent enhancements (particularly AI) — and with a focus on Kubernetes as the primary supported deployment target, plus revamped docs and configuration options, it’s gotten much simpler to install Spinnaker. With a clean cluster, you can have a running installation of Spinnaker in about 10 minutes today and deploying shortly after that. Halyard is no longer needed, as the default installation to kubernetes is simple, clean and fast. Every advanced user of Spinnaker that we know of has already long since moved to native deployments instead of using Halyard.
What hasn’t changed is the complexities of certain configurations. Authentication configuration is inherently complex REGARDLESS of halyard OR Kustomize… as every auth solution is slightly different. Configuration for all the options for everything Spinnaker can do is… difficult, but we’re doing our best to document now in the docs site and in the https://github.com/spinnaker/spinnaker/tree/main/spinnaker-kustomize repository the configuration settings and information required to setup and manage Spinnaker, as well as patterns you can use as needed for your own deployment of Spinnaker. The docs site ALSO got a major revamp which should make finding and configuring the settings in Spinnaker MUCH simpler. We’d welcome additional documentation to make this even better!
We’ve been calling out halyard as deprecated for multiple years. With https://github.com/spinnaker/spinnaker/pull/7865 it’s finally removed from the project. Please let us know (join the spinnaker slack!) if you have issues, questions, concerns. Existing halyard installs SHOULD continue to work. We’ll continue to publish Spinnaker BOM’s that halyard can consume for the time being, but the project is progressing beyond it’s roots. It’s time to clean up some of the technical debt we’ve encountered along the way.
