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

Annotation key is too long error when starting workspace, created from devfile #13303

Closed
mmorhun opened this issue May 10, 2019 · 15 comments
Closed
Assignees
Labels
kind/bug Outline of a bug - must adhere to the bug report template. severity/P1 Has a major impact to usage or development of the system.
Milestone

Comments

@mmorhun
Copy link
Contributor

mmorhun commented May 10, 2019

Description

When try to start workspace form some devfiles it fails to start with error message:

Failure executing: POST at: https://172.30.0.1/apis/apps/v1/namespaces/eclipse-che/deployments. Message: Deployment.apps \"workspacet0so790bumywjht3.workspace\" is invalid: spec.template.annotations: Invalid value: \"org.eclipse.che.container.eclipse-che-theia-dev-nightly.machine_name\": name part must be no more than 63 characters. Received status: Status(apiVersion=v1, code=422, details=StatusDetails(causes=[StatusCause(field=spec.template.annotations, message=Invalid value: \"org.eclipse.che.container.eclipse-che-theia-dev-nightly.machine_name\": name part must be no more than 63 characters, reason=FieldValueInvalid, additionalProperties={})], group=apps, kind=Deployment, name=workspacet0so790bumywjht3.workspace, retryAfterSeconds=null, uid=null, additionalProperties={}), kind=Status, message=Deployment.apps \"workspacet0so790bumywjht3.workspace\" is invalid: spec.template.annotations: Invalid value: \"org.eclipse.che.container.eclipse-che-theia-dev-nightly.machine_name\": name part must be no more than 63 characters, metadata=ListMeta(_continue=null, resourceVersion=null, selfLink=null, additionalProperties={}), reason=Invalid, status=Failure, additionalProperties={}).

Reproduction Steps

  1. Create workspace from the following devfile using POST /workspace/devfile API method
{
  "specVersion": "0.0.1",
  "name": "multiple-dockerimages",
  "projects": [
    {
      "name": "nodejs-mongo-app",
      "source": {
        "type": "git",
        "location": "https://github.com/ijason/NodeJS-Sample-App.git"
      }
    }
  ],
  "components": [
    {
      "name": "theia-editor",
      "type": "cheEditor",
      "id": "eclipse/che-theia/next"
    },
    {
      "name": "exec-plugin",
      "type": "chePlugin",
      "id": "eclipse/che-machine-exec-plugin/0.0.1"
    },  
    {
      "name": "mongodb",
      "type": "dockerimage",
      "image": "eclipse/che-theia-dev:nightly",
      "endpoints": [
        {
          "name": "mongo",
          "port": 27017,
          "attributes": {
            "public": "false",
            "discoverable": "true"
          }
        }
      ],
      "mountSources": true,
      "volumes": [
        {
          "name": "mongo-storage",
          "containerPath": "/data/db"
        }
      ],
      "memoryLimit": "2500Mi"
    },
    {
      "name": "nodejs-app",
      "type": "openshift",
      "reference": "node-js.yaml",
      "referenceContent": "apiVersion: v1\nkind: List\nitems:\n-\n  apiVersion: apps/v1\n  kind: Deployment\n  metadata:\n    name: web\n    labels:\n      app: nodejs\n  spec:\n    replicas: 2\n    selector:\n      name: web\n    template:\n      metadata:\n        labels:\n          app: nodejs\n        name: web-controller\n      spec:\n        containers:\n        - image: node:0.10.40\n          command: ['tail', '-f', '/dev/null']\n          args: []\n          name: web\n          ports:\n          - containerPort: 3000\n            name: http-server\n          volumeMounts:\n           - mountPath: /projects\n             name: projects\n        volumes:\n         - name: projects\n           persistentVolumeClaim:\n             claimName: projects\n- apiVersion: v1\n  kind: PersistentVolumeClaim\n  metadata:\n    name: projects\n  spec:\n    accessModes:\n     - ReadWriteOnce\n    resources:\n      requests:\n        storage: 2Gi\n-\n  apiVersion: v1\n  kind: Service\n  metadata:\n    name: web\n    labels:\n      name: web\n  spec:\n    type: LoadBalancer\n    ports:\n      - name: web\n        port: 80\n        targetPort: 3000\n        protocol: TCP\n    selector:\n      app: nodejs\n- apiVersion: v1\n  kind: Route\n  metadata:\n    name: che\n  spec:\n    to:\n      kind: Service\n      name: web\n    port:\n      targetPort: web\n"
    }
  ],
  "commands": [
    {
      "name": "run",
      "actions": [
        {
          "type": "exec",
          "component": "nodejs-app",
          "command": "cd ${CHE_PROJECTS_ROOT}/nodejs-mongo-app/EmployeeDB/ && npm install && node app.js"
        }
      ]
    }
  ]
}

Note, that this problem occurs when replace mongo with something longer, say eclipse/che-theia-dev:nightly.

  1. Try to start the workspace
@monaka monaka added the kind/bug Outline of a bug - must adhere to the bug report template. label May 10, 2019
@sleshchenko sleshchenko added team/platform severity/P1 Has a major impact to usage or development of the system. labels May 10, 2019
@mmorhun
Copy link
Contributor Author

mmorhun commented May 20, 2019

It tries to use org.eclipse.che.container.eclipse-che-theia-dev-nightly.machine_name for the name. To workaround this problem one may add alias field into the image description in devfile. The Che will use it as a name and it will not exceed the 64 characters limit.

