wmedvede commented on code in PR #255:
URL:
https://github.com/apache/incubator-kie-kogito-serverless-operator/pull/255#discussion_r1335597892
##########
api/v1alpha08/sonataflow_types.go:
##########
@@ -24,6 +24,535 @@ import (
"github.com/kiegroup/kogito-serverless-operator/api"
)
+const DefaultContainerName = "workflow"
+
+// FlowContainer is the container for the internal workflow deployment based
on the default Kubernetes Container API
+type FlowContainer struct {
+ // Container image name.
+ // More info: https://kubernetes.io/docs/concepts/containers/images
+ // This field is optional to allow higher level config management to
default or override
+ // container images in workload controllers like Deployments and
StatefulSets.
+ // +optional
+ Image string `json:"image,omitempty" protobuf:"bytes,2,opt,name=image"`
Review Comment:
Another silly question. So, if the user configures an image here, the
operator will basically skip the image generation for that workflow, and just
grab the configured one, right?
Which use case are we trying to cover with this?
I mean, looks like a very advanced situation where the build was produced
completely outside the operator scope, no warranty that the image even
corresponds to a workflow, so this why I'm asking, I which situations people
might want to do that? optimizations maybe?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]