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

Implement an ability to specify container for commands for K8s/OS tool with multiple containers #12606

Closed
sleshchenko opened this issue Feb 6, 2019 · 1 comment
Labels
kind/enhancement A feature request - must adhere to the feature request template. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. severity/P1 Has a major impact to usage or development of the system.

Comments

@sleshchenko
Copy link
Member

Description

Now commands for K8s/OS tool in devfile work fine only if the tool has one container.
It is needed to improve UX of K8s/OS tool commands if the tool has multiple containers.
There are two different improvements directions:

  1. IDE should propose to user choose container from tool containers list (now it shows all containers, editors, plugins, Che Utils(like jwtproxy)).

  2. Add an ability in Devfile to specify the concrete container from tool.
    It may be done by extending Devfile Command model and introducing new fields like

  - name: build
    actions:
      - type: exec
        tool: 
          name: che-dev
          containerName: mysql  // new
          podName: db           // new 
          selector:             // new
            app.kubernetes.io/component: database
        command: mvn clean install
        workdir: /projects/che

It is just a proposal that should be discussed in details and there was not made final decision how Command model should be changed to handle this case.

@sleshchenko sleshchenko added kind/enhancement A feature request - must adhere to the feature request template. team/platform labels Feb 6, 2019
@skabashnyuk skabashnyuk added the severity/P1 Has a major impact to usage or development of the system. label Mar 6, 2019
@che-bot
Copy link
Contributor

che-bot commented Sep 7, 2019

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

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

Moderators: Add lifecycle/frozen label to avoid stale mode.

@che-bot che-bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Sep 7, 2019
@che-bot che-bot closed this as completed Sep 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement A feature request - must adhere to the feature request template. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. severity/P1 Has a major impact to usage or development of the system.
Projects
None yet
Development

No branches or pull requests

3 participants