[Fleet APM Integration] static Java agent version list becomes stale quickly

[eyalkoren]

When creating an Agent policy with APM integration and using the new (beta) Java Agent attacher, one of the integration config options is the APM Java agent version. Currently, this config is a combination of a text box and a pre-populated dropdown list of proposed versions:

It's not very clear that this is a free-text input, but even if it was, most users would likely just choose one of these options. The problem is that this list is statically created on build time, which means that it will become stale very quickly. In the worst case, the latest version in this list would contain a version that has a severe bug that was quickly resolved and released, but users will be tricked to use it.

Easy fix:

• Remove the version list
• Add a link to our GitHub release page or official Release notes
• Add an example: Version (for example: "1.30.0").

Ideal fix:

Fetch available versions from maven central at runtime in the integration page

[elasticmachine]

Pinging @elastic/apm-ui (Team:apm)

[dannycroft]

@eyalkoren Hey! We (UI Team) spoke about this in our refinement recently and I wanted to just make a some clarifications here.

The "Easy fix" seems like the best way forward here, because of what would needed to be clarified for the "Ideal fix" in terms of unknowns.

Querying an API for the available versions would be a lovely solution here. But I'm not sure about an external API (in this case repo1.maven.org but alternatively api.github.com). I feel like the security team might have something to say about that, and I'm not even sure that our systems can guarantee access to these APIs in the enviroments they will be running in e.g. behind firewalls etc

Do you know of any other examples of features relying on external API access?

Next steps I can see:

1. If we want to persue the "ideal fix", can we achieve this in another way where we aren't relying on an external API
2. We need to clarify if there are any security issues (we might be worried for no reason)

I can look into number 2, and see if anyone can provide insight into number 1. But any other insight or opinion here would be appreciated.

cc @AlexanderWert @simitt

[eyalkoren]

The easy fix is certainly enough for now.
Looking forward, we will probably want the Java agent to come as any other Fleet integration package, in which case I assume there would be a builtin support for available versions.
If that's the case, let's not waste efforts on that.
I hope this makes sense.

[dannycroft]

@eyalkoren OK, let's move forward with the easy fix for now.

[cauemarcondes]

@eyalkoren in the current version there's a default value, which is the first element from the static list of versions. Do you want to have a default value set in the text field? Should this field be required, meaning the save button is going to be disabled until a valid version is added.

[eyalkoren]

Do you want to have a default value set in the text field?

No, I don't think having a static version as default would serve us right, unless it is latest (which is currently not supported)

Should this field be required, meaning the save button is going to be disabled until a valid version is added

Good question! Ideally, the least we require is best. I am not sure which cli artifact we are using for this integration, but either way, we probably need to make it required at this point- if we use the slim jar, than it is definitely required and if not, we will use the prepackaged agent, which has the same problem we try to avoid.

@felixbarny what do you think about adding special handling for latest? It should be extremely easy for us to special-case this one and construct the proper URL (I found https://oss.sonatype.org/service/local/artifact/maven/redirect?r=releases&g=co.elastic.apm&a=elastic-apm-agent&v=LATEST, maybe there is another). Then we have both a good default and we don't have to make it a required config.

Regardless, I think it would be useful if the description of the text field will contain either example for proper versions like 1.30.1 or a link to available versions or both. Options for possible links showing available versions:

• https://mvnrepository.com/artifact/co.elastic.apm/elastic-apm-agent
• https://github.com/elastic/apm-agent-java/releases
• https://www.elastic.co/guide/en/apm/agent/java/current/release-notes.html

[felixbarny]

@felixbarny what do you think about adding special handling for latest?

SGTM

Regardless, I think it would be useful if the description of the text field will contain either example for proper versions like 1.30.1 or a link to available versions or both.

Adding a example version, such as 1.30.1 has the same issue in that users may copy/paste and it gets stale quickly. I'd link to the release notes which have more info about each version.

Should this field be required, meaning the save button is going to be disabled until a valid version is added

Yes, for now, the save button should be disabled. After we have enhanced the attacher and updated APM Server to use it, we can add a default value latest.

[eyalkoren]

Adding a example version, such as 1.30.1 has the same issue in that users may copy/paste and it gets stale quickly.

No, this is entirely different and has nothing to do with getting stale, you could even give 1.0.0 as an example and add any description around it. All I want is that users see the general form, know that it is semver with three levels. Consider this text: "The agent version to attach, in a sem-ver form - <MAJOR>.<MINOR>.<PATCH>, for example: 1.0.0".

[cauemarcondes]

So far it looks like this:

I can add a link to any of the links @eyalkoren mentioned above.

So I should save latest in the version if no version has been provided?!

[eyalkoren]

Current fix

• empty text field, without default or proposed version
• description: I can't say what is a proper form for UI text field description, but the general content should be something like: "Fill with a valid version, for example: 1.0.0"

Future enhancement

Once we implement elastic/apm-agent-java#2614 and the APM Server is released with a version that contains this addition, we should use latest as the default.

@felixbarny please approve or correct

[felixbarny]

Suggested description:
Enter the version of the Elastic APM Java agent that should be attached.

I would remove the example as I still think there's a risk users will just type in the example, such as 1.0.0. The field should be validated with a regex, such as \d+\.\d+\.\d+. But IIRC, that's already the case, right @cauemarcondes? Do you know what the error message is when someone types in foo?

[cauemarcondes]

But IIRC, that's already the case, right @cauemarcondes? Do you know what the error message is when someone types in foo?

Yes, that's already the case @felixbarny . It shows an error message:

[cauemarcondes]

@eyalkoren / @felixbarny PR is up here #131759