Velero: Move existing cloud provider plugins into their own repo

[nrb]

The plugins that are currently in tree should move out into their own repo for parity with the other providers. (see #1525 and this slack conversation for example)

This also means that plugins can be iterated on separately from the core codebase.

[nrb]

Some code changes that will need to happen to help accomodate this:

• Enhance velero install do plugin installation at deploy time, and make sure it supports all plugins.
• Enhance the Helm chart to support plugin installation at deploy time.

[skriss]

It might make sense to have a separate repo per provider -- that way each binary/image can be as small as possible and limited to a single provider's SDK.

[nrb]

De we want to keep the logic that adds velero.io to any plugin name that isn't namespaced with this change? An example

[skriss]

@carlisia assigning this to you. I would definitely like to see a plan/design written up for this as there are a bunch of moving pieces. It may make sense to have one plan/design doc for this, #1740, and #1774 since they're all going to be related.

[skriss]

Things to think about off the top of my head:

• what's the repo structure? (repo per provider, etc)
• build/release process changes?
• where do docs live?
• are there any places outside the plugins where we depend on the cloud-provider SDKs? can we eliminate those dependencies too?
• what does the upgrade path look like for users currently using the in-tree plugins?

[nrb]

Another question: are we moving _just_ the cloud provider plugins out?

I think some plugins, such as the pod -> pvc -> pv backupitemaction ones, make sense to stay in the core repo as they provide some important logic that just happens to be implemented in a plugin.

[skriss]

I personally don't really see any reason to move the item action plugins out, interested to hear others' thoughts.

[carlisia]

Thanks for these initial guidelines. Makes sense to me. 👍

[carlisia]

Also: "each separate repo for plugins will need to push to the same image repo".

[carlisia]

Question: should we use go modules with the new plugin repos? This made me think about it: https://twitter.com/markbates/status/1172869341026627584

c/c @skriss @nrb @prydonius

[nrb]

I'm not convinced there's much to gain by moving to modules at the moment. Also, it would seem strange to me to have those repos use go modules but not Velero.

As mentioned in that thread, gopls is still not quite ready - I know I've heard many developers say they've dropped VSCode/gopls for GoLand until gopls is in a better state.

All that said, I need to do more research. I view the tweet as an anecdote, and I need to gather more information.

[skriss]

@carlisia I'm going to consider this done and close out - only thing that's technically left in here is Helm chart docs, but you're working on that and it's not blocking this from being done.

[carlisia]

Cool 👍