Add 'CreateInstalledPackage' impl

[antgamdia]

Description of the change

Initial implementation of the CreateInstalledPackage operation

Benefits

An initial and very limited Carvel support in Kubeapps

Possible drawbacks

N/A

Applicable issues

• related Carvel package support in Kubeapps #3221

Additional information

N/A

[absoludity]

Why not pull out the target cluster as well? Currently it looks like it's just assuming the available package cluster. AFAICT, we don't lose anything by assuming multi-cluster support here, rather than explicitly not supporting it?

[absoludity]

Hmm, I wonder if we should do this later in the process before s.createPkgInstall (or even after it, depending on how carvel handles that situation - I assume it'll see the secret as soon as created but we'd have to check). Main thing being to minimize the chance that we create the secret and leave it dangling if the other parts fail.

Actually, it could be simpler that we also clean up the secret if any other error occurs. I'd think we'd need to do this anyway otherwise the next creation would fail (unless you're avoiding collisions on the secret name). Even if not, we still should clean up imo.

[antgamdia]

Good point! I'm moving the secret creation right before the s.createPkgInstall + adding a TODO to check if we really need to have the secret in advance (I'd say it is possible, but perhaps we will have to wait for an additional reconciliation cycle, but not sure).

[absoludity]

Haha - there you go :P. Yes, I guess either way (ie. even if we clean up secrets on failed installs) we'll still need to handle creating a unique name for the secret given we can't avoid users creating secrets with specific names.

Not related to this PR, but we may eventually want to support people using an existing secret for values rather than entering values.

[absoludity]

Yeah, it's Carvel's way of supporting deployments across clusters (without having kapp-controller on those other clusters). I've chatted with the carvel team about this. My concern is that with this you're relying on secrets on the cluster that give very permissive RBAC to another cluster. Their response was that this is how others (kubernetes dashboard) do things, and that the secret is no worse than a service account for this cluster (which yes, it may be in some cases limited to a specific namespace etc., but it's a level up from RBAC imo).

As it is, with our UX we'd be assuming kapp-controller on the other cluster and talking to it with the users creds as normal. I don't think we have to support this case of deploying to another cluster without kapp-controller being installed there, at least yet.

[antgamdia]

Thanks for the context here, really useful!! When I saw it for the very first time I thought -oh, out-of-the-box multicluster! - but then I noticed it wasn't what I expected, haha.
I've added a note in the code pointing to this comment.