-
Notifications
You must be signed in to change notification settings - Fork 26
Create Unified plugin broker that merges functionality of all the plugin type specific brokers #37
Conversation
Signed-off-by: Oleksandr Garagatyi <ogaragat@redhat.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great. I'll be able to use the unified broker in the initContainer I create in the CRD controller. 1 container instead of 3 at workspace start. I'll rebase my current work on brokers on this change.
@davidfestal not sure whether it is good time to do that. We also plan to move meta download from plugin registry in unified broker. With this improvement you would be able to remove some code from CRD POC codebase |
@davidfestal @sleshchenko @amisevsk I made plugin type matching case insensitive, please take a look and approve again |
In fact I was already planning to open a very lightweight PR on plugin brokers with my local changes that allowed me to reuse them as is in the CRD Controller. I'll do it as soon as your current PR is merged: It included the promotion of the And then I plan to integrate in the CRD controller new features / refactorings of the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM still.
If we're matching case-insensitive, does it make sense to include that in some tests? E.g. the type on the added test config could be lower case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@amisevsk you are right, I'll need to add tests for that |
@amisevsk I added unit tests and couple of fixes that I was needed for testing or that I discovered along the way |
Guys I did some changes. I checked them on Che - everything works fine. I started workspace with plugins of each kind. |
This broker is capable of processing Che plugins of all types. Depending on the plugin type it calls an appropriate plugin broker implementation. Signed-off-by: Oleksandr Garagatyi <ogaragat@redhat.com>
Signed-off-by: Oleksandr Garagatyi <ogaragat@redhat.com>
Signed-off-by: Oleksandr Garagatyi <ogaragat@redhat.com>
Signed-off-by: Oleksandr Garagatyi <ogaragat@redhat.com>
Signed-off-by: Oleksandr Garagatyi <ogaragat@redhat.com>
Signed-off-by: Oleksandr Garagatyi <ogaragat@redhat.com>
Signed-off-by: Oleksandr Garagatyi <ogaragat@redhat.com>
e3b76bb
to
b0141e1
Compare
What does this PR do?
Note: This PR is designed to be reviewed in a commit-by-commit manner. Commit message of each commit explains what was changed in the corresponding commit.
Add new unified plugin broker that should co-exist with other plugin brokers for the time being.
It accepts plugin meta.yaml entries of all the types instead of type specific as other brokers do.
It sorts meta.yaml entries depending on the type and pass them to the appropriate broker implementations.
Tested locally with config.json containing all the meta.yaml entries from the repo for manual testing of other brokers.
What issues does this PR fix or reference?
Closes redhat-developer/rh-che#1304