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

[Change Request] Deploy HaikuDepot version 1.0.169 #147

Open
andponlin opened this issue Jan 24, 2025 · 1 comment
Open

[Change Request] Deploy HaikuDepot version 1.0.169 #147

andponlin opened this issue Jan 24, 2025 · 1 comment
Labels
change-request Request a change on Haiku's infrastructure

Comments

@andponlin
Copy link
Contributor

Description

Update HaikuDepot to version 1.0.169

IMPORTANT; In this version, a new application server has been added into the repository called haikudepotserver-server-graphics. The build process has been substantially adjusted to accommodate the new build product. haikudepotserver-server-graphics will not need to be deployed yet, but is built + tested + pushed as part of the refactored GitHub Actions pipeline.

The reason for the new application server is that HDS will eventually offload it's graphics processing (scaling, optimization, HVIF processing) onto this secondary application server. At this stage, there is no need to deploy the haikudepotserver-server-graphics but it is being built + tested + pushed to ghcr.io/haiku/haikudepotserver-server-graphics.

This deployment request is only covering HDS and it will continue to proceed as normal. The new build of HDS contains preparatory changes to eventually support the new haikudepotserver-server-graphics as well as a minor bugfix and a version bump.

There are no database changes so a rollback will not require a database restore.

How has the change been tested

  • Dev-tested by the HaikuDepot dev.
  • Automated tests run by the Github action: here

Steps to implement the change

Note: Please mark changes from the default steps below in bold

  1. Verify that the image is available in the package registry.
  2. Scale down haikudepotserver and start a job to backup the database:
    $ kubectl scale deploy haikudepotserver --replicas=0
    $ kubectl create job --from=cronjob/haikudepotserver-pgbackup haikudepotserver-pgbackup-manual-(VERSION)
    
  3. Monitor the job to make sure it finishes correctly:
    $ kubectl logs -f jobs/haikudepotserver-pgbackup-manual-(VERSION)
    Backup haikudepotserver...
    gpg: directory '/root/.gnupg' created
    gpg: keybox '/root/.gnupg/pubring.kbx' created
    Added `s3remote` successfully.
    `/tmp/haikudepotserver_2023-08-06.sql.xz.gpg` -> `s3remote/haiku-backups/pg-haikudepotserver/haikudepotserver_2023-08-06.sql.xz.gpg`
    Total: 0 B, Transferred: 245.32 MiB, Speed: 86.05 MiB/s
    Snapshot of haikudepotserver completed successfully! (haiku-backups/pg-haikudepotserver/haikudepotserver_2023-08-06.sql.xz.gpg)
    
  4. Apply any pre-deployment configuration changes (see section Configuration Changes)
  5. Update the version in the infrastructure repository in deployments/haikudepotserver.yml.
  6. Apply the update to the server:
    $ kubectl apply -f deployments/haikudepotserver.yml
    
  7. Apply any post-deployment configuration changes (see section Configuration Changes)
  8. Post-deployment checks (is the web service responding, can you refresh the data using the HaikuDepot app)
  9. Commit and push the updated deployment configuration to GitHub.
  10. Announce the update on the haiku-sysadmin and haiku mailing list.

Configuration Changes

Please list any configuration changes, and note whether they need to be done pre-deploy or post-deploy

None

Rollback Plan

If the update is unsuccessful, the rollback can be executed as follows.

If there has been a (failed) database migration as part of the change, the backup created in step 2 must be restored. If the database has not been affected, then skip to the image rollback steps below.

  1. Stop all instances of haikudepotserver
    $ kubectl scale deploy haikudepotserver --replicas=0
    
  2. Prepare the restore job in deployments/other/restore-pg.yml by making sure the container args point to the haikudepotserver container
            args: ["restore", "haikudepotserver"]
    
  3. Restore the database by executing the following commands.
    $ kubectl exec -it deployment/postgres -- dropdb -U postgres haikudepotserver
    $ kubectl exec -it deployment/postgres -- createdb -U postgres -O haikudepotserver haikudepotserver
    $ kubectl apply -f deployments/other/restore-pg.yml
    # follow and validate the output of the following command. If the command completes, the restore is done.
    $ kubectl logs --follow jobs/restore
    # cleanup
    $ kubectl delete job/restore
    $ git checkout deployments/other/restore-pg.yml
    
  4. Roll back the image with the following commands:
    $ git restore deployments/haikudepotserver.yml
    $ kubectl apply -f deployments/haikudepotserver.yml
    
  5. Do sense checks in the logs and by some exploratory production testing to validate that the restore has been successful.
@andponlin andponlin added the change-request Request a change on Haiku's infrastructure label Jan 24, 2025
@andponlin
Copy link
Contributor Author

Hi there; would it be possible to progress this deployment for me?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
change-request Request a change on Haiku's infrastructure
Development

No branches or pull requests

1 participant