Source packages from package manager

[thompson-tomo]

In light of the packaging SIG I have been thinking about how the process to setup auto-instrumentation can be streamlined while also ensuring this streamlining doesn't just transfer the burden.

One area which stood out is how can we leverage opamp & package managers to simplify the process to update the auto-instrumentation agents.

What I came up with is:

• a single supervisor should be able to update multiple-agents (already there)
• rather than manually downloading files & running them, we should be able to specify a package manager to use to install it. Along with the path.
• agents should report the supported package managers.

In the end we end up with supervisor reporting to the server that it supports nuget, the server informs the agent/supervisor when a new nuget is approved for installation. The supervisor installs the new agent by invoking nuget using the information provided. The status is reported back.

[tigrannajaryan]

• rather than manually downloading files & running them, we should be able to specify a package manager to use to install it. Along with the path.
• agents should report the supported package managers.

This sounds like a specialized "agent" that does all these things. Why does anything needs to change in the OpAMP spec for this to be possible?

[thompson-tomo]

The key thing is how can an agent know that a package manager is to be used let alone which one based on the proto

message DownloadableFile {
    // The URL from which the file can be downloaded using HTTP GET request.
    // The Server at the specified URL SHOULD support range requests
    // to allow for resuming downloads.
    string download_url = 1;

    // The hash of the file content. Can be used by the Agent to verify that the file
    // was downloaded correctly.
    bytes content_hash = 2;

    // Optional signature of the file content. Can be used by the Agent to verify the
    // authenticity of the downloaded file, for example can be the
    // [detached GPG signature](https://www.gnupg.org/gph/en/manual/x135.html#AEN160).
    // The exact signing and verification method is Agent specific. See
    // https://github.com/open-telemetry/opamp-spec/blob/main/specification.md#code-signing
    // for recommendations.
    bytes signature = 3;

    // Optional headers to use when downloading a file. Typically used to set
    // access tokens or other authorization headers. For HTTP-based protocols
    // the Agent should set these in the request headers.
    // For example:
    // key="Authorization", Value="Basic YWxhZGRpbjpvcGVuc2VzYW1l".
    // Status: [Development]
    Headers headers = 4;
}

As such the extension would be to indicate which package manager is to be used.

This sounds like a specialized "agent" that does all these things.

I don't see it as specialised but rather base functionality as a way to install auto instrumentation.

The extension for the agent to server message is so that the server knows which package manager can be used.

In effect we would be able to install a generic otel package ie system package which includes the agent. Once the agent discovers the server, all the required auto instrumentation is installed. This makes an easy on boarding path.

[tigrannajaryan]

I don't see it as specialised but rather base functionality as a way to install auto instrumentation.

By design, this is not a concern of OpAMP protocol. OpAMP has no opinion about it and that's a deliberate design choice to make sure OpAMP is generic and can be used widely, not just for Otel.

This is what the spec says about packages:

The content of the file, functionality provided by the packages, how they are stored and used 
by the Agent side is Agent type-specific and is outside the concerns of the OpAMP protocol.

The key thing is how can an agent know that a package manager is to be used let alone which one based on the proto

The way the agent is expected to known is by having that knowledge coded in the agent. It should not be based on the proto. Have an agent the purpose of which is to receive packages from OpAMP server and install the packages using system package manager.

[thompson-tomo]

By design, this is not a concern of OpAMP protocol. OpAMP has no opinion about it and that's a deliberate design choice to make sure OpAMP is generic and can be used widely, not just for Otel.

The additional field doesn't change that in fact it broadens it's usage as it can be used to install any package from the package managers registry ie any nuget, rubygem and not just auto-instrumentation.

The content of the file, functionality provided by the packages, how they are stored and used
by the Agent side is Agent type-specific and is outside the concerns of the OpAMP protocol.

That wouldn't change as the download_url field would/could be pointing to the package manager registry & not opamp server.

Have an agent the purpose of which is to receive packages from OpAMP server and install the packages using system package manager.

I am not seeing how this would be possible other than repackaging the package from the package manager registry to add in a file telling it to install it using the package manager.

If we had a field in the message to indicate the package manager, that repackaging is eliminated and if servers want they can leverage package manager registry rather than self host the packages.

[tigrannajaryan]

I am not seeing how this would be possible other than repackaging the package from the package manager registry to add in a file telling it to install it using the package manager.

Why would you need to repackage anything? I am confused.

I am suggesting to implement your custom agent that downloads packages specified in DownloadFile and then uses "apt" to install the package. This doesn't require any changes to OpAMP spec, proto or how the files are stored on download server.

[thompson-tomo]

Why would you need to repackage anything? I am confused.

I am suggesting to implement your custom agent that downloads packages specified in DownloadFile and then uses "apt" to install the package. This doesn't require any changes to OpAMP spec, proto or how the files are stored on download server.

Because if you download a *.tgz package how do you know to install it using npm or another package manager which supports tgz. This could be addressed via an additional proto field (prefered) or repackage the package file adding metadata file indicating which package manager to use to install it.