You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following that, there might be more. Users will want to define what might happen during the act of promoting. For example, they may need to open and close a JIRA/ServiceNow ticket as part of affecting the environment.
Kargo should allow provide an extensible way to allow users to define what happens during the act of promoting.
The way I imagine this working is similar to how ConfigManagementPlugins (v2) work in Argo CD where we allow users to package their own tooling into a container, which we would run as a sidecar to the promotion controller, and invoke commands from inside the user-defined container as part of the promotion process via an RPC interface that we define.
The text was updated successfully, but these errors were encountered:
Agree in the need. Very intrigued by the suggested approach.
Was talking with @shelby-moore and @evgeny-goldin yesterday about extending Bookkeeper's capabilities, and by extension, Kargo's...
Something I keep coming back to is a security concern over execution of arbitrary user-defined workloads in-process.
With the approach you suggest, it would be the cluster op/admin who configures and installs Kargo who is "blessing" specific tools, scripts, etc. and making those available to leas privileged users.
Love this idea. It may be a viable strategy for solving a few different problems.
Today we support a handful of promotion mechanisms. Some things that happen as part of a promotion include:
kustomize edit set image
or equivalentFollowing that, there might be more. Users will want to define what might happen during the act of promoting. For example, they may need to open and close a JIRA/ServiceNow ticket as part of affecting the environment.
Kargo should allow provide an extensible way to allow users to define what happens during the act of promoting.
The way I imagine this working is similar to how ConfigManagementPlugins (v2) work in Argo CD where we allow users to package their own tooling into a container, which we would run as a sidecar to the promotion controller, and invoke commands from inside the user-defined container as part of the promotion process via an RPC interface that we define.
The text was updated successfully, but these errors were encountered: