Machine Agent specification and implementation

[garagatyi]

We have new abstraction called agent to applying on Machine on start time
https://docs.google.com/document/d/1fEO8iY8JnfeGxYVEQV6TMIiGbiwNEYqvH1f_ctjATkc/edit
Agent essentialy means the script to call when Machine starts (using Docker exec in case of Docker Machine for ex).
For the time we talk about 3 types of agent:

• Dev (which includes what we need to dev machine)
• Terminal (web terminal)
• Ssh
  After we consider Language Server to be processed as an Agent.

The goals are:

• to specify how to name, package and run Agent (needs a comprehensive specs in GDoc for example) Specify how to name, package and run Agent #2005
• implement Agent API Implement Agent API #2008
• adapt deployment to those changes https://github.com/codenvy/deployment/pull/122 2 SP
• package language servers agents Implement and pack Language Server Agents #2032
• package terminal agent Pack terminal agent #2074
• package dev agent Package dev agent #2073
• package ssh agent Pack ssh agent #2156 1SP
• upload new agent binaries to Codenvy Update Server Continuously upload new agent binaries to Codenvy Update Server #2137 1SP
• test agents over different containers Test agents over different containers #2138 2SP
• test agents in Codenvy 1SP
• adopt to new environment model Adopt agents to new environment model #2285

NOTE: for this iteration for simplification we suppose that all the ports mapping (if needed for agent) is declared in the servers section of environment, will see then.

[TylerJewell]

@gazarenkov @tolusha @vkuznyetsov - can we define a little more detail for the specification of done here?

1: How will stacks defined by users reference a minimum set of agents that are mandatory? I know that this agent concept is built into the workspace definition, but how does it map out to the stack level?

2: Will there be any user experience around the process of removing stacks where we communicate potential issues that the system may face when an agent is removed from a running workspace?

[gazarenkov]

1. The model is stack -> workspace -> environment -> agents. I.e. when you define stack you define all the chain.
2. Agent's presence is sufficient for workspace/machine start time. After agent materialized to scripts/program installed and|or launched inside machine. So "removing agent from running workspace" makes no sense.

[TylerJewell]

What about the use case where a user has an existing workspace that is running and they wish to add a new agent to it. Specifically, user:
1: Creates new blank workspace.
2: Performs a git clone to get some code installed in a blank PT.
3: User opens a file with a .ts extension
4: We recognize that .ts has a language server agent available
5: We invite user to add ts language server - they say yes
6: We add language server.

Are we going to be able to avoid restarting workspace in this situation, as I think it is reasonable. And then the same would be true for user who wants to remove such agent.

[tolusha]

Agent might require additional workspace configuration that can be done only before workspace is started.

[gazarenkov]

@TylerJewell yes, in all of this cases workspace should be restarted. What we need for the cases like this is good UX.

[slemeur]

I had this first draft mockup for managing the agents from a workspace.

I have few questions about the agents:

• can the user get the complete list of available agents?
• are the embedded stacks, providing a list of pre-defined active agents and a list of approved agents (by approve, I mean - agents that we know will work with the stack)
• can the user upload an agent, to a workspace's machine or to the system?
• in a multi-machine modes, is the user defining where the agents must be deployed? or they are always deployed in the dev-machine?

I understand the UX problem you are mentioning about reconfiguring a workspace which can be done accross multiple options and then having to restart the workspace to apply the new configuration. This is a separate issue we should not bother about for now - just focus on the use cases.

[tolusha]

• we can only provide list of Che agents but we keep in mind that user can inject any agent he wants by adding corresponding url.
• agents have nothing with the stack. They belong to workspace.
• clarify pls "upload agent" ?
• they can be deployed on any machine

[gazarenkov]

@slemeur do not overthink about Agent UI
In fact it is small part of Workspace Environment conf, I would say it is a list + field to add new (which may be dropdown list if/when we are able to retrieve all accessible agents from registry) in Environment configuration page.