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

Problem: bootstrap process doesn't always work #303

Open
sevein opened this issue Jan 24, 2018 · 1 comment
Open

Problem: bootstrap process doesn't always work #303

sevein opened this issue Jan 24, 2018 · 1 comment

Comments

@sevein
Copy link
Member

sevein commented Jan 24, 2018

In a typical AM/SS installation (deb/rpm/ansible) the process seems to be done in the following way:

  1. SS administrator deploys Storage Service code.
  2. SS administrator runs manage.py migrate.
  3. SS administrator starts Storage Service web worker(s).
  4. SS administrator provides API key to Pipeline administrator.
  5. Pipeline is installed - pipeline self-registration process.

The order of the operations is important because when SS is executed for the first time (step 3), the startup() function makes some changes in the database that are needed for step 5 to succeed:

  1. Create LOCAL_FILESYSTEM Space with path /.
  2. Create default locations for this Space.
  3. Persist the UUIDs of the new locations in the database (settings table)

In step 5 the locations added in step 3 are associated with the new pipeline.

The problem I've found with the process described above is the following:

In a typical container-based deployment it's possible that the application was executed (step 3) before the database was populated (step 2) meaning that the startup() function is never executed. When the pipeline is registered (step 5) the process doesn't succeed - it does not fail but the locations are not created. The system ends up with a pipeline created but missing locations causing all sort of problems.

@sevein
Copy link
Member Author

sevein commented Jan 24, 2018

A potential solution is to implement the startup function as a management command that we ask the user to run after manage.py migrate is executed. Or perhaps Django emits some kind of signal that we can use to trigger startup() when the migration completes (django.db.models.signals.post_migrate?).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant