elastic / elastic-agent

Elastic Agent - single, unified way to add monitoring for logs, metrics, and other types of data to a host.
Other
17 stars 144 forks source link

Prevent users from upgrading standalone agents in container, deb, and rpm environments #5832

Open ycombinator opened 2 weeks ago

ycombinator commented 2 weeks ago

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:

elasticmachine commented 2 weeks ago

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

cmacknz commented 2 weeks ago

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.

pchila commented 2 weeks ago

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

cmacknz commented 2 weeks ago

I like it, much more reliable. We should replace the existing upgradeable check with that.

swiatekm commented 2 weeks ago

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.