Feature Request: Create a third-party folder for company specific code/implementations

[corbantek]

Feature Description

Due to the nature of how golang has to build in a monolith (at least for each cobra exec) we need a way to allow third-party features, implementations, and add-ons to be run with Vitess.

This idea was discussed last fall here.

For the implementation of using third-party code, I want to specifically NOT use native go "plugins", go-plugin, or pluginprc which all rely on some form of RPC communication with the parent process. I think for keeping performance at a maximum, we would not like to add the extra layer of communication to the runtime.

The general idea is:

• Create folder in go called "thirdparty"
• Inside this folder is a go file called thirdparty.go that has a public initialize function that is empty for base vitess (no-op when called)
• This folder by default is gitignored
• Third parties would copy their implementations/features into this thirdparty folder for their respective build systems
• Any required initializations would be added to the public initialize function in thirdparty.go (this is maintained by the thirdparty, not upstreamed to vitess)
• Vitess base would/could add calls this public initialize function from an init() inside the respective cobra impls (IE vtgate, vt, ...)

This feature has a base implementation in Add the concept of thirdparty impls to Vitess

Use Case(s)

HubSpot has traditionally forked Vitess for each release and then applied a large amount cherry-picks and code changes to augments Vitess for HubSpot usage and infrastructure.

This task is not lightweight and requires weeks of cherry-picking, merging, and testing on top of keeping track of what are Vitess changes vs HubSpot changes. This makes upgrades extremely difficult and upstreaming fixes harder because we cannot test on different branches (only the current branch we have deployed).

We'd like to let our code move between releases without having to cherry-pick hundreds of commits each time. Having all our code in a separate repo that is copied into the thirdparty would have several advantages

• Know exactly what is HubSpot vs Vitess changes
• Ability to switch between current releases and main
• Continuous integration and testing on interested branches and main
• Ability to provide and test upstream fixes on both current branch and main branch

PRs

Add the concept of thirdparty impls to Vitess