Che: [CHE 6] Revert renaming of "Agents" by "Installers"

[slemeur]

Description

For some reasons, "Agents" have been renamed to "Installers" in our model. This nomenclature is unfortunate and must be reverted.

The meaning behind "installers" is completely different from end-user point of view. An installer does not provide any features or capabilities - it is just a component that handle the installation of a "software".

"Installer" is unfortunated because:

• On some infrastructures there is nothing which can be installed in a workspace machine(s)
• Agents might be packaged in the workspace machine(s)
• Agents can be running as sidecars of the workspace machine(s)

"Installers" nomenclature is more confusing than anything for end-users - and very specific to one scenario.

Example showing how it is exposed to end-user:

_Here, the user is supposed to enable features and capabilities provided by "Agents" not "Installers"_

That renaming also breaks any workspace definition (used in chefile, factories) between che5 and che6:

"dev-machine": {
  "installers": [
    "org.eclipse.che.exec",
    "org.eclipse.che.terminal",
    "org.eclipse.che.ws-agent",
    "org.eclipse.che.ssh"
  ],
}

_Here it looks equally unappropriated._

[gazarenkov]

@slemeur I think you misunderstand the model
Now:
1/ We have installers as a script which MAY (if infrastructure allows, example of "not allowing" is the case when there is sudo command and infrastructure does not allow it) install some software into machine.
2/ We have agents naming dedicated software installed (no matter how: via image, recipe or installers) to machine. For example: ws-agent for supporting basic set of APIs (Project/Git etc), terminal-agent, exec-agent (for commands)
Before:
We had agents for both of those which was confusing and actually word agent is not semantically good for the entity which perform ONLY installation.

Che6 format is not compatible with Che5, it is normal for major version and we will deal with using patches, migration instructions etc.

Hope it answers your question.

[gazarenkov]

Ah, and, yes, I would say UD could be more straightforward reflecting the workspace model, it has to be discussed indeed.

[slemeur]

Unclear

"1/ We have installers as a script which MAY"

Which may what?

[slemeur]

Che6 format is not compatible with Che5, it is normal for major version and we will deal with using patches, migration instructions etc.

The only reason why a workspace definition is not compatible between Che 5 and Che 6 is because of the use of installers instead of agents. It's a shame to break compatibility of workspace definition for a renaming that is unappropriated.

[sunix]

I think renaming such a core component will confuse everyone. This is even more confusing if finally an che6 installer is a che5 agent et a che6 agent is something else ... Confusion + breaking compatibility don't sound good to me.

[gazarenkov]

@slemeur fixed, thanks for pointing this.

@sunix, @slemeur No, it is not only, there are a lot of changes.
As I mentioned, we called "agent" 2 different things in Che5, it is fixed in Che6.

[sunix]

@gazarenkov BTW installers sound like it will only install something ... not run it. Whereas the che6 installers and che5 agents also run something.

[gazarenkov]

@sunix yes, they MAY run something but they do not run themselves becoming an "agent" or so.
We considered other names but "Runners" would fit less than "Installers" since they always install and sometimes run
I do not think it is a big deal though since in practice many installers we use may run some long live process at once. But if you have really better name which cover all of this (please do not propose something like "InstallersAndRunners" :) ) - we can discuss it even now.
I am very serious about this kind of terminology.

[slemeur]

I have an hard time to process your logic behind the definition of "Installer".

I read:

We have installers as a script which MAY install some software into machine

and now:

"Installers" always install and sometimes run

Installers are not installing anything on certain infrastrutures.

As mentioned earlier:

The meaning behind "installers" is completely different from end-user point of view. An installer does not run anything - it is just a component that handle the installation of a "software".

The abstraction should be the "Agent". The way an agent is getting provided to the workspace, is an attribute or a type of agent.
An agent could be delivered:

• by an installer
• by a sidecar container
• by connecting to a third-part service
• ...

An agent can then provide:

• tooling
• API
• language servers
• ...

Using "Installer" does not provide this kind of abstraction.

[sunix]

to me this is a small change that doesn't provide a lot of value but is causing a lot of confusion and backward compatibility issues

[gazarenkov]

I see no sense to support wrong terminology for backward compatibility in major version in cost of future, let's think about better UI and documentation for this.

[slemeur]

At first:

• "Installers" are in your proposal used to make something generic, where "Installer" is a terminology that is absolutely specific to the Docker infrastructure. There will be nothing installed on OpenShift infrastructure, so having installers upfront in the recipe of a workspace that is running on OpenShift is one of the non sense introduced by the use of this terminology.

Second:

• The terminology should not be bound to the way the "tooling" is getting configured with the workspace. There is an higher lever of abstraction which has always been "Agents" and which was clear to end-user and coherent with the way we explain how the system is working.
  Then, an agent can be installed, bootstrapped, spin-up as a sidecar - but this is implementation detail - the system must handle that, without having to expose it to the end user.

Finally:

• This terminology has been introduced without any discussion. Changing the terminology of such a component is impactful. It would have been nice to initiate a public discussion, collect opinion and have an healthy discussion about motivations and point of view of everyone.

We are lucky that Che 6 has not been released. We still have a bit of time to change and improve this.

[gazarenkov]

First - not at all, there are no dependency on docker
Second - no, you misunderstand the model. I tried to explain it above, if you really want to understand the point, try to re-read and we can talk separately.
Third - no, there are nothing hidden, all the development is open, everything is reflected in issues, EVERY Sprint backlog is published in advance and discussed. This particular terminology (installers, bootstrappers) WAS discussed back 6+ months ago with PM, you probably just had no interest this time.

For the readiness to GA release, that's what I'd do agree with you:

• we have to put more effort on explanation how it works. Our current official documentation looks near useless, it is not informative. I hope we can do it better by release time.
• UD seems to be too cumbersome for end user, flow there is too complex and artificial (far from the flow happened in core). I am not sure if we can radically change it by the release time but at least we have to some improve it.

[sunix]

I see no sense to support wrong terminology for backward compatibility in major version in cost of future, let's think about better UI and documentation for this.

"wrong" terminology is only your point of view. To me there was nothing wrong in calling it "agent" what was agent at the time. But calling something that is being installed AND then activated AND run as a microservice just "installer" looks like a wrong terminology for sure.

[gazarenkov]

script which download and install "agent" (for ex) can not be called "agent".
yes, I call it wrong terminology

[gorkem]

I was looking at this over the weekend and this is a more involved change than I anticipated. We have referral to agents, workspace agents on the website, in addition to docs. I have seen a lot of presentation material and recorded sessions that talks about agents. This is hundreds of hours of work, that needs to be corrected. And we can not recover the recorded sessions such as this one.

I am not sure if this terminology needs to be exposed either. So we have installers that install agents? Great kudos to us, but what is the benefit of that information to the developer who just wants to add Java support. I thought listing all agents on a page was horrific and this exposes developers to detail that they do not care about. This may be an important detail to a Che developer but I fail to see what does it contribute to others.

Besides installers on platforms such as Openshift.io that do not give sudo access are problematic. I would not really want to put a terminology that does not work well for all situations front and center.

[ghost]

I would not really want to put a terminology that does not work well for all situations front and center

Calling them agents won't fix the problem either. I think for OpenShift we need to display some warning in User Dashboard - UD itself needs to know what infra is used.

Also, stepping a bit in future, we are looking at sidecars more active, right? With sidecars, the very term installer won't make much sense since we will have the right environment and binaries to run. And we will be able to guarantee 100% successful start on any infra.

[benoitf]

It's not a display issue.

When I want to enable a terminal on top of my workspace, I enable the agent 'terminal'
then it's infrastructure responsability to provide this capability.

so in the workspace definition, I enabled agents, installer being one way of providing this requirement.

Agent is not the binary that we are executing. If it's listening on some ports, etc it's only a binary or a server or a daemon.

So the expected terminology for end user is to have in workspace definition a set of agents.
Installer being one way among several ways of the underlying infrastructure to provide this agent requirement.

[gazarenkov]

Agent it is an abstraction which provides some functionality to workspace (usually server(s) listening to some port using some protocol). To workspace It can be delivered as a binary or as a binary inside machine or other way. Delivery way is out of scope, it just has to be somewhere in the workspace and work, it existed in workspace runtime.
Installer is a (one of possible) way to provide binary to workspace's machine. Physically it is a shell script with meta-information stored in special registery. It is declared in a workspace configuration and executed on workspace start. It is not visible in workspace runtime (it downloads and installs binaries and goes away).

Both of them existed in Che, they are complimentary in some sense but totally different abstractions.

[benoitf]

@gazarenkov
I'm saying that the workspace definition contains the requirement (ie : list of agents required)
then, the infrastructure provide a set of capabilities, and implementation of these capabilities can use installers or something else

but in workspace definition, you only have agent, not installer so the workspace definition is portable. You ask for ssh, a terminal and exec feature. The way of providing is let to the infrastructure.

And in workspace runtime model, it's where you can find the binding between the requirement (agent) and the capability(which could be the installer with the version used for this capability)

And you could have policies, like optional agent/requirement (so workspace can start even if one agent is not provided by the infrastructure) (instead of removing for example ssh from all workspace definitions) https://github.com/eclipse/che/pull/7691

[gazarenkov]

@benoitf
You are talking about different delivery mechanism ("sidecar friendly") but the point is that we do not know what does that mean in terms of workspace configuration yet. Can discuss it separately if you have proposals for future development.

What we do know is that we have servers (agents) runtime and can deliver them to workspace using either:

• software provided with recipe (image) + servers configuration (port/protocol)
• installed after machine starts using installers
  What we call "agents" is about what's inside, mostly how it communicates to others, not about how it installed.

@gorkem our documentation does not contain strong definition of the things (yet) and I doubt delivery aspect is something heavily explained in our presentations in the past (otherwise I doubt this terminology would be approved by Tyler :) ). We need to make an effort on better explaining it in the documentation.
I am OK to rewording it in UD if you, guys, strongly believe it would help (though, as I said, I have an issue for the UD UX, including this aspect, but it is worth separated issue).

What I strongly disagree about is reverting it in the model using the same word for 2 different things (as it used to be in version 5).

[benoitf]

@gazarenkov I'm not talking about sidecar (I have not even referenced that word in my last comment)

It's not rewording it in UD. It's in the workspace definition. A workspace definition contains agents, not installers. (It's only you that is trying to say that).
Installer is how it's installed, the portable workspace definition should only reference agent id/names, not reference installers (which are how it's installed).

[skabashnyuk]

I would like to comment this part.

"wrong" terminology is only your point of view. To me there was nothing wrong in calling it "agent" what was agent at the time. But calling something that is being installed AND then activated AND run as a microservice just "installer" looks like a wrong terminology for sure.

I think that an "agent" might be a word with too many definitions. That is why it may provide some confusion.

Let's take a look closer this sentence installed AND then activated AND run as a microservice. Limiting of all of that to the word agent may be complex in the situation when this three thing is different. Actually - "installed AND then activated " is an installer, run as a microservice - is a server.

Some examples when "installer" is better terminology than "agent".

Imagine someone wants to install fresh htop tool(top but different) to any container where they running in development. This is something that doesn't need any expose port and doesn't need be running all the time. Or for instance, run some program that doing some license activation. This program checks something and when produce some license file and exit. It doesn't need to expose some port. In both cases calling this thing, an agent is a bit too much, an "installer" name perfect sense to me.

Same thing at runtime. If some agent is running what does this mean? Is it something accessible by some URL? Does any process that is running inside of my workspace is an agent? Instead, a server has the perfect sense to me. It is some process that provides some functionality and can be accessed by URL.

[gorkem]

What is the benefit of these details to the developer who just wants to add Java support?

[skabashnyuk]

First of all "Java support" is not an agent. It's something bigger. That is provided by a set of servers delivered by infrastructure or installed at runtime. + It might be set of extensions that adjusting in some way how IDE looks like or(and) behaves.

[gorkem]

Everybody knows and must know it is much bigger. It is a set of servers that are beamed by infrastructure, with some time traveled debuggers that are installed on continuum. and some nano bots that are added to the mix so that the IDE is morphed into a warp UI on a quantum plane. :)

I did not even say "Java Support" is an agent, I said that is what I want. What is our single line one button, drag and drop answer to that?

[gazarenkov]

@gorkem the benefit is that we can explain in plain language of what to do w/o extra questions/answers (it is a benefit of having consistent glossary and OOP "Is a ..." approach).

Like (just for example, not real one): to add Java support you have to

• install Java agent (binaries) adding "che.Java" installer (sh script) to workspace configuration

Compare with:

• install Java agent (binaries) adding "che.Java" agent (sh script) to workspace configuration

(I am not talking about other option to add it)
The Question: what is Java agent, binaries installed to container or sh script?

[gorkem]

We are not disputing there is a complexity and multiple elements involved with an agent. Ability to explain this complexity by introducing new terminology is a benefit to us but not to the developer. The benefit to the developer would be if they are never exposed to the complexity. In that case an agent can be a the combination of the delivery method(installer) and the service. but as knowing the recipe of the soup does not make the soup more tasty(in some cases the opposite 😄 ), knowing the details of an agent does not make it more useful or easy. In fact this additional information is a distraction. And simplification is not only a goal limited to the GUIs, developers interface with Che via factory.json, stack.json and chefile etc.

[gorkem]

@gazarenkov Are we taking care of this? I feel that we need to retract installers even more since the last discussion about LSP on containers.

[ghost]

@gorkem my 5 cents.

1. We can launch language servers in parallel containers. Some work needs to be done, but we can do that.
2. We can launch ws-agent in a parallel container too. #1 and #1 imply volume sharing since both need access to projects.
3. What's left is terminal and exec agent and these agents can only be launched in a particular chosen machine - sidecars do not make sense here. And the good thing is that they don't require any specific deps as they are tiny binaries compiled from go code. I bet they can run in 99% of images out there.
4. ssh agent - we can get rid of this one or if its purpose is just to sync project sources we can launch it in a sidecar too and mount /projects dir. In this case, we may call it as project sync agent, not ssh.

What am I driving at? We may get rid of installers at all, if needed and guarantee that when an agent is enabled it will run and provide extra functionality that it advertises.

[benoitf]

@eivantsov :
On the workspace definition you only need to say : agent : terminal, you dont care how it's bring. This is why installer name should be reverted

[ghost]

@benoitf I think @gorkem means we should eventually get rid of an installer as it is and look at sidecars for everything where it makes sense. Maybe I misunderstood.

[skabashnyuk]

@benoitf I think you right. From the end-user perspective, things should be simple like turn on or turn off some switch. But that you are proposing with an agent I think can reduce the power of Che as a framework. I believe that current concept with machines, servers, and installers are the perfect fundament for next features that can require a combination of basic things. Language server as a sidecar is a perfect example of that. It requires something that connects together user-defined recipes and other containers running in parallel. I worried that if we do with installer what you want, we may lose some flexibility because of too match concentration on LS as sidecars. For example, the installer of jprofiler with the exposed port as the server is perfectly fit in the concept of the installer but not very well fit in the concept of the agent.

I think that thing that you with @gorkem are talking it is another level of abstraction that can allow to combined some fundamental things to features that can be consumed by the user. And btw it can be implemented in a variety of ways, as a UI, or as part of API or model. I truly believe that we need to keep base things simple and separate as we can. We can always make complicated things above the base but not the opposite.

[sunix]

I understand the initiative to improve the power of Che as a framework. But here it is just that the name of "installer" is not right and confusing from the user perspective.
Installer would be like apt-get install jdt.ls, may or may not start the service : service jdt.ls start
I would rather see this like the list of agents that are installed by scripts in the workspace to be activated in this workspace. So finally these are agents ... specific agents but still agents, not "installers".

Here we are talking about the list that we have in factory.json or un the workspace definition: the list of "installable agents" that are going to be activated in the workspace.

Naming theses agents "installers" won't make Che more powerful as a framework ... but will confuse everyone.

[gazarenkov]

@sunix
What we specify is not agents, it is exactly the installation scripts.
It can install anything, independently if you call it "agent" (like ws-agent) or just "software" (like java, maven, node) etc.
Che Installers is a mechanism which allows to install/inject/deliver (whatever term is preferred) software into Che Machine (running Docker container in case of Docker based infra).
On the other hand agents (any software in fact) can be delivered other way - for example pre-installed and just appear inside "local" (related to other software) or other "accessible" machine (a k a sidecar).We can also imagine other ways to deliver software (agents) - for example we can control a "recipe" which describes machine content before runtime (foe example Dockerfile). Etc...

So, the terminology I had and have in mind is:

• installers - delivery mechanism
• agents - some "special for us" software (mostly what we expose as servers and|or is a server side of IDE plugins and|or LS-es)

Yes, it happen we need to specify delivery mechanism in the workspace configuration but as far as we decide to support it, specify it and have a registry (I'd prefer centralized one) to store/browse, I see nothing wrong with it. Otherwise, if we think it is not good enough due to "sudo thing" etc let's just remove it.

[gorkem]

@gazarenkov I thought we were in agreement to revert to agent on docs and UIs etc. and introduce installer as a new terminology. Are we executing on that?

[gazarenkov]

@gorkem yes, we agreed about UI.
Actually, I mentioned that above (see the comment 17 days ago)
I am OK to rewording it in UD if you, guys, strongly believe it would help (though, as I said, I have an issue for the UD UX, including this aspect, but it is worth separated issue).
I do not think we are executing since I see no issue about it (@ashumilova knows better).

[gorkem]

@gazarenkov Also documentation too. It should not use installer and agent as something interchangeable and should explain installers as a separate concept.

[benoitf]

the JSON as well as it's now manipulated by users.

[ghost]

@benoitf do you mean changes in the model too?

[gazarenkov]

@gorkem sure, it is 2 different things, thats what we always have in mind. It will be clearly explained in Che6 documentation.

[benoitf]

@eivantsov yes because model is documented and exposed

[ghost]

@gazarenkov so it's not just a dashboard issue now?

Also, in docs an installer is termed as a tool to prepare environment, deliver and launch agents. I am a bit lost in the discussion here. If we rename installers into agents, what an installer is then?

[gazarenkov]

@eivantsov this issue never been a "dashboard issue", that is the problem.
What I am doing here - is exactly trying to explain that it is 2 different things, but some ppl around convincing me that installers does not exist

[slemeur]

Yes @gazarenkov we are trying to convince you that "installer" is not an appropriated wording to name a tool to prepare environment, deliver and launch agents as in many cases, nothing will be "installed".

We are also trying to explain that this wording should not be exposed at all. The way the agents are delivered to the end-user is the problem of our infrastructure. We are also trying to explain, that, introducing "installer" is breaking a more fundamental core concept and value of Che, which is "portable workspace".

The following model, used for workspace's JSON, which will also impact factories and chefile:
"dev-machine": { "installers": [ "org.eclipse.che.exec", "org.eclipse.che.terminal", "org.eclipse.che.ws-agent", "org.eclipse.che.ssh" ], }
Is putting installer as a first citizen elements, where it should just be agents - the running system, being able to understand how to deliver the agents to the end-user:

• the system on infraA could then use an installer to enable the agent
• the system on infraB could then use a sidecar to enable the agent
• ...

So, indeed the issue requirements are to avoid exposing installer terminology to end-user and as consequence, revert back to agents (which was perfectly fine in Che5) instead of installers in workspace's JSON, factories and chefile - as well as in the dashboard.

[vparfonov]

In my mind explanation for "installers" -> "a tool to prepare environment, deliver and launch agents" is clear. And explain that exactly we do during starting machine. Like parallel in real world when you install some software on your PC some installers have options start this software after installation other doesn't.
About compatibility with Che 5 factory and chefile as i know we have task in current train for make universal format for this stuff.
So i don't see any reason for renaming.

[ghost]

The purpose of an installer is quite straightforward. An installer installs software and services, start servers, activates agents etc. Some of the servers are crucial to the IDE and workspace in general, such as workspace agent, exec agent and terminal. Others just bring new functionality to a workspace - language servers, SSH daemon. Bootstrapper executes installer scripts that prepare environment, check for dependencies and install components defined by an installer. You may want to take a look at an example of an installer script that prepares environment and installs C# language server.

This is what I have in Che6 docs as a draft. And this is exactly what an installer script does.

[gorkem]

@vparfonov you just made me realize why installers feels wrong as a term. It is a term that is associated with PCs and does not associate right with cloud.

[gazarenkov]

@gorkem but that's exactly how it works now, we point to the script which installs software on running machine (container or PC, whatever), it is not a "right cloud solution".
If you think "installer" is the bad word then propose other but if it is "agent" then propose other word for what we call "agent" now (the soft we actually install).

@slemeur
we are trying to convince you that "installer" is not an appropriated wording to name a tool to prepare environment, deliver and launch agents as in many cases, nothing will be "installed".
No needs to convince me, I agree that in case we do not need "installer" we do not include it in workspace definition (add something else instead).

The way the agents are delivered to the end-user is the problem of our infrastructure.
that was the problem of Che5 since in this case user who wanted just to add a script to install software had to be aware of infrastructure specific mechanism to to deliver and run this script. In Che6 it is improved adding one more layer called "bootstrapper" as an infrastructure specific mechanism of delivery installers to this particular infrastructure.
So it lowers threshold for installer (just a script) author and makes installer launch-able on potentially any infrastructure which supports it (i.e. has "bootstrapper").

[sunix]

@gazarenkov Hold on ... this script may OR may not install anything. If someone authors a script like this one https://github.com/eclipse/che/blob/master/agents/ssh/src/main/resources/installers/1.0.0/org.eclipse.che.ssh.script.sh, it will ... maybe ... install the dependencies if they are not present but the final result is that the sshd service IS STARTED. This is the main goal of this script: to start the sshd service, not to install the dependencies. We've been naming these things "agent" for years and "installer" feels like it's only installing thing which is wrong.

@vparfonov I just don't see what is clear in what you are saying.

a tool to prepare environment, deliver and launch agents

But there is nothing about a tool that installs something ... I don't how this can be clear.

Can we just go ahead and keep "agent" like it was before ? Please

[gazarenkov]

@sunix I think this aspect was discussed above. It is up of particular installer to make a decision if and when copy/run some software (that's what any installer does).
Again:
1/ we still call "agent" software we use, such as "ws agent", "terminal agent" etc
2/ we call "installer" (for "agent" if you will) a script which copy and|or run software (agent)

It is a bit strange to have it raised after months (almost a year) of adding the Installer notion but we can imagine other names if someone propose.
But it is 2 terms to consider, so, if you want to call number 2 "agent" then propose how to call number 1 which we call Agent for years (such as "ws agent", "terminal agent")

For what it worth (it is interesting to remind :) ) - we have term "agent" (in terms of "workspace agent" mostly) for about 2 years, starting from Che5, I remember the moment it was proposed.
We have a publicly available issue for reworking agent installation which caused "installer" emergence for 11 months: https://github.com/eclipse/che/issues/3971

[sunix]

@gazarenkov Here we are talking only about what the user sees: from the factory.json and from the dashboard UI. This is like our API, we are not talking about internals. Whatever you have behind, the user sees the agent as a piece of software that is injected into the initial workspace container. The agent is not defined in the initial container definition (dockerfile). In the factory.json or dahsboard UI, user wants to activate agents, weather it has to install additional dependencies or not. If we call internally the script installer it is ok but the user won't understand. User just want to activate/deactivate agents that's all. User shouldn't have to know that it is going through a script or whatever. User wants features to be injected in the workspace. Installer name is not appropriate to be exposed in the factory.json or dashboard UI. Call it agent, feature, injected service, capability, whatever but not installer. agent is the best option because we won't have backward compatibility issue just because we don't like the name. And backward compatibility is strongly important when we are building a framework.
In https://github.com/eclipse/che/issues/3971 I can't see any mention about renaming agent to installer in factory.json and dashboard ui.

[skabashnyuk]

@sunix I think we might need to stop thinking about our users as stupid chickens. I understand and mostly agree with you that UI-UX should be pretty simple in enabling or disabling some feature. Moreover, I think that users don't care about even "agenA" or "Agentb", they want features, functionality. That is why it's more term of UI. When we are talking about this issues in terms of Che as framework again I don't agree to have some things abstract that enable something abstract on the background and call it "agent". What if that abstract behavior is different when user expect what if LS that runs as sidecar he wants to run as a process inside of the specific machine. Who knows? I think we never can imagine all possible variants. That is why we should not gues to try to provide something abstract, we should provide appropriate instruments. And I think "installer" is a good instrument. Because it did a real concrete thing - "deliver software" to the concrete machine.

You think that "installer" is not a proper UI term? No problem lets call it "Features" or "X Agent"

[sunix]

@skabashnyuk when I refer users, I also include myself and don't coïncider myself as a stupid chicken. This is why we have that discussion.
To summaries, Installer doesn't mean deliver software, it means install something (what ? we don't know) which is not right. Maybe I am a stupid chicken but I don't see how an installer can be about delivering software ... it's about installing something . That's all.

[sunix]

Agent is commonly used in our world to define something that we inject to an existing system. For instance, Java agent, or monitoring tools have agent that you add to your system. This is exactly what I understand che5 agents or che6 installers are. To me sidecars are not agents ... they are sidecars :)

[gazarenkov]

@sunix read definitions above, it is not a rocket science.
Installer installs agent, agent provides functionality.
Notion of agent is the same for che5 and che6.

Sidecar it is alternative to installer mechanism of agent delivery.

[sunix]

@gazarenkov again this is wrong:
An 'Installer' installs and deploys an agent. In other term it activates an agent. This is what the user wants to be able to do in dashboard or factory: activate agents ... not activate installers ...
Let's just change in factory.json and dashboard the name installer to agent and we are good.

[skabashnyuk]

@sunix @slemeur if you want to name installer as an agent, then how do you call workspace agent?
It would be some workspace agent that activates workspace agent but they are different?

[gazarenkov]

@sunix
An 'Installer' installs and deploys an agent - exactly
And UD user ask to install installer, not agent.
If you go to the registry by installer ID written in Workspace configuration you will see installer script (not executable Agent). You may see mentioning of agent to be installed by this installer such as "ws-agent" in Installer's name or|and description.

That is the correct reading, quite easy to explain to any unbiased user.

[sunix]

@gazarenkov

• To "Install installer" doesn't sound wrong to you ?
• An installer that installs AND DEPLOYS AN AGENT, doesn't sound wrong to you ?

I don't see how these can be correct reading ...

So what you describe are actually scripts that do something ... could be installing or not, could be deploying or not. So installer is not a good name. They are more like 'init scripts' to activate agents, definitely not installers ... because these scripts could do whatever not related to installing something. But finally the goal is to activate agents right ? If this is the case, let's finish this discussion and show to the user the ability to activate agents somehow. The simplest way is to rename 'installer' to 'agent' like before. Keep it simple stupid ;)
++ backward compatibility which has te be concidered in any framework anytime even when changing major version.

[sunix]

unbiased user ? ... we are the first Che users and we are raising issues that real user will face when Che will get released.
This issue came out when I had existing factory.json that wasn't working anymore because of these changes. And the first question was ... are LS, terminal, ssh agents not agent anymore ? But it looked like they still were agents so I can't see how you will easily explain that change to any user. We now have 60 comments in this issue and I still don't understand this naming. Sorry.

PS: It can be easy to explain but it's better not to have to explain and if things are straight forward without any explainations.

[sunix]

Normally when you install something you do it once. So it means that if I activate the "installer" 'C# Language Server', start the workspace, stop the workspace, deactivate the "installer" and restart, the C# Language Server is expected to be "installed" and running and I expect to be able to use it.
But, it sounds really wrong or at least this is not the current behaviour.

[skabashnyuk]

@slemeur what is your plan for this issue?

[skabashnyuk]

@slemeur says that we would not fix this issue.