feat(rfc): make operator the default install for Spinnaker

[mashby2022]

[jasonmcintosh]

Going to ask: SHOULD the operator be moved to the spinnaker project instead of the armory project as part of this?

[mattgogerly]

Going to ask: SHOULD the operator be moved to the spinnaker project instead of the armory project as part of this?

I think that probably makes sense. I've not kept up to date with the maintenance of it - does the Armory Enterprise operator depend on the open source one, or are they completely independent?

[jasonmcintosh]

Going to ask: SHOULD the operator be moved to the spinnaker project instead of the armory project as part of this?

I think that probably makes sense. I've not kept up to date with the maintenance of it - does the Armory Enterprise operator depend on the open source one, or are they completely independent?

Completely independent :)

[dogonthehorizon]

@jasonmcintosh yes, we intend to donate the armory/spinnaker-operator project to OSS as a requirement for this work :D There's some evolving thinking internally on how we manage the two operators going forward, but not ready to talk about it publicly quite yet.

[jvz]

Got a link to this operator? This space has a few competing choices there.

[dogonthehorizon]

@jvz Here you go: https://github.com/armory/spinnaker-operator

This space == Spinnaker operators, or install and configure? The intent of this RFC is to decide on the default while allowing competing options to continue :)

[jvz]

This looks like a solid project. The space was more so on the operators side, though it'd be great to work on standardizing one. The install and configure story is overly complex, and I'd love to see this simplify for common use cases like running in Kubernetes.

[jvz]

So I've got a question about this operator: would this make it easier for us to eventually introduce more microservices and potentially split up existing ones into more well-defined domains? If this makes the operational aspects of configuration and deployment of new services more straightforward than the status quo, then I'd be highly supportive of this operator idea. Sometimes, I worry that our microservices are getting monolithic in parts which has been a result of the difficulty in introducing new services to the project whether they be official services in this project or custom ones related to plugins, extensions, or whatever. If this operator approach can help address this issue, then you've got my strong support here!

[mattgogerly]

The problem I've found, and that I have with operator/Kleat/any other Kustomize based install, is that when you're operating multiple instances of Spinnaker the file structure can become extremely unwieldy with overrides across each instance.

There are other issues with the Operator (and also the Operator/Halyard combo) approach that I've encountered, that I think would need solving before it can be considered an optimal install process:

1. The operator is reliant on installing CRD(s) to the cluster on which it's running. This isn't always possible, especially for teams running on multi-tenant infrastructure where access is restricted. This is more an issue with operators in general rather than being specific to this one.

2. The operator as far as I know is still just using Halyard underneath. It's therefore still reliant on having an object store to upload profile/service settings files to, which seems a) a barrier to entry and b) somewhat unnecessary since the config files are available in the repo for each service anyway. This also means teams have to ingest multiple images to use operator.

[ksrinimba]

IMO, Operator as a concept has not taken off as much as it was anticipated. Originally, from what I understood at that time, operator was thought as a mechanism that allowed users/groups to install/upgrade software that is controlled at org-level from the UI with a click of a button.

In Spinnaker context, it kind of adds another layer of complexity and, IMHO, the benefits provided do not seem to add-up, particularly in the context of the alternatives.

All said and done, Halyard is pretty good for most of the use-cases- it processes .hal/config and other files and creates the yamls. The problem is if we need something that is not supported by Halyard, we need to workaround.

An alternative, IMO, would be what someone already mentioned: Kustomize. Gives full controll over each of the yamls. We could break-up the .hal/config into multiple files, based on purpose (accounts, artifacts, etc.) making it lot more maintainable..not everyone needs all of the account-types, artifact-types, etc. My 2 cents.