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

mysql commands do not work via devfile commands (Theia Tasks) #13416

Closed
sleshchenko opened this issue May 24, 2019 · 7 comments
Closed

mysql commands do not work via devfile commands (Theia Tasks) #13416

sleshchenko opened this issue May 24, 2019 · 7 comments
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

@sleshchenko
Copy link
Member

sleshchenko commented May 24, 2019

Description

mysql commands do not work via devfile commands (Theia Tasks)

Reproduction Steps

  1. Create a workspace from the following Devfile
Devfile
---
apiVersion: 1.0.0
metadata:
  name: java-mysql-theia-kubernetes
components:
  -
    type: cheEditor
    id: eclipse/che-theia/next
  -
    type: chePlugin
    id: eclipse/che-machine-exec-plugin/0.0.1
  -
    type: kubernetes
    alias: web
    referenceContent: |
      kind: List
      items:
      -
        apiVersion: v1
        kind: Pod
        metadata:
          name: web
        spec:
          containers:
          -
            image: registry.centos.org/che-stacks/centos-jdk8
            name: dev
            ports:
            - containerPort: 8080
              protocol: TCP
            resources:
              limits:
                memory: 512Mi
            volumeMounts:
            - name: projects
              mountPath: /projects
          volumes:
          - name: projects
            persistentVolumeClaim:
              claimName: projects
      -
        apiVersion: v1
        kind: PersistentVolumeClaim
        metadata:
          name: projects
          labels:
            app.kubernetes.io/name: employee-manager
            app.kubernetes.io/component: nodejs-app
        spec:
          accessModes:
           - ReadWriteOnce
          resources:
            requests:
              storage: 1Gi
  -
    type: kubernetes
    alias: mysql
    referenceContent: |
      kind: List
      items:
      -
        apiVersion: v1
        kind: Pod
        metadata:
          name: db
          labels:
            type: db
        spec:
          containers:
          -
            image: centos/mysql-57-centos7
            name: mysql
            ports:
            - name: mysql
              containerPort: 3306
              protocol: TCP
            env:
            - name: MYSQL_USER
              value: petclinic
            - name: MYSQL_ROOT_PASSWORD
              value: password
            - name: MYSQL_PASSWORD
              value: password
            - name: MYSQL_DATABASE
              value: petclinic
            resources:
              limits:
                memory: 256Mi
      -
        apiVersion: v1
        kind: Service
        metadata:
          name: db
        spec:
          selector:
            type: db
          ports:
          - name: mysql
            port: 3306
            protocol: TCP
            targetPort: mysql
commands:
  - name: open database command line
    actions:
    - type: exec
      component: mysql
      command: mysql -u $MYSQL_USER -p$MYSQL_PASSWORD --database=$MYSQL_DATABASE
  1. Try to run open database command line tasks.
    Expected: terminal with mysql is run
    Actual: mysql command is not found message is shown

Note that if you open terminal in mysql container and execute command (mysql -u $MYSQL_USER -p$MYSQL_PASSWORD --database=$MYSQL_DATABASE) there then it works just fine.

Also, we did some short investigation with @AndrienkoAleksandr and made sure that exec-plugin and terminal have the same uid in shell.

OS and version:
Was reproduced on Che deployed on Minishift.

Diagnostics:

@sleshchenko sleshchenko added kind/bug Outline of a bug - must adhere to the bug report template. team/ide2 labels May 24, 2019
@l0rd l0rd added this to the 7.0.0 milestone Jul 24, 2019
@l0rd l0rd added severity/P1 Has a major impact to usage or development of the system. area/languages Issues related to Language extensions or plugins integration. labels Jul 24, 2019
@l0rd l0rd removed the team/ide2 label Jul 24, 2019
@evidolob evidolob added team/ide2 and removed area/languages Issues related to Language extensions or plugins integration. labels Jul 24, 2019
@evidolob evidolob assigned evidolob and unassigned svor Jul 24, 2019
@mmorhun mmorhun self-assigned this Jul 24, 2019
@mmorhun mmorhun added the status/in-progress This issue has been taken by an engineer and is under active development. label Jul 24, 2019
@sunix
Copy link
Contributor

sunix commented Jul 30, 2019

@mmorhun could you share your investigation result here ?

@mmorhun
Copy link
Contributor

mmorhun commented Jul 30, 2019

I did investigation and the root problem is that all Che tasks is run in non-interactive shell. Because of this, mysql command isn't added into PATH environment variable and as a result we see mysql command is not found. In other words, the mysql image is designed to add mysql command in PATH only if the shell is interactive (which is true for a regular terminal which a user opens).

To fix the problem without changing the image, we need to run such Che tasks in interactive shells. But we cannot predict if a task requires interactive shell, so we have to run every task in interactive shell (which would be a plus, imo). But some scripts which is designed for non-interactive shells might not work properly.
For more details, one may check this.

So, is it ok to run all Che tasks in interactive shell ? @AndrienkoAleksandr @l0rd @RomanNikitenko @evidolob @sunix

@l0rd @slemeur, should we introduce such change before GA ?

@AndrienkoAleksandr
Copy link
Contributor

So, is it ok to run all Che tasks in interactive shell ? @AndrienkoAleksandr @l0rd @RomanNikitenko @evidolob @sunix

Like variant we can apply some option in the dev file and for che task... But maybe it would be better to do this after GA. Like workaround for current mysql devfile, we can define in the commands full path to the mysql binary and it should work.

@amisevsk
Copy link
Contributor

As a workaround for GA, would it be possible to update the task to point directly at the mysql binary?

@mmorhun
Copy link
Contributor

mmorhun commented Jul 31, 2019

@amisevsk yes, it will work and very easy to fix.

@sunix
Copy link
Contributor

sunix commented Jul 31, 2019

It has nothing to do with 'interactive' aspect of a shell ... but anyway ...

I would say it is not a bug as the container is not supposed to call mysql binary directly:

Our commands should try to respect the one that is used in the container CMD. https://github.com/sclorg/mysql-container/blob/master/5.7/Dockerfile#L80

run-mysqld

Are we missing the ability to define env variables from the che commands ?

From README:

$ podman run -d --name mysql_database -e MYSQL_USER=user -e MYSQL_PASSWORD=pass -e MYSQL_DATABASE=db -p 3306:3306 rhscl/mysql-57-rhel7

It seems that the env variable are already defined so just calling run-mysqld should work (if the goal is to start the database)

If the goal is to open a terminal: use full path yes.

@mmorhun
Copy link
Contributor

mmorhun commented Jul 31, 2019

In devfile registry the command from java-mysql stack has already been changed to use full path for mysql binary

@mmorhun mmorhun closed this as completed Jul 31, 2019
@AndrienkoAleksandr AndrienkoAleksandr removed the status/in-progress This issue has been taken by an engineer and is under active development. label Jul 31, 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