Skip to content
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

Closed
metacosm opened this issue Jan 4, 2019 · 6 comments
Closed

odo extension architecture #1173

metacosm opened this issue Jan 4, 2019 · 6 comments
Labels
kind/epic An issue categorized as a high-level Epic. Needs to be scoped and broken down in 1+ stories/tasks kind/feature Categorizes issue as a feature request. For PRs, that means that the PR is the implementation lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed.

Comments

@metacosm
Copy link
Contributor

metacosm commented Jan 4, 2019

[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 to odo itself. Extensions would work as plugins that would be dynamically loaded when the tool starts and communicate with odo 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…

@metacosm
Copy link
Contributor Author

metacosm commented Jan 10, 2019

Golang issue regarding Windows support: golang/go#19282
Golang issue regarding plugins not working correctly when using vendored dependencies: golang/go#20481

@metacosm metacosm self-assigned this Jan 10, 2019
@kadel kadel added kind/epic An issue categorized as a high-level Epic. Needs to be scoped and broken down in 1+ stories/tasks kind/new feature labels Jan 14, 2019
@sspeiche sspeiche added this to the backlog milestone Jan 28, 2019
@johnfriz
Copy link

johnfriz commented Aug 7, 2019

Hi Folks. Just wondering what the plan in to develop the plugin concept further? Is there any follow up work planned at this time?

@kadel kadel added kind/feature Categorizes issue as a feature request. For PRs, that means that the PR is the implementation and removed kind/new feature labels Sep 19, 2019
@openshift-bot
Copy link

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

@openshift-ci-robot openshift-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Apr 7, 2020
@openshift-bot
Copy link

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

@openshift-ci-robot openshift-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels May 7, 2020
@openshift-bot
Copy link

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

@openshift-ci-robot
Copy link
Collaborator

@openshift-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

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.

@girishramnani girishramnani removed this from the backlog milestone Jun 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/epic An issue categorized as a high-level Epic. Needs to be scoped and broken down in 1+ stories/tasks kind/feature Categorizes issue as a feature request. For PRs, that means that the PR is the implementation lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed.
Projects
None yet
Development

No branches or pull requests

7 participants