Discuss the behavior of operator-sdk build about operator-sdk

[theishshah]

Sample of how this can work:
operator-sdk build <image> will behave as is.
operator-sdk build <image> <path_to_template> will build the operator.yaml with a custom template

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{.ProjectName}}
spec:
  replicas: 1
  selector:
    matchLabels:
      name: {{.ProjectName}}
  template:
    metadata:
      labels:
        name: {{.ProjectName}}
    spec:
      containers:
        - name: {{.ProjectName}}
          image: {{.Image}}
          ports:
          - containerPort: {{.MetricsPort}}
            name: {{.MetricsPortName}}
          command:
          - {{.ProjectName}}
          imagePullPolicy: Always
          env:
            - name: WATCH_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
            - name: {{.OperatorNameEnv}}
              value: "{{.ProjectName}}"

A template can look like the above, with whatever custom information that needs to be added can be placed in that template file and the operator.yaml will be generated from that

[fiftoine]

Case :
When developing operators locally with minikube docker env (eval $(minikube docker-env)), the operator image can't be pulled because of the imagePullPolicy set to Always.

A solution is to change the imagePullPolicy to IfNotPresent.

The operator-sdk build $IMAGE should allow to customize the generated operator.yaml containing a specific value for imagePullPolicy (I supppose it could do it for the full operator.yaml)

Proposed behavior 4:

Having different templates for the operator.yaml having profile awareness passed to the operator-sdk build $IMAGE. Something like operator-sdk build $IMAGE -p dev. It would then use the template operator-dev.yaml

One could then customize operator-${PROFILE}.yaml and use it depending on the environment it's build on.

[nicksantamaria]

I have some environment variables added to the deployment in operator.yaml which allow modifying certain behaviors of the operator.

The current behavior or operator-sdk build overwriting this file makes providing sane defaults and examples for overriding impossible.

[fanminshi]

@nicksantamaria we are aware of this issue. To circumvent this issue for now, you can copy the first operator.yaml after the first build to a new <your>.yaml. Then use <your>.yaml for any further operator deployment.

[fanminshi]

@theishshah how are values {{.ProjectName}}, {{.Image}}, and so forth being obtained? How are those those values being pass-in to the template?

[theishshah]

All the values other than {{.Image}} are provided from the k8sutil and the pkg/generator code. Image comes from the command argument.

[fanminshi]

@theishshah Suppose that the user wants to add additional custom fields to their templates.

e.g:

  ...
  env:
  - name: <Your ENV Var>
    value: <Your value>

How do they achieve that with your proposed plan?

[theishshah]

Been thinking about this for the last day, just came to realize that if a custom field is being supplied in the template, the value can just be coded into the template as the user will know the value whether they put it in the template or pass it in as an arg to the build command, correct?

[fanminshi]

the value can just be coded into the template this approach works. However, it seems to me that the user experience might be strange. For instance, there are fields {{.ProjectName}} and {{.Image}} will be populated by the sdk tool. But how does the user know which keyword will be populated by the sdk tool. Also it seems to me that the user never needs to defines new fields; the user can just hardcode the custom fields.

pass it in as an arg to the build command, If we are going with this approach. we need to define the format of arg and how it affects the output. Also if we can just hardcode the custom fields in the templates, why do we need to pass in the values as args?

Overall, I think that the user experience matters a lot for this. I'd suggest to try different approach to get a feel how the workflow is.

[theishshah]

"The tool now works such that if a operator.yaml exists no new file is generated. This allows either a fully custom file to be created before the build command, or for a file to be modified in between builds without being over-written. If the image name changes between builds it is the user responsibilty to update that in the file. " - Comment on PR #364.

[shawn-hurley]

So I really liked the idea of a template, call it operator.yaml.tmpl or whatever and I can pass it to the command (via a path), and then the command uses the image name, to generate a new operator-.yaml file. If that file exists then you should overwrite it. If no template is specified then you do the above behavior IMO.

I think the above would be a happy medium between simple starter use cases and more advanced use cases where I want to template out, but create multiple images. As for the template values, I would suggest just documenting the template can only add the {{.ProjectName}} and {{.Image}}.

@fanminshi @theishshah thoughts?

[fanminshi]

@shawn-hurley I think tying deploy.yaml to the operator-sdk build command can be complicate as I have mentioned from #84 (comment). I think it is much simpler if the operator-sdk new command generates a default operator.yaml or operator.yaml.tmpl with the image field to be filled and let it not tied to the operator-sdk build command. In that way, we expect that the users to manage the operator.yaml themselves and also to make clear distinction that the operator-sdk build has nothing to do with it. Furthermore, operator-sdk build should only be responsible for building the operator image.

[theishshah]

PR #364 merged