Remove native launch scripts of Eclipse Che (replaced now by Docker CLI)

[benoitf]

What does this PR do?

Now, docker CLI is the way to start Eclipse Che so we don't need anymore "native scripts" and Vagrantfile

command to start che is : docker run eclipse/che
to use local binaries : add -v <path-to-che-cloned-directory>:/repo

It was originally made as part of Pull Request #3318
but it has been delayed to get stability on docker CLI and developers using it
#3318 (comment)

What issues does this PR fix or reference?

#2977

Previous behavior

Che was launched with shell scripts or with Vagrant

New behavior

Che is launched with CLI

Tests written?

No

Docs updated?

AFAIK in the docs we don't write how to use these scripts.

Changelog

Remove native launch scripts of Eclipse Che (replaced now by Docker CLI)

Change-Id: I8649830049974043b69f6725480c1799cfe325cd
Signed-off-by: Florent BENOIT [email protected]

[codenvy-ci]

Build success. https://ci.codenvycorp.com/job/che-pullrequests-build/1668/

[benoitf]

adding removal of Vagrantfile as well

[codenvy-ci]

Build # 1676 - FAILED

Please check console output at https://ci.codenvycorp.com/job/che-pullrequests-build/1676/ to view the results.

[benoitf]

ci-build

[codenvy-ci]

Build success. https://ci.codenvycorp.com/job/che-pullrequests-build/1688/

[benoitf]

should I wait more time on the review of this PR ?

[TylerJewell]

We are ok to merge. However, what if we considered an alternative?

The purpose of the CLI is to have puppet for taking a single configuration and generating an instance configuration. Today, we do that with a single way to ultimately start che which is with eclipse/che-server. But what if we used puppet to generate multiple ways to start Che - through docker-compose and / or native? And then we had some sort of simple flag in the start command to indicate which technique is used to start your che instance.

We could then have templates for generating the native approach for starting che - but you still use the CLI to interface with it.

[benoitf]

We're generating a docker compose file that can be used directly (without cli calls)
Also native is working only on linux so it's not portable

[TylerJewell]

We could generate a native.sh and a native.bat at the same time. So, theoretically this would be possible.

[TylerJewell]

So, we currently have a /instance folder, which we could impose to mean, "default execution folder for docker compose launcher". What would stop us from adding /instance-native and other flavors as peers? We would not generate these folders by default. We would honor that workflow only if users provided a launch-type flag. So we could have --launch:default, --launch:native, --launch:compose as global flags that can instruct the CLI which instance folder (and template types) to use.

[benoitf]

Pull request rebased. It's open for 6 days : should I merge ?

[TylerJewell]

Yes, merge.

We can plan to add in a second type of /instance folder in the future that allows for truly native launches but launched from within the CLI container.

[codenvy-ci]

Build success. https://ci.codenvycorp.com/job/che-pullrequests-build/1762/