Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Fleet] Check for version conflict errors during package installation #84651

Closed
skh opened this issue Dec 1, 2020 · 6 comments
Closed

[Fleet] Check for version conflict errors during package installation #84651

skh opened this issue Dec 1, 2020 · 6 comments
Assignees
Labels
bug Fixes for quality problems that affect the customer experience Feature:EPM Fleet team's Elastic Package Manager (aka Integrations) project Team:Fleet Team label for Observability Data Collection Fleet team

Comments

@skh
Copy link
Contributor

skh commented Dec 1, 2020

At the start of a package installation, EPM checks if a saved object already exists for a package, and updates it immediately to indicate that an installation is in process. If two processes are trying to install or update a package, this may cause a race condition on the saved object, which results in a 409 error and a failure of the API call.

UPDATE: When the two installations are started within about 500ms from each other, the version conflict errors do not happen at the beginning of _installPackage(), but somewhere in the install*() functions that are called by _installPackage() to install the actual assets. This makes this a bit trickier to solve.

This task is to handle this situation more gracefully.

A possible approach could be to check for this specific error condition with SavedObjectsClient.errors.isConflictError() in _install_package() and react accordingly:

  • read the saved object again
  • check again for install_status and install_started_at
  • return early or continue installation accordingly

The description of #84190 and the script in https://gist.github.com/skh/cc695952031c9e349874b898c7066e42 may be good starting points for this work.

@skh skh added bug Fixes for quality problems that affect the customer experience Feature:EPM Fleet team's Elastic Package Manager (aka Integrations) project Team:Fleet Team label for Observability Data Collection Fleet team labels Dec 1, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/ingest-management (Team:Ingest Management)

@elasticmachine
Copy link
Contributor

Pinging @elastic/ingest-management (Feature:EPM)

@ph
Copy link
Contributor

ph commented Dec 1, 2020

@jfsiii and @neptunian would like your input for this issue? What is the current behavior?

@skh
Copy link
Contributor Author

skh commented Dec 1, 2020

@ph The current behavior is described in the issue description.

@skh skh self-assigned this Dec 2, 2020
@skh
Copy link
Contributor Author

skh commented Dec 2, 2020

I've looked into this a bit deeper, and it seems the version conflicts happen a bit later in the installation process. When starting the installations 500ms apart, I see them during installKibanaAssets() but I guess that is a bit random and depends on the system. I've updated the initial description.

@neptunian
Copy link
Contributor

neptunian commented Dec 2, 2020

Maybe we should ask the Kibana team if there is any experience in handling this scenario. Perhaps we can use a library like https://www.npmjs.com/package/async-lock to avoid more than one install at a time for a package key.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Fixes for quality problems that affect the customer experience Feature:EPM Fleet team's Elastic Package Manager (aka Integrations) project Team:Fleet Team label for Observability Data Collection Fleet team
Projects
None yet
Development

No branches or pull requests

4 participants