-
Notifications
You must be signed in to change notification settings - Fork 79
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
Proposal for enhanced default processor to handle user-defined artifact like Machine Learning artifacts #143
Proposal for enhanced default processor to handle user-defined artifact like Machine Learning artifacts #143
Conversation
33e62b1
to
258bda8
Compare
Proposal Preview: proposals/artifact-processor-extender.md /cc @zhujian7 @gaocegege @hainingzhang /assign @xaleeks @steven-zou |
258bda8
to
ace1fda
Compare
Hi, Thanks for the proposal. I find the framework proposed here may be a bit over-engineering at least for current requirements. It also introduces new attack-surface, for example the robot accounts in the external processors may be leaked and a malicious user can use it to pull artifacts from Harbor. If we define a schema in the config blob of an artifact, it seems the processor extender is not very necessary? i.e. if a in-tree processor and extract data as a pre-defined contract the artifact developer will only have to write the config JSON object in a certain format, then he will not need to implement his processor and we don't need to introduce yet another framework to manage external service registration in Harbor? |
Currently, it may work. In our use case, we now just have one possible addition: README. In the future, we will support a new type We can have the detailed dicusstions in the community meeting today 🍻 We are open to the decision. If the community members think it is too far, we can keep a in-tree common processor instead. |
@reasonerjt After a detailed review, I think in-tree processor is also one possible approach. We will refine the proposal soon. |
d02cf2d
to
af8eafb
Compare
f5517b2
to
e17617f
Compare
e17617f
to
f3f79c9
Compare
f3f79c9
to
7349e0a
Compare
c28fb4b
to
ffa1ed1
Compare
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.
comments
|
2e5ebbf
to
ad8945f
Compare
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
The PR is merged, please update the proposal according to our implementation @hyy0322 👍 |
Signed-off-by: Yiyang Huang <huangyiyang@caicloud.io>
Signed-off-by: Ce Gao <ce.gao@outlook.com>
Signed-off-by: Ce Gao <ce.gao@outlook.com>
Signed-off-by: Yiyang Huang <huangyiyang@caicloud.io>
Signed-off-by: Ce Gao <gaoce@caicloud.io>
Signed-off-by: Ce Gao <gaoce@caicloud.io>
Signed-off-by: Ce Gao <gaoce@caicloud.io>
Signed-off-by: Ce Gao <ce.gao@outlook.com>
Signed-off-by: Ce Gao <ce.gao@outlook.com>
Signed-off-by: Yiyang Huang <huangyiyang@caicloud.io>
Signed-off-by: Ce Gao <gaoce@caicloud.io>
Signed-off-by: Ce Gao <gaoce@caicloud.io>
Signed-off-by: Yiyang Huang <huangyiyang@caicloud.io>
Signed-off-by: Yiyang Huang <huangyiyang.huangyy@bytedance.com>
ad8945f
to
a07d255
Compare
Proposal updated. |
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.
approved
According to the lazy consensus principle, merge this proposal PR. The feature will be delivered in V2.1. |
Signed-off-by: Yiyang Huang huangyiyang.huangyy@bytedance.com