✨ Migrate to go-plugin system for provisioners

[s3rj1k]

What this PR does / why we need it:

Migrate provisioners to go-plugin system for out-of-tree runtime BYO custom provisioner registration.

Checklist:

• Documentation has been updated, if necessary.
• Unit tests have been added, if necessary.
• E2E tests have been added, if necessary.
• Integration tests have been added, if necessary.

[metal3-io-bot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[metal3-io-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign elfosardo for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[s3rj1k]

@dtantsur This is how possible go plugin migration can look like

[dtantsur]

This is not terrible, honestly. I'd like to hear from other folks, especially those more knowledgeable in Go, but this approach looks good to me.

[s3rj1k]

This is not terrible, honestly. I'd like to hear from other folks, especially those more knowledgeable in Go, but this approach looks good to me.

If that lands, anyone could implement any (Lua, JS, Starlark, ...) interpreted runtime glue as go plugin or just directly use compiled Go code as plugin.

[Rozzii]

/cc @Rozzii

[dtantsur]

This may be a big problem in practice, and per https://pkg.go.dev/plugin it's virtually impossible to have plugins that are compiled separately from BMO itself. If so, isn't it easier to adjust the build process so that a different provisioner can be compiled in? And then add a flag to chose provisioner by name (not by its .so path)?

[s3rj1k]

You need to compile with same SDK env yes.

that a different provisioner can be compiled in

I want to ensure that we have ability to have out-of-tree plugins, not fork and add code into BMO repo

And then add a flag to chose provisioner by name (not by its .so path)?

That would mean hardcoding some specific path into BMO, I don't see any major issue with that, can be done

[zaneb]

Presumably someone could create an out-of-tree provisioner today and vendor the desired version of BMO to provide the controller (i.e. without having to fork BMO itself and add the provisioner code to it).
It seems like plugin authors would have to vendor BMO anyway in order to get the same versions of dependencies, so I guess it's not really clear to me what this is buying them.

[s3rj1k]

Presumably someone could create an out-of-tree provisioner today and vendor the desired version of BMO to provide the controller

Have you tried to do that?

It seems like plugin authors would have to vendor BMO anyway

Vendoring go.mod is not a real vendoring

I guess it's not really clear to me what this is buying them

It gives consumer ability to use officially shipped BMO release binary with their plugin as opposed to shipping a rebuild of BMO and plugin.

[s3rj1k]

In recent rebase I've added .github/workflows/plugin-test.yml workflow and Dockerfile.plugin-test so we could verify OOT flow and how vendoring is supposed to work.

I would appreciate if someone could trigger Copilot on this PR, so we could catch other possible issues

[MahnoorAsghar]

I meant to drop one comment, which failed (probably some browser issues), but 'Mahnoor started a review' is now showing up on the page for me atlease 😅