-
Notifications
You must be signed in to change notification settings - Fork 244
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
odo
extension architecture
#1173
Comments
Golang issue regarding Windows support: golang/go#19282 |
Hi Folks. Just wondering what the plan in to develop the plugin concept further? Is there any follow up work planned at this time? |
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
Rotten issues close after 30d of inactivity. Reopen the issue by commenting /close |
@openshift-bot: Closing this issue. In response to this:
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. |
[kind/Feature]
Which functionality do you think we should add?
Adding an extension mechanism for
odo
would allow interested third-parties to extend the tool to suit their own needs without needing features to be added toodo
itself. Extensions would work as plugins that would be dynamically loaded when the tool starts and communicate withodo
via an event system over an event bus to be able to have decoupled extensions implemented as listeners of events produced at different stages of command execution. Commands would thus be able to push events during different stages of their execution (e.g. pre-run, post-complete, post-validate, post-run). The bus will allow interested third parties to register listeners to react to events and possibly interrupt the command processing based on this (by returning a specific error type, which will allow the bus to abort the command processing and notify listeners that might have already performed some process based on the event to revert their work).Why is this needed?
Not strictly needed but would be a nice to have feature. This could, in particular, allow runtimes to customize
odo
's behavior to account for their specificity or make it easier to implement a scaffolding feature to more easily bootstrap projects. Another idea could be to use a listener to play the commands the user triggers on different clusters than the one the user is logged to…The text was updated successfully, but these errors were encountered: