Add section in workspace to handle the agents

[ashumilova]

We will need a new section in the workspace details to handle the agents.
This is a proposed design that we will iterate.

[ibuziuk]

@ashumilova I have started to work on this one. After browsing a little bit through REST API I figure out how to get agents per workspace:

this.agents = this.workspace.config.environments.default.machines["dev-machine"].agents;

Basically, the agents' names for my test workspace are:

org.eclipse.che.terminal
org.eclipse.che.ws-agent
org.eclipse.che.ssh

looking at the mockup I find it hard to understand how can I get agents' "state" and "description" properties. REST API for agents e.g api/agent/name/org.eclipse.che.ws-agent return object with properties like: "name" / "dependencies" / "properties" / "script". Am I on the wrong track ?

[slemeur]

@ibuziuk : Glad, and super excited to see you contributing to Che. Please give a look at the updated mockup.

Agents will be defined per machines in environments.

In the agent section, you'd have the ability to see the whole list of agents installed with Che. User will then just have to use the slider to activate the agents in the machine or not.

[ibuziuk]

@slemeur hey, buddy! I also super exited having a possibility to contribute - for now I'm only getting familiar with a code base though. New mockup looks completed, however I still baffled with the agent properties "state" / "description" - I can not figure out what API should be used here.

[tolusha]

Currently agents don't provide description.

[ashumilova]

What we have is dependencies, properties and script. @tolusha can we add description - to have smth human readable.

@ibuziuk about state - the state is determined whether machine includes the agent provided by Che or not. So we display all agents provided by Che in the list, and those that are mentioned in machines agents list - are active for this machine, others - inactive.

[slemeur]

@tolusha : Each agents must be provided with a set of meaningful information for end-user.
When I see the name = "org.eclipse.che.terminal" and all the properties you have related to the agent, they seem perfect for internal - but definitely not to be exposed to end-users.

Please create the issue to improve this area.

[ibuziuk]

@tolusha @ashumilova Thanks for clarifications

[ibuziuk]

@slemeur @ashumilova As it was mentioned above Che Agent API is missing "description" property and the "name" property like "org.eclipse.che.ls.json" does not look viable from the user perspective. So, I guess with the current version of API the best layout would be the following (please, let me know if it is ok for the initial implementation):

Basically, in the next iteration it would be great to change the Agents REST API the following way:

1. Add id field. The value of it would be the current value of the name field i.e. org.eclipse.che.ls.json
2. Amend name field so, that it would reflect meaningful name of the agent i.e. JSON language service
3. Add description field
4. Change REST API, so that new id will be used instead of name e.g. change GET /agent/name/{name} to GET /agent/id/{id}

WDYT ?
If you think it is relevant, I would be glad to work on it ;-)

[TylerJewell]

Yes, yes, yes, and yes. :)

I think using the fully qualified name as you have it is a reasonable first start so that we can go ahead and get the capabilities merged into master. We can then make an improvement PR once the API is updated. So I am +1 for splitting into two segments.

[ibuziuk]

@TylerJewell awesome! I am planning to provide the initial implementation by the end of the week

[TylerJewell]

That is really awesome. There are just a couple of lingering language server and agent bugs, but if all goes well, we may have a shippable release with agents and language server by next week!

[ibuziuk]

@ashumilova @slemeur @TylerJewell while implementing the agents enabling / disabling I have noticed that API does not allow to disable ws-agent agent:

Am I correct that the switch for this agent should be permanently disabled ?

[ashumilova]

@ibuziuk yes we have that restriction that at least one machine in environment should be with ws-agent.
Perhaps it should be disabled in case it's the only one machine with ws-agent. @slemeur what do you think?

[slemeur]

@ibuziuk and @ashumilova : Yes at least one machine from the environment needs the ws-agent. I think we should use the "Dev" slider to handle that.

The "ws-agent" will still be listed in the agents list, but in disable state.

[ibuziuk]

@slemeur just want to be sure that we are on the same page:

• ws-agent switch is listed but always disabled for machine regardless of it's state
• switching of the ws-agent happens only via "Dev" slider

I'm polishing my PR now, but I do not really know when 5.0.0-M3 is going to be released to be sure that the fix will be ready on time for it

[ashumilova]

The approximate date of 5.0.0-M3 release is Monday (09/26).

[ibuziuk]

@ashumilova oh, awesome I was thinking it's today ;-)

[slemeur]

@ibuziuk : yes perfect! we are on the same page ;)

[ibuziuk]

@ashumilova @slemeur PR is ready - #2577
The biggest concern is that enabling / disabling agent results in screen blinking. Actually, it is also true for other sections like "Dev" / slider in "RAM" - for agents it is more noticeable though.

[ashumilova]

Fixed by @ibuziuk

[ibuziuk]

@ashumilova @slemeur as I understand it was decided to split this issue in two parts. First one is done and merged, the second one is coupled with changing Agents REST API and adjusting front-end part for it. Should I work on the second part ?

[slemeur]

@ibuziuk Yes sure ! It would definitely be great for the product !
We have not planned this work in the upcoming sprint for us, so if you would like to contribute it, it would be wonderful :) !

[ibuziuk]

@slemeur great! should I create another issue for it ?

[slemeur]

@ibuziuk Yes please, it would make it clearer ;)

[ibuziuk]

@slemeur done - #2654