Misc. comments on outer-loop proposal

/area api
(sorry not sure how to best label this)

Comments on existing doc

1.

As mentioned in the Google doc comment, the syntax

        attributes: 
          - name: CONTAINER_IMAGE
            value: {{myimage}}

wouldn't allow Devfile variable substitution, it would need to be more like:

        attributes: 
          - CONTAINER_IMAGE: {{myimage}}

suggestion

If 'attributes' generally refer to free-form YAML, in devfile, a better name might be deployVariables:

        deployVariables: 
          - CONTAINER_IMAGE: {{myimage}}

2.

In the example in https://github.com/devfile/api/blob/main/docs/proposals/devfile/outer-loop-build-and-deploy.md#example-of-kubernetes-deployment-manifest with:

      spec:
        containers:
          - name: {{.COMPONENT_NAME}}
            image: {{.CONTAINER_IMAGE}}
            ports:
              - name: http
                containerPort: {{.PORT}}
                protocol: TCP

it is clear that {{.CONTAINER_IMAGE}} comes from the CONTAINER_IMAGE attribute on the deploy command. But what about {{.COMPONENT_NAME}} and {{.PORT}} ? Are these supposed to be other attrs not shown in the example snippet? Are they more like "built-ins"? Do they imply other Go template or Helm template functionality? Are they generically "derived" from other devfile structures ? A lot could be read into that ;)

3.

For the image build, I assume the "args" representing any and all options e.g. to docker build, not just --build-arg options?

E.g. I might have this:

          dockerfile:
            buildContext: ${PROJECTS_ROOT}/build
            location: https://github.com/redhat-developer/devfile-sample/blob/master/src/Dockerfile
            args: [ "--build-arg", "arg1", "--label", "L1" ]

It seems tempting to maybe pick some options, like "label" and "promote" them into yaml... but I'm not sure how we decide which, so maybe not.

4.

What do we envision the composite command including both an image build and a deploy to look like? I'm thinking it's a separate deploy command, which let's say is the default deploy command, e.g. maybe something like this:

    components:
      - name: myk8sdeploy
        kubernetes:
          uri: deploy/deployment-manifest.yaml

    commands:
      - id: deployapply
        apply:
          component: myk8sdeploy
          group:
              kind: deploy
              isDefault: false
        attributes: 
          - name: CONTAINER_IMAGE
            value: {{myimage}}
      - id: build-and-deploy
        composite:
            commands:
              - deploybuild  # not shown, from earlier example
              - deployapply
            group:
                kind: deploy
                isDefault: true
            parallel: false

Alternative suggestion

The use case where I primarily want to do an outer loop image build and deploy, and never care to just automatically build the image on "start" seems a bit verbose.

What if we disable the auto build on start with a new autoBuild: false property and add a new "imageComponent" property to reference the image component as a kind of "dependency" ?

So something like:

    components:
      - name: mydockerfileimage
        image:
          imageName: {{myimage}}
          autoBuild: false     # new property to turn off auto build (assuming it's still defaulted to true)
          dockerfile:
              location: Dockerfile
            
    components:
      - name: myk8sdeploy
        kubernetes:
          uri: deploy/deployment-manifest.yaml

    commands:
      - id: deployk8s
        apply:
          component: myk8sdeploy
          group:
            kind: deploy
            isDefault: true
       imageComponent:   mydockerfileimage
       deployVariables:           # if 'attributes' are generally free-form, it's confusing to have string types only here:
          - CONTAINER_IMAGE: {{myimage}}         # incorporating the other change

I feel like using a composite command adds some verbosity without being any conceptually clearer. (It is already kind of a less-than-perfect fit I think to have this image component which looks like a command).

If we're just inventing a new type of deploy command can't we say that its scope bridges multiple components?

@elsony

@elsony

        attributes: 
          - CONTAINER_IMAGE: {{myimage}}

+1, will fix

it is clear that {{.CONTAINER_IMAGE}} comes from the CONTAINER_IMAGE attribute on the deploy command. But what about {{.COMPONENT_NAME}} and {{.PORT}} ? Are these supposed to be other attrs not shown in the example snippet? Are they more like "built-ins"? Do they imply other Go template or Helm template functionality? Are they generically "derived" from other devfile structures ? A lot could be read into that ;)

They are supposed to be attrs not shown in the example snippet. All attributes in the kubernetes yaml are supposed to be provided by the attributes when calling the apply command. I'll update the example to reflect that.

For the image build, I assume the "args" representing any and all options e.g. to docker build, not just --build-arg options?

Yes, args are for the image build, e.g. docker build. This provides a way for users to customize the command when building the image.

If you want to explicitly create a composite command to chain build and apply, the sample snippet that you provided will be correct. Having said that, we should be able to reuse the same approach as the container start in a build command to simplify the usage without explicitly introducing the autobuild: false field.

This is related to the requirement on the design doc. In the apply command using the deploy group, it links to the image component. The tools already know it needs to use the image component that has not been built before so the tools should be able to implicitly invoke the image build to the build image component without explicitly create a composite command.

For 1., I think we should consider more than changing the example attributes showing an instance of a free-form type, which happens to use a string value:

 attributes: 
      - CONTAINER_IMAGE: {{myimage}}

If the intended use case involves a string substitution, should we create a new string-typed field:

 commandVariables:     # or variables, or deployVariables?
      - CONTAINER_IMAGE: {{myimage}}

For 3., I think it would help to elaborate and spell it out in a bit more detail to show we're combining the args and the other fields in a build-tool specific way.

E.g. what about this change: 211cda2

    variables:
      myimage: myimagename
    components:
      - name: mydockerfileimage
        image:
          imageName: {{myimage}}
          dockerfile:
            buildContext: ${PROJECTS_ROOT}/build
            location: Dockerfile
            args: [ "--no-cache", "--build-arg", "arg1=abc", "--label", "version=1.0" ]
            rootRequired: false

...

Note:

The build tool/mechanism, e.g. buildah/kaniko, used for building the dockerfile is up to the specific devfile tool, which will define a build using a custom, straightforward mapping from the devfile image component definition to a build command for the specific build tool. E.g. for docker build the above example might map to a command like:
docker build -t {{myimage}} --no-cache --build-arg arg1=abc --label version=1.0 ${PROJECTS_ROOT}/build -f Dockerfile
(with substitutions applied)

I recall we said we would try to avoid needing any new attributes or variables and just use the top-level devfile variables..and be sure to allow them to be substituted in deploy use cases by the various tools.

@elsony

Since outer-loop scenarios have been adopted since v2.2.0 we will need to review to see if there is anything from here that since needs addressing.

cc: @elsony

This issue is stale because it has been open for 90 days with no activity. Remove stale label or comment or this will be closed in 60 days.

Navigation Menu

Repository navigation

Misc. comments on outer-loop proposal #517

Comments on existing doc

1.

suggestion

2.

3.

4.

Alternative suggestion

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Misc. comments on outer-loop proposal #517

Description

Comments on existing doc

1.

suggestion

2.

3.

4.

Alternative suggestion

Activity

scottkurz commented on Jun 29, 2021

elsony commented on Jul 16, 2021

scottkurz commented on Jul 20, 2021

scottkurz commented on Jul 20, 2021

scottkurz commented on Nov 24, 2021

michael-valdron commented on Apr 11, 2024

github-actions commented on Jul 23, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions