Consider splitting `pkg/provisioner/*` into golang plugins.
s3rj1k opened this issue · 12 comments
User Story
It would be nice to have plugin support for BYO provisioner by using golang plugins approach.
Detailed Description
Moving pkg/provisioner/* into golang plugins would require making go mod init on them, updating build process, adding code that will load plugins on start.
Anything else you would like to add:
Moving out stock provisioner code would also help with making statemachine part be properly isolated from provisioners.
/kind feature
It's not a bad idea, although
- at this point BMO makes so many Ironic-specific assumptions that developing an alternative provisioner is hardly possible,
- the Provisioner interface keeps evolving and won't be stable for now.
As an aside, I'd really like to extract a reusable Ironic-centric library out of pkg/provisioner/ironic and move it to a separate reusable module.
/triage accepted
/help
@s3rj1k could you please describe a bit more your custom provisioner use case ? Is it an opensource provisioner, is the provisioner already compatible with the BMO state machine (which is derived from the Ironic state machine) ?
@Rozzii:
This request has been marked as needing help from a contributor.
Please ensure the request meets the requirements listed here.
If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.
In response to this:
/triage accepted
/help
@s3rj1k could you please describe a bit more your custom provisioner use case ? Is it an opensource provisioner, is the provisioner already compatible with the BMO state machine (which is derived from the Ironic state machine) ?
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
could you please describe a bit more your custom provisioner use case
One that I used before is basically very patched Ironic provisioner and by having this plugin system I would hope to see more hard separation between logic so that any kind off-stream patched could be applied exclusively to the plugin code itself.
But really any kind of other BM provisioners could be done if plugin system would reduce the scope of implementation.
As an aside, I'd really like to extract a reusable Ironic-centric library out of
pkg/provisioner/ironicand move it to a separate reusable module.
This would be a first step, yes, this will somewhat ensure that provisioner could be more isolated, it always feels like BMO is missing this part of isolation of implementations.
Ironic-specific assumptions
IMO, state machine can be reused, some states can be just No-Op in case of other than Ironic provisioner is used.
I would like to have the ability to use any kind of cloud provider API (meaning BM offerings, not VMs that they offer) with proven to work state-machine and have all of this interchangeable, openstack <-> somethingother just by switching plugin.
So that ironic-specific things in this case can be of use.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues will close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
/lifecycle stale
/remove-lifecycle stale
/lifecycle-frozen
/lifecycle-frozen
/lifecycle frozen