You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a typical AM/SS installation (deb/rpm/ansible) the process seems to be done in the following way:
SS administrator deploys Storage Service code.
SS administrator runs manage.py migrate.
SS administrator starts Storage Service web worker(s).
SS administrator provides API key to Pipeline administrator.
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:
Create LOCAL_FILESYSTEM Space with path /.
Create default locations for this Space.
Persist the UUIDs of the new locations in the database (settings table)
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.
The text was updated successfully, but these errors were encountered:
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?).
In a typical AM/SS installation (deb/rpm/ansible) the process seems to be done in the following way:
manage.py migrate
.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:
/
.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.The text was updated successfully, but these errors were encountered: