[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [che-dev] Workspace.Next
|
On 19 Dec 2017, at 2:38, Oleksandr Garagatyi wrote:
What we have been discussing with Gorkem some time ago is a separation
of
development stack and user's application step.
I believe it is something similar to what Mario says.
My idea is that user doesn't want to describe his development
environment,
but wants to put his production environment and add some functionality
provided by Che.
For example, a user has prod with a spring boot app and DB. He wants
to
open Che and put his compose/k8s recipe to create workspace and choose
what
he needs java support, visual tool for querying the DB, maven,
terminal to
call maven and git operations, etc. Then Che should do some magic to
provide a workspace with all of these components merged somehow.
What would be needed for the user next is an ability to redeploy his
app
after he changed sources. And this redeploys should not (if possible)
involve running spring boot app inside of development containers t
deliver
sources. Delivering sources should be a problem for a tool, aka Che,
not
the user. It is the place where those build container (s2i) are
needed.
I understand that this is a major change, but this would provide much
better UX and would behave in a quite an intuitive way for a user.
+1
When developers have their own existing images or when they use a
service that generates codes and image definitions.
Che is not the easiest to work with. We need to eliminate this step of
workspaces.
OTOH when a developer starts with Che stack and define his/her
workspace, we are more helpful with the workspace.
However, what the user is creating in this case is also his/her runtime
environment. I think we should also acknowledge that
and Che should become a tool for defining runtime in addition to
workspace.
On Mon, Dec 18, 2017 at 5:45 PM, Gennady Azarenkov
<gazarenk@xxxxxxxxxx>
wrote:
Actually, that's what I am asking about.
You can try to rename "dev" to "runtime" and see, if it does not work
in
some circumstances, then it's a bug.
Thanks
On Mon, Dec 18, 2017 at 4:07 PM, Mario <mario.loriedo@xxxxxxxxx>
wrote:
@Mario, dev-machine is just a machine name. It can be any name.
Agree. And the curious thing is that to define a "runtime" stack the
only
mandatory machine is a "dev" machine, not a "runtime" machine :-)
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
--
OLEKSANDR GARAGATYI
SENIOR SOFTWARE ENGINEER
Red Hat
<https://www.redhat.com/>
<https://red.ht/sig>
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