@sleshchenko sleshchenko changed the title Error when starting workspace, created from devfile Annotation key is too long error when starting workspace, created from devfile May 28, 2019
@metlos
Copy link
Contributor

metlos commented Jun 7, 2019

The only 2 viable solutions I see here is to:

  • either
    • shorten the prefix/suffix of the annotation. E.g. instead of org.eclipse.che.container.eclipse-che-theia-dev-nightly.machine_name we could do with che.container.name.eclipse-che-theia-dev-nightly for example.
    • Add a validation step that would fail early if the generated annotation would exceed the 64 chars limit. I.e. it would suggest to put in an alias if the identifier of the component (plugin id, docker image name, ...) would be too long or to shorten the alias if it itself is too long.
  • or
    • give up on storing this kind of information (which I believe is purely informational)

@mmorhun
Copy link
Contributor Author

mmorhun commented Jun 7, 2019

I don't think we should bother Che users with internal stuff like length of generated name. I would try to use full form and if it fails, make it shorter.

@metlos
Copy link
Contributor

metlos commented Jun 7, 2019

So what about:

che.container.1.component=eclipse-che-theia-dev-nightly
che.container.1.machine=ws/dev
che.container.2.component=...
che.container.2.machine=...

e.g. split the annotation in 2 with predictable names and free-form values.

@metlos
Copy link
Contributor

metlos commented Jun 7, 2019

This is the piece of code that adds these annotations. Notice that the machine name is always already contained in the key of the annotation. I don't think this piece of info gives any useful information.

https://github.com/eclipse/che/blob/35ce3544f7e008566daecb1b57266b1bc4fef7f5/infrastructures/kubernetes/src/main/java/org/eclipse/che/workspace/infrastructure/kubernetes/wsplugins/KubernetesPluginsToolingApplier.java#L202-L203

@lemaral
Copy link

lemaral commented Jun 26, 2019

I hit the same issue while trying the new vscode kubernetes plugin support, so I tried to use a shorter alias but it does not seems to be picked up (using nightly)

  - type: chePlugin
    alias: kubernetes-tools
    id: 'ms-kubernetes-tools/vscode-kubernetes-tools/0.1.17'

metadata.annotations: Invalid value: "org.eclipse.che.container.vscode-kubernetes-toolsu3f.machine_name": name part must be no more than 63 characters, spec.template.annotations: Invalid value: "org.eclipse.che.container.vscode-kubernetes-toolsu3f.machine_name": name part must be no more than 63 characters]

@sleshchenko
Copy link
Member

@lehmanju Thanks for sharing your case. I believe you're right and workaround with short alias work only with dockerimage component type.

@lemaral
Copy link

lemaral commented Jun 30, 2019

@sleshchenko, thanks for confirming. I believe that there is no workaround then and because of that it's not possible to use the latest che with vscode plugins currently (and potentially other plugins with long name)
Another quick fix would be to use annotation prefix which allows 253 characters (but my following comment still applies).
About the root cause of the issue, I think using raw information for annotation key is a fragile design. It should be stored in the annotation value, and the key should be generated as a short fixed-length unique retrievable value (e.g. hash).
My 2 cents :)

@apupier
Copy link
Contributor

apupier commented Jul 11, 2019

hitting same issue with OpenShift Connector extension:

spec.template.annotations: Invalid value: "org.eclipse.che.container.vscode-openshift-connector2ph.machine_name": name part must be no more than 63 characters.

@tsmaeder
Copy link
Contributor

tsmaeder commented Jul 11, 2019

I don't understand this issue: I don't see spec.template.annotations anywhere in the devfile. If it is something that is generated by our own tooling, we need to insure that we can translate values in the input to valid values in the output.
Putting the burden for this on the user seems wrong to me.

@apupier
Copy link
Contributor

apupier commented Jul 11, 2019

it seems to be something generated by Che itself internally.

Currently, there is not even a "burden" to the user as the initially proposed workaround is reported as not working for VS Code extension, working only for dockerfile see #13303 (comment)

My current understanding is that there is no way to use some of the VS Code Extensions proposed by the default registry.

@tsmaeder
Copy link
Contributor

@skabashnyuk can you confirm that some of the plugins in che-plugin-registry do not work currently? That would mean it's a 7.0.0 issue, IMO. If it's only a problem for 3rd party plugins, I would tent towards 7.1.0.

@tsmaeder
Copy link
Contributor

tsmaeder commented Jul 11, 2019

Ok, that's a 7.0 for me then. What we ship should at least start up out of the box.

@tsmaeder tsmaeder added this to the 7.0.0 milestone Jul 11, 2019
@metlos metlos self-assigned this Jul 15, 2019
@metlos metlos added the status/in-progress This issue has been taken by an engineer and is under active development. label Jul 15, 2019
@l0rd l0rd mentioned this issue Jul 16, 2019
85 tasks
@slemeur slemeur added status/code-review This issue has a pull request posted for it and is awaiting code review completion by the community. and removed status/in-progress This issue has been taken by an engineer and is under active development. labels Jul 24, 2019
@sleshchenko
Copy link
Member

Finally closed 🎉

@mmorhun mmorhun removed the status/code-review This issue has a pull request posted for it and is awaiting code review completion by the community. label Jul 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Outline of a bug - must adhere to the bug report template. severity/P1 Has a major impact to usage or development of the system.
Projects
None yet
Development

No branches or pull requests

8 participants