This process is untested by others, but works for me keeping devstack working with minimal waiting. If this is proven to be more globally useful, we can move it to devstack documentation. |
Only pull new docker images when all else fails or there is a known important update.
Pull new code from github as needed.
After pulling new code (especially if it has been a while), do the following:
Update requirements.
Note: I sometimes skip this if I guess that nothing changed that matters, and the I would run this if I hit a missing module error.
# from devstack directory make lms-shell # inside the LMS shell make requirements |
Update migrations.
Note: I usually skip this until I get a missing column or table error to save time.
make migrate |
Update assets.
Note: I always skip this unless my UI is totally messed up, because it is really slow.
paver update_assets |
You can find the commands to update requirements, migrations, and assets in the provisioning scripts.
For example, here is the LMS provisioning script with the paver commands.
Most other services use this IDA provisioning script with the following make commands instead of paver:
make requirements make migrate make static |
Note: As in the LMS example above, it is faster to only run the commands as you need them.
If you do need to provision, since it takes so long, the above commands can help you pick up from where you left off if it fails after a lot of work.
Run attach to see logs and restart a service as needed (or see if it auto-restarts).
# from devstack directory make lms-attach |
Use CTRL-C to restart the service.
Be patient. Using CTRL-C twice in a row will kill your container.
In the LMS shell, you can use TAB to autocomplete (you may need to hit TAB twice) for paver commands, if you can’t remember them.
Use make stop instead of make down when you shut down devstack, so you can keep recent bash history. Only use make down when you intentionally want to start over.