Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [che-dev] Question about agents, features and services

Asbi understand it, a sidecar is a container the shares the process namespace with its host. 
/Thomas


On Wed, 18 Apr 2018, 10:30 Zachary Sang, <zacharysang@xxxxxxxxx> wrote:
That makes sense. Thanks for your help!

On Wed, Apr 18, 2018 at 10:20 AM, Oleksandr Garagatyi <ogaragat@xxxxxxxxxx> wrote:
Yes, you are right regarding first two questions. 

As to the third one, I think that the difference is that sidecar means a technical way of running services. Whereas services are Eclipse Che model entities. 

On Wed, Apr 18, 2018 at 5:12 PM, Zachary Sang <zacharysang@xxxxxxxxx> wrote:
Thanks for your response! This makes the motivation behind the adding concept of services and features to Che much more clear. 

Does this mean that a sidecar is simply the name given to a container running alongside the user container to provide this extra functionality?

Also, I see that a feature is the user's term for a unit of functionality that they can add to their workspace, and that it is built from a set of services, each providing a focused piece of the feature. Does this sound correct?

If this sounds right, I am still a little confused to the difference between a sidecar and a service. Aren't these both containers that run alongside the user's workspace container?

Thanks again,

Zak

On Wed, Apr 18, 2018 at 3:58 AM, Oleksandr Garagatyi <ogaragat@xxxxxxxxxx> wrote:
Hi, Zak. I'm one of the contributors who is working on a new feature/service concept integration in Che. I'll try to explain how I see an answer to your questions, but don't take it as a general answer from the whole community. I can be mistaken somewhere, so if someone notices a mistake, please, do not hesitate to add your comments to the thread.

Che 6 agent is a piece of software that adds some functionality to the workspace.
But it is usually added to a workspace with a shell script that installs an agent and its dependencies to a workspace container.
This approach doesn't fit container world approach when nothing should be installed in a container at runtime. Since this approach might be violated in Che we face difficulties in the usage of Che on a hosted containers infrastructures, such as kubernetes or openshift. 
Basically installing something into a container at runtime is not a good approach because:
- it may require a sudo access which is unavailable in many infrastructures
- a container may run with a random user ID which is also tricky when you install something at runtime
- agent dependencies may conflict with a user's container. Example: user's app uses Oracle Java 5, agent X uses OpenJDK Java 6, agent Y uses  Azul JVM. All of them should somehow coexist in a single container. And they should be somehow installer in the same container which is very tricky.

And apart from that right now Che doesn't allow us to add a plugin to IDE codebase from an agent. Which leads us to a situation when IDE parts of all the plugins we want should be bundled with the basic Che packaging. This approach doesn't allow us to grow Che community and plugins eco-system easily.


So there is an idea to bring new feature/service concept to Che which is called Workspace.Next.
This concept supposes that user defines his own application recipe, e.g. my NodeJS app server in container1 and MySQL server in container2. And he also defines a list of features in IDE he wants to use, e.g. NodeJS support, UI for SQL querying from the IDE, some packaging system support, some VCS support, etc.
Che combines user's app recipe and list of features to a runtime that uses sidecars to provide tooling to a workspace.
In this particular example we could end up running:
- container1 with NodeJS app
- container2 with MySQL server
- container3 (sidecar) with a NodeJS language server
- container4 (sidecar) with a VCS agent
- container5 (sidecar) with an agent needed to provide UI for SQL querying from the IDE

As you might see in this example:
- all the features can be implemented by different authors
- all the features have their own environment and dependencies
- we can set up all the dependencies when docker images for features are built, so no sudo is required
- there is no conflict in dependencies between features because they run in different containers


As to what feature and what service terms mean:
- a feature is what IDE user choose when he creates a workspace
- a service is part of the feature which is developed by Che plugins authors

Here is an epic that explains all the concepts and motivation, probably better than what I have described here https://github.com/eclipse/che/issues/8265
You can follow discussions regarding designing Workpspace.Next there and eventually even try it when some experimental version of it will be ready.



On Tue, Apr 17, 2018 at 6:45 PM, Zachary Sang <zacharysang@xxxxxxxxx> wrote:
Hi,

I am a little confused about the roles and relation between agents, features, and services. I understand that at the moment workspace agents such as the terminal agent, ssh agent and some of the language servers work to allow a user to add additional functionality to a workspace beyond the recipe definition. I have also read a little about how features will consist of a collection of services and how these also serve to increase extensibility and to allow users to add functionality to a workspace. However, I am not sure how features/services will interact with agents. Will they ultimately take over the same functionality as agents?

Also, where do sidecars fit into all this?

Best,

Zak

_______________________________________________
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 


_______________________________________________
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 


_______________________________________________
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

Back to the top