Procedures¶
Intended audience: Anyone who is administering Embargo Transfer.
Deployment¶
Standard Kubernetes tools like k9s can be used to dynamically update the deployment including increasing/decreasing replicas, but changes should be committed back to GitHub.
Maintenance¶
After creating a pull request or merging to the main branch in lsst-dm/embargo-butler, a GitHub Action will automatically build a new version of the containers, which can be deployed for testing.
For production, an annotated tag with version “vN.N.N” should always be placed on the main branch, which will cause a versioned container to be created.
That version can then be deployed by selecting it in the kustomization.yaml file for the appropriate environment(s).
Backup¶
N/A.
Cold Startup¶
If necessary, recreate the notification topic and bucket notification configuration in S3 using the configurations and scripts in GitHub. Reapply the application manifests from GitHub.
Cold Shutdown¶
No special tasks.
Reproduce Service¶
Testing should be done in the usdf-embargo-dmz-dev vcluster.
IP addresses will need to be changed, and appropriate notification configurations for test buckets will need to be applied.