Formalize expectations when elastic-agent is installed via package manager

[leehinman]

Describe the enhancement:

When elastic-agent is installed with a package manager (rpm or deb) the files are just copied to disk. Enrollment and starting elastic-agent are manual processes. This is a different experience than when installed via elastic-agent install. We should specify what is done by the package manager and what has to be done by the user manually. For example.

Should the package manager start elastic-agent

Having elastic-agent running is currently required for enrollment because of #4084. Also most other packages that install a server of some kind often start the server (eg. nginx). But always starting elastic-agent may interfere with the --delay-enroll option.

Should upgrades work via the package manager

Currently using the package manager to upgrade elastic-agent doesn't work (#3784). Should it? Also if we use elastic-agent upgrade to upgrade then what is stored in the package manager database is out of sync with what is on disk.

Describe a specific use case for the enhancement or feature:

install & upgrade of elastic-agent via rpm or deb package managers

What is the definition of done?

• List of expectations
• Issues to track implementing those expectations

[elasticmachine]

Pinging @elastic/elastic-agent (Team:Elastic-Agent)

[cmacknz]

One solution to the --delay-enroll issue would be to add an elastic-agent enroll --delay that is equivalent to elastic-agent install --delay-enroll.

[cmacknz]

So my initial answers to these questions are:

Should the package manager start elastic-agent

Yes, and we should implement elastic-agent enroll --delay to mirror what elastic-agent install --delay-enroll does. This follows the already established pattern of install mirror the arguments to enroll for a single command. This would make it so that the agent enrolls the next time it is restarted, regardless of if it is currently running.

Should upgrades work via the package manager

I think it should. We could go farther and have elastic-agent upgrade for these installations just download the new version and execute the upgrade via the package manager.

[pierrehilbert]

We should probably do it in a similar way to how PostgreSQL is working:

1. You install the new binary through the package manager
2. You run pg_upgrade command to upgrade your running PostgreSQL cluster to the new binary.