Skip to content
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

The image name in initContainers should automatically resolve to a image stream name. #17504

Open
GrahamDumpleton opened this issue Nov 29, 2017 · 7 comments
Assignees
Labels
component/apps kind/feature Categorizes issue or PR as related to a new feature. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. priority/P2

Comments

@GrahamDumpleton
Copy link

GrahamDumpleton commented Nov 29, 2017

When using dc.spec.template.spec.initContainers and you set the image field to an image stream name, it isn't automatically resolved to an image stream name in the project as occurs for dc.spec.template.spec.containers. Being in a DeploymentConfig, I would expect it to, just like with normal containers in the pod. Instead it is necessary to set the lookupPolicy on the image stream to be local, or add the resolve-names annotation to the pod template.

Version
oc v3.6.1+008f2d5
kubernetes v1.6.1+5115d708d7
features: Basic-Auth

Server https://127.0.0.1:8443
openshift v3.6.1+008f2d5
kubernetes v1.6.1+5115d708d7
Steps To Reproduce

Use a oc patch --type=json patch such as:

[
  {
    "op": "add",
    "path": "/spec/template/spec/initContainers",
    "value": [
      {
        "name": "blog-htdocs-init",
        "image": "blog",
        "volumeMounts": [
            {
                "mountPath": "/mnt",
                "name": "htdocs"
            }
        ],
        "command": [
            "rsync",
            "--archive",
            "--no-perms",
            "--no-times",
            "/opt/app-root/src/htdocs/",
            "/mnt/"
        ]
      }
    ]
  }
]

and the deployment will get stuck when trying to start the init container as it can't work out what image is.

Instead use:

[
  {
    "op": "add",
    "path": "/spec/template/metadata/annotations/alpha.image.policy.openshift.io~1resolve-names",
    "value": "*"
  },
  {
    "op": "add",
    "path": "/spec/template/spec/initContainers",
    "value": [
      {
        "name": "blog-htdocs-init",
        "image": "blog",
        "volumeMounts": [
            {
                "mountPath": "/mnt",
                "name": "htdocs"
            }
        ],
        "command": [
            "rsync",
            "--archive",
            "--no-perms",
            "--no-times",
            "/opt/app-root/src/htdocs/",
            "/mnt/"
        ]
      }
    ]
  }
]

or run:

oc set image-lookup dc/blog

which adds the annotation on the pod template, then works okay.

Current Result

Doesn't resolve image name to image stream in init containers.

Expected Result

Since part of DeploymentConfig, expect it to resolve to image stream name like it does for containers in same pod.

Additional Information

None.

@bparees
Copy link
Contributor

bparees commented Nov 30, 2017

@pweil- this is a deploymentconfig RFE, not an image RFE.

@openshift-bot
Copy link
Contributor

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

@openshift-ci-robot openshift-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Feb 28, 2018
@GrahamDumpleton
Copy link
Author

/lifecycle frozen

@openshift-ci-robot openshift-ci-robot added the lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. label Feb 28, 2018
@hedinasr
Copy link

+1

@ghost
Copy link

ghost commented Sep 19, 2018

We are stuck with this as well. It means that you have to hard-code the image URI for the init-container in a template, which will fail if you don't match the project name to the template. This limits the usefulness of init-containers in a template, as there is no way to explicitly reference the namespace either: https://trello.com/c/zcRQFri0/916-2-namespace-template-parameter-templates.

@GrahamDumpleton
Copy link
Author

GrahamDumpleton commented Oct 2, 2018

@riekrh If the name of the image for the init container is the same as the main container, have you tried adding the name of the init container to the container names under imageChangeParams.

    - imageChangeParams:
        automatic: true
        containerNames:
        - superset
          superset-init
        from:
          kind: ImageStreamTag
          name: superset:latest
          namespace: "${NAMESPACE}"
      type: ImageChange

For the case where same image is used as main container, this works fine.

@openshift-ci-robot openshift-ci-robot added kind/feature Categorizes issue or PR as related to a new feature. and removed kind/enhancement labels Apr 13, 2019
@cmflynn
Copy link

cmflynn commented Sep 7, 2022

I'm still having this issue, even with declaring imageChangeParams + containerNames. @GrahamDumpleton can you post a complete example of the yaml where this approach works?

edit: nevermind, I was missing the image field having the image stream name as its value. now it looks to be working.

          initContainers:
            - name: ${APP_NAME}-init-alembic-migrate
              image: ${APP_NAME} # <-- this is the image stream name 
              command: ["alembic", "upgrade", "head"]
              env: *ENV

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component/apps kind/feature Categorizes issue or PR as related to a new feature. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. priority/P2
Projects
None yet
Development

No branches or pull requests

8 participants