Open ycombinator opened 2 weeks ago
Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)
We already have detection for most (all?) of these cases: https://github.com/elastic/elastic-agent/blob/49579aea2c4bb9901e5212695249af63cc02c074/internal/pkg/agent/application/upgrade/upgrade.go#L69-L74
When we do this, we should consider including a --force
flag or similar as an escape hatch in case this logic ever has a bug. We report the upgradable
state to Fleet and it is used to block upgrades from the UI, but there is an underlying API with a similar force flag in Fleet.
I was more thinking about introducing a placeholder/marker file like upgrades.disabled
file in the agent main directory and only add it to the packages where the update is off by default. This should be pretty simple to implement
I like it, much more reliable. We should replace the existing upgradeable check with that.
I agree with Paolo as well. Whether the agent is upgradable this way is really a property of the package, and so should be part of it in some way. A marker file is straightforward enough, and can only be wrong due to packaging bugs.
Describe the enhancement:
Standalone Elastic Agents that are running in a container or deployed via DEB or RPM packages should not be upgradable using the
elastic-agent upgrade ...
CLI command.Describe a specific use case for the enhancement or feature:
What is the definition of done? Running
elastic-agent upgrade
for standalone Elastic Agents should fail with a descriptive message when Elastic Agent is deployed: