-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Comments
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). |
If you run the docker, you can use the image tag? |
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 |
@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. |
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.). |
Closing this since this issue is over two years old and I think we have this functionality now, though one of a few mechanisms:
We could likely stabilize the format of (2) and (3) in the future if obtaining this through an extension is not considered sufficient. |
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:
--version
flag (not very reliable since the output format is not precisely defined).The text was updated successfully, but these errors were encountered: