Portal:Cloud VPS/Admin/Horizon
This page is currently a draft. More information and discussion about changes to this draft on the talk page. |
deploying updates to Horizon
Horizon is deployed in a docker container using branch that corresponds to OpenStack upstream release branches. Horizon is generally backwards-compatible with older OpenStack APIs, so its release cadence does not need to be perfectly in sync with the rest of Cloud-VPS; generally Horizon is several releases newer.
Currently (2023-09-07) the individual horizon components are hosted in gerrit and the top-level deployment repo on gitlab.
Refreshing upstream code base
Most repos are forks of upstream code. Repos starting with 'wmcs-' are in-house UIs which don't have upstreams to sync with.
Ideally each forked repo has a branch named after an upstream version (a release name like zed or antelope, or an LTS release like 2023.01); this branch should reflect the upstream branch of the same name with local wmf patches applied on top. Not all upstream projects branch with every version, so we aren't 100% consistent about this.
To update (using designate-dashboard as an example):
On your local development system clone the WMCS and upstream git repositories
$ git clone "ssh://<username>@gerrit.wikimedia.org:29418/openstack/horizon/designate-dashboard" && \
scp -p -P 29418 <username>@gerrit.wikimedia.org:hooks/commit-msg "designate-dashboard/.git/hooks/"
$ cd designate-dashboard
$ git remote add upstream https://opendev.org/openstack/designate-dashboard.git
$ git checkout -b train origin/train
$ git pull upstream stable/train --rebase --stat
If there are no conflicts you can rebase the upstream changes on top of any local customizations
$ git rebase origin/train
Requires the labs-striker group https://gerrit.wikimedia.org/r/admin/groups/3db64b50b88a848f800e95c946fab6a84b8fec2b
$ git push origin HEAD:refs/for/train%topic=upstream_refresh
Deploying
The docker image is built by gitlab whenever a new tag is pushed to the deploy repo.
To apply a specific patch:
- Apply patch to the master branch of <submodule>
- Cherry-pick that patch to <release branch> (e.g. 'train') of <submodule> and merge
- make a submodule update patch on <release branch> in the deploy repo and push
- tag the latest release, typically with a date stamp:
$ git tag 2023-09-06-225100
$ git push origin 2023-09-06-225100 # this starts an image build on gitlab
- Once gitlab completes the build (and, assuming the build succeeds) this new image can be deployed by updating hiera settings, like this example.