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

Ability to access Collector's executable's version number programmatically #5438

Closed
tigrannajaryan opened this issue May 27, 2022 · 7 comments
Labels

Comments

@tigrannajaryan
Copy link
Member

For Agent Management the Supervisor needs a way to fetch the version of the Collector's executable it is supervising.

There are a few options:

  • Have a manifest file with version number recorded in it and include the manifest in Collector's installation packages.
  • Try to fetch version number from executable directly (as a symbol?). Not very desirable since it requires platform specific code.
  • Read from CLI by using --version flag (not very reliable since the output format is not precisely defined).
  • Something else?
@mx-psi
Copy link
Member

mx-psi commented Jun 1, 2022

To me what sounds most reasonable is to have an HTTP endpoint that you can query, followed by the manifest. I don't have the full context on why we need this, but I don't know if this would work very well with distros that follow an independent versioning scheme. Is that something that is accounted in the Supervisor's design?

@tigrannajaryan
Copy link
Member Author

To me what sounds most reasonable is to have an HTTP endpoint that you can query, followed by the manifest. I don't have the full context on why we need this, but I don't know if this would work very well with distros that follow an independent versioning scheme. Is that something that is accounted in the Supervisor's design?

HTTP endpoint won't work. It requires the Collector to be up and running, which is not possible for my use case. The Supervisor needs to know the Collector version to fetch the appropriate configuration for it (the config can be version dependent) and then to run the Collector. So, we have a chicken and egg problem. The Supervisor cannot run the Collector without knowing its version (well, maybe it can do some speculative run with a dummy config, but that's fragile and error prone and looks wrong just for the purpose of obtaining the version number).

@bogdandrutu
Copy link
Member

If you run the docker, you can use the image tag?

@mx-psi
Copy link
Member

mx-psi commented Jun 1, 2022

Thanks for the context @tigrannajaryan, I didn't realize that. I still don't understand why we want the Collector version (since different distros can have different versioning schemes, see e.g. the AWS distro which is currently at v0.18.0 but uses components from v0.51.0), it feels like to make this work in all distros what we want to have is either the protocol version supported or a way to ask the binary what capabilities it supports

@tigrannajaryan
Copy link
Member Author

I still don't understand why we want the Collector version (since different distros can have different versioning schemes, see e.g. the AWS distro which is currently at v0.18.0 but uses components from v0.51.0), it feels like to make this work in all distros what we want to have is either the protocol version supported or a way to ask the binary what capabilities it supports

@mx-psi Think of a central configuration Server where you can specify configurations per Collector distro/version combo. The Supervisor will connect to this Server (using OpAMP), ask for a configuration for the Collector that the Supervisor needs to supervise. The Server will return the appropriate configuration, the Supervisor will save it as a local file and will run the Collector. The configuration does not have to be different for different Collector versions, but it can (for example there is a know bug in a specific version which can be worked around by providing a different configuration). Similarly, configurations may or may not be different for distros.

The decisions about having different configurations per Collector version or distro ultimately belongs to the end user. We do not want to hard-code these decisions. Instead we want to have the necessary flexibility for the end user to make such choices if they need to. For this reason OpAMP is designed to send to the Server all known information about the Collector (version, distro name, etc) and ask for the relevant configuration for the Collector.

@tigrannajaryan
Copy link
Member Author

If you run the docker, you can use the image tag?

If tags are readable by processes running inside the container then yes, this is a good option for dockerized Collector. We still need a way for non-dockerized distributions (rpm, etc.).

@evan-bradley
Copy link
Contributor

Closing this since this issue is over two years old and I think we have this functionality now, though one of a few mechanisms:

  1. The OpAMP extension
  2. The components command that includes a buildinfo section. The output of this command is YAML formatted, though I don't believe it is stable.
  3. The --version flag that outputs this information. This is also not stable.

We could likely stabilize the format of (2) and (3) in the future if obtaining this through an extension is not considered sufficient.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants