Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

V2Tool ‘server mode’ #41

Open
belimawr opened this issue Oct 14, 2022 · 5 comments
Open

V2Tool ‘server mode’ #41

belimawr opened this issue Oct 14, 2022 · 5 comments
Labels
8.7-candidate Team:Elastic-Agent Label for the Agent team

Comments

@belimawr
Copy link
Contributor

The V2Tool should read its server configuration information from a configuration file and start the GRPC server following it.
Every time a client (shipper, inputs, etc) connects to the server, the server will send corresponding configuration in the same way it would if it had started the binary.

Clients connecting/disconnecting should be handled gracefully, there should be no need to re-start the V2Tool once it’s running.

Once the server is started, it should log the connection information: host, port, T;S status (enabled/disabled), connection token (it’s for testing, it’s not meant to be secure). Logging the token might be a point for further discussion.

@fearful-symmetry
Copy link
Contributor

I wonder at what point we should convert the tool to use the "real" elastic-agent server and not the mock server. The mock testing server is super lightweight, and it was how I managed to get this working in 4 days. If we want this to more dynamically start and stop connections, it might be worth looking into just importing the component managers that live in elastic-agent/pkg/component/runtime and spin up the same server code that elastic-agent does.

@fearful-symmetry
Copy link
Contributor

So, after going over the code for a bit, I think replacing the Mock V2 server with the agent server probably makes the most sense. In the long term it'll require us to shuffle around the agent code to move things out of internal/, but we don't have to worry about correctly emulating the agent server, and it'll be much easier to run the tool as a server that can dynamically start and stop clients.

This also makes the possibility of a "server mode" much easier, as we don't need to worry about the config for GRPC, we can just pass the server a path to the executable, and it'll handle the connection details.

As far as making it actually work, it looks like we just need to create our own Manager instance in pkg/component/runtime, then call Update() with a component file that we've generated.

@belimawr
Copy link
Contributor Author

That sounds great @fearful-symmetry! Should we create a new task to start using the Elastic-Agent server and have it as pre-requisite for this one? Or do you think it can be all done as part of this task?

@fearful-symmetry
Copy link
Contributor

I actually made a little proof of concept last week. There's still some weird behavior that I can't quite figure out (it can take the agent a few seconds to actually tell a client to shut down, not sure why), but other than that, it seems to work.

As far as how many tasks/issues this should be, we should probably just have it be two separate issues. If we get both done in one pass, then we can just close both issues.

@belimawr
Copy link
Contributor Author

Cool, I created another task: #46. Feel free to edit it/add your findings/experiments there.

@pierrehilbert pierrehilbert added the Team:Elastic-Agent Label for the Agent team label Oct 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
8.7-candidate Team:Elastic-Agent Label for the Agent team
Projects
None yet
Development

No branches or pull requests

4 participants