Include agent as a deployable component of the operator

[amcginlay]

I understand that the agent component materialised long before the operator component but, to this day, the agent is expected to be there first (if only to create the jetstack-secure namespace).

I think committed JSS customers may question why the two are not installed as a pair since they can be considered to be two halves of the same coin.

I think the behaviour of jsctl clusters connect should be to deploy the operator as necessary and then have the operator (by default) deploy the agent.

To put this another way "Jetstack Secure Agent" should appear as a JSS Component in this table:
https://platform.jetstack.io/documentation/installation/js-operator#jss-components

With this arrangement in place the CLI could (perhaps) be simplified by deprecating all operator commands. This would amount to a breaking change so it'll be less painful to do this now than later when the user base will likely be larger.

[sitaramkm]

I think the behaviour of jsctl clusters connect should be to deploy the operator and then have the operator (by default) deploy the agent.
Agree !

Additionally, something like

• jsctl clusters connect -generate-config (or something like that) should allow for config to be downloaded and edited (image location mostly - always)
• jsctl clusters connect --generate-helm (or something like that) should allow to Helmify the install

[irbekrm]

Thanks for writing this up @amcginlay !

I am imagining that it will be two commands

jsctl clusters setup (name could be different) deploys operator and in future might do some additional checks to see if cluster is ready if we think that's needed

jsctl operator installations apply - this is the existing command to apply an installation, perhaps the name could be changed to something like jsctl clusters configure . This would apply the operator config that would result in the operator deploying cert-manager, agent, policy approver and any other components and/or issuers that user has defined

This will make the cluster appear in JS UI later and if we wanted to run any checks against the cluster before attempting to apply operator's configuration to deploy cert-manager (i.e backup & restore) those would be CLI-only. I think this should be fine as I don't think a platform operator needs to look at UI at this point.

I don't know if there is a value in striving to combine these two commands - in production I imagine that folks will helm install <operator-helm-release> && kubectl apply -f <operator-configuration> from their CI pipelines rather than use jsctl. Combining these two commands would make it easier to quickly set up a a cluster, but harder to generate config for GitOps I guess.

[irbekrm]

then have the operator (by default) deploy the agent

I think that the operator should deploy all components in the same way (from Installation spec) as that provides a unified way of configuring all of them, observing any errors and what has actually be deployed to cluster- so there needs to be a step where the Installation gets applied as well.