| 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
_______________________________________________
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
Sun TAN
Senior Java Software Engineer
Eclipse Che @ Red Hat
+33 6 21 02 41 73
sutan@xxxxxxxxxx
http://blog.sunix.org
@sunsengdavidtan