Rename variables, constants and files from PAVICS to Birdhouse #428
Conversation
github-actions
bot
added
ci/deployment
There was a problem hiding this comment.
To be consistent with the organization name (https://github.com/bird-house), I think the comment/doc mentions should be formatted either as bird-house or Bird-House instead of Birdhouse.
In the PR description, the relative file link do not work.
CHANGES.md
Outdated
| - Update ``env.local`` file to replace all variables that contain ``PAVICS`` with ``BIRDHOUSE``. | ||
| * see [`env.local.example`](./birdhouse/env.local.example) to see new variable names | ||
| * see the ``BACKWARDS_COMPATIBLE_VARIABLES_PAVICS`` variable (defined in | ||
| [`default.env`](./birdhouse/default.env)) for a full list of changed environment variable names. | ||
| - Update any external scripts that access the old variable names directly to use the updated variable names. | ||
| - Update any external scripts that access any of the following files to use the new file name: |
There was a problem hiding this comment.
Are these mandatory changes or recommended ones provided the backwards compatible mode mentioned above?
There was a problem hiding this comment.
It's recommended. But since this is a migration guide, this is one of the steps to migrate properly. In the future, if we drop support for the old variable names we don't want people to lose out because they didn't migrate properly.
@mishaschwartz @fmigneault yes my bad, extremely sorry. I was too consumed lately on other issues on Ouranos side. If I can not get to this next week, I think you can merge and new findings from me will just be in a followup PR. |
|
Ok thanks for the follow up. I'll aim to merge this on Friday May 31st if you haven't had a chance to look at it before then. |
E2E Test ResultsDACCS-iac Pipeline ResultsBuild URL : http://daccs-jenkins.crim.ca:80/job/DACCS-iac-birdhouse/2666/Result ✅ SUCCESSBIRDHOUSE_DEPLOY_BRANCH : pavics-to-birdhouse DACCS_IAC_BRANCH : master DACCS_CONFIGS_BRANCH : master PAVICS_E2E_WORKFLOW_TESTS_BRANCH : master PAVICS_SDI_BRANCH : master DESTROY_INFRA_ON_EXIT : true PAVICS_HOST : https://host-140-118.rdext.crim.ca PAVICS-e2e-workflow-tests Pipeline ResultsTests URL : http://daccs-jenkins.crim.ca:80/job/PAVICS-e2e-workflow-tests/job/master/1614/NOTEBOOK TEST RESULTS |
E2E Test ResultsDACCS-iac Pipeline ResultsBuild URL : http://daccs-jenkins.crim.ca:80/job/DACCS-iac-birdhouse/2669/Result ✅ SUCCESSBIRDHOUSE_DEPLOY_BRANCH : pavics-to-birdhouse DACCS_IAC_BRANCH : master DACCS_CONFIGS_BRANCH : master PAVICS_E2E_WORKFLOW_TESTS_BRANCH : master PAVICS_SDI_BRANCH : master DESTROY_INFRA_ON_EXIT : true PAVICS_HOST : https://host-140-118.rdext.crim.ca PAVICS-e2e-workflow-tests Pipeline ResultsTests URL : http://daccs-jenkins.crim.ca:80/job/PAVICS-e2e-workflow-tests/job/master/1615/NOTEBOOK TEST RESULTS |
|
I'd appreciate your opinion: I'm tempted to bump this a major version since:
And the documentation has significantly changed even though the UI hasn't been changed at all. But that's not strictly necessary because everything should be fully backwards compatible. What do you think? |
I am doing code only quick review today, not enough time to perform a real deploy review. I'll let you know from a fresh eye perspective that not see how extensive this change is. |
There was a problem hiding this comment.
Quick read this PR, let me summarize what I understood, @mishaschwartz please correct me if I am wrong.
So all the old config vars name will still work if we have an an existing working env.local file, the back-compat mode is enabled by default.
If we have external script outside of this repo calling pavics-compose.sh and/or sourcing read-configs.include.sh they will still work transparently.
Very glad and very appreciate the effort put in to ensure this back-compat.
Now the breaking part: some old default values have changed. So even if the old config var name still work, their default value have changed.
So for vars that we never had to set in env.local because we were relying on the old default values, we now have to set them to get back the default values.
@fmigneault could I have the list of vars you had to set to keep the github pipeline and all your existing hosts running? I will use this as a starting point to adapt my env.local in advance so the day this PR goes live, my production host is already ready and the go-live can be automated and unattended. This list should be probably added to the migration doc (the changed log) to help other (ex: PCIC) prepare their env.local in advance.
I found a few items, nothing major.
And about the major version bump, I am not against, since some manual intervention is required but can be done in advanced so the go-live is still automated and unattended.
| ------ | ||
|
|
||
| Power Analytics and Visualization for Climate Science - Powered by Birdhouse and other ESGF software |
There was a problem hiding this comment.
Well the goal of the stack is still "Analytics and Visualization for Climate Science". Can we just keep that part of the string and only drop the rest?
| export THREDDS_SERVICE_DATA_LOCATION_NAME='Birdhouse' # this default is for backward compatibility | ||
| export THREDDS_DATASET_URL_PATH='datasets' # this default is for backward compatibility | ||
| export THREDDS_SERVICE_DATA_URL_PATH='birdhouse' # this default is for backward compatibility | ||
| export THREDDS_DATASET_LOCATION_ON_CONTAINER='/birdhouse-ncml' |
There was a problem hiding this comment.
Since we are already breaking back-compat, should we take the opportunity to fix the default value so they are less weird with respect to their variable name?
THREDDS_DATASET_LOCATION_ON_CONTAINER='/birdhouse-datasets'
THREDDS_SERVICE_DATA_LOCATION_ON_CONTAINER='/birdhouse-service-data'
THREDDS_DATASET_LOCATION_ON_HOST='${BIRDHOUSE_DATA_PERSIST_ROOT}/thredds-datasets'
THREDDS_SERVICE_DATA_LOCATION_ON_HOST='${BIRDHOUSE_DATA_PERSIST_ROOT}/thredds-service-data'
There was a problem hiding this comment.
I'm happy with that. Renaming the THREDDS_DATASET_LOCATION_ON_HOST and THREDDS_SERVICE_DATA_LOCATION_ON_HOST variables aren't really part of this PR since there's no "pavics" in the name but if we're renaming the other two we might as well do them all at once.
There was a problem hiding this comment.
Opps you are right, they do not contain "pavics"! Sorry, I accidentally added 2 more variable changes. I am okay if you decide to not change them.
I think the old default values are also repeated in env.local.example, if my memory is good and you decide to go with this. Do a search for the old default values just to be sure.
birdhouse/deployment/deploy.sh
Outdated
| if [ -d "${adir}" ]; then | ||
| cd "${adir}" || exit | ||
|
|
||
| # fail fast if unclean checkout | ||
| if [ ! -z "$(git status -u --porcelain)" ]; then | ||
| if [ ! -z "$(git status --untracked-files=no --porcelain)" ]; then |
There was a problem hiding this comment.
This should be --untracked-files=all because the default was all.
There was a problem hiding this comment.
Yes that is the old default. But why? I mean, does it break the update if there are untracked files?
There was a problem hiding this comment.
It's not that it would break the autodeploy, it's more about if the checkout is unclean, then someone is experimenting with the machine, let's not break his test environment.
In other works, autodeploy can also be enabled on dev/staging machine and it will automatically keep those machines up-to-date as long as the machine is not being actively used for development purposes. Very convenient when you have a fleet of test machines and you want them to be always up-to-date, ready to be used as test environment, and when they are in used, autodeploy won't touch them.
On a production machine, having untracked files means someone is testing directly in prod !!! It's probably for an emergency, again do not break that. And it gives a very simple and quick way to temporary disable autodeploy: just touch a new file like disable-autodeploy-because-of -XYZ-reason.txt.
There was a problem hiding this comment.
I'm going to revert this because making this change here was the wrong place to do it.
On a production machine, having untracked files means someone is testing directly in prod
There are many other reasons why you might have untracked files in prod:
- multiple env.local files
- custom components
- notes and readme files
By restricting what can go in this folder we limit lots of useful use cases. This is one of the reasons that I don't use the auto deploy components in production (the other being that I want to be able to understand updates before I deploy them in production).
There was a problem hiding this comment.
There are many other reasons why you might have untracked files in prod:
* multiple env.local files
We have this in our private repo.
* custom components
We have many external components in their own repo, most are private except this one https://github.com/bird-house/birdhouse-deploy-ouranos/
* notes and readme files
Don't have this one but I don't see why they can not be committed to one of the repos instead of being uncommitted and risking to lose it or unable to track their changes.
We can have meeting so I can show you our setup, with autodeploy on all our staging hosts as well.
| @@ -0,0 +1 @@ | |||
| CREATE DATABASE ${BIRDHOUSE_GENERIC_BIRD_POSTGRES_DB}; | |||
There was a problem hiding this comment.
missing .gitignore update matching the generated file of this new template file?
tests/test_read_configs_include.py
Outdated
|
|
||
| # Set backwards compatible allowed to False explicitly since the current default | ||
| # is True when not executing through the CLI. | ||
| # tmut may add a bunch of messages to stderr if this is not set. This may cause confusion when trying to debug a |
There was a problem hiding this comment.
do a search, I vaguely seen more tmut I think.
|
@tlvu export SERVER_NAME=CRIM-TEST-CI
export SERVER_INSTITUTION=CRIM
export SERVER_SUBJECT=Testing
export SERVER_TAGS=test,ci,validation,integration,end-2-end
export SERVER_DESCRIPTION="
Platform to test functionatities of birdhouse-deploy (https://github.com/bird-house/birdhouse-deploy)
employed by multiple institutions to provide the core configuration of components for PAVICS/DACCS/Marble nodes
(https://github.com/DACCS-Climate/Marble-node-registry).
"
export [email protected]
export EXTRA_CONF_DIRS="
./config/proxy
./config/magpie
./config/twitcher
./config/canarie-api
./config/geoserver
./config/finch
./config/raven
./config/hummingbird
./config/thredds
./config/portainer
./config/jupyterhub
./components/proxy
./components/magpie
./components/twitcher
./components/canarie-api
./components/geoserver
./components/finch
./components/raven
./components/hummingbird
./components/thredds
./components/portainer
./components/jupyterhub
./components/monitoring
./components/weaver
./components/cowbird
./components/stac
./optional-components/canarie-api-full-monitoring
./optional-components/all-public-access
./optional-components/testthredds
./optional-components/secure-thredds
./optional-components/secure-data-proxy
./optional-components/stac-data-proxy
./optional-components/stac-populator
./optional-components/wps-healthchecks
./optional-components/database-external-ports
./optional-components/test-weaver
./optional-components/test-cowbird-jupyter-access
./optional-components/test-geoserver-secured-access
./optional-components/x-robots-tag-header
"
# must toggle the option to have pavics-sdi optional weaver component tested:
# https://github.com/Ouranosinc/PAVICS-e2e-workflow-tests/blob/master/Jenkinsfile
export TEST_PAVICS_SDI_WEAVER=true
# in turn, the following variable must also be set to force to have pavics-sdi optional component notebook added:
# https://github.com/Ouranosinc/pavics-sdi/blob/master/docs/source/notebook-components/weaver_example.ipynb
# but since it is executed via 'PAVICS-e2e-workflow-tests', it must be passed indirectly with the extra variable
export EXTRA_TEST_ENV_VAR="${EXTRA_TEST_ENV_VAR} WEAVER_TEST_ENABLED=true"
# Docker images name to be used in the jupyterhub
# For PAVICS image, use default from birdhouse-deploy to obtain latest reference automatically.
DOCKER_NOTEBOOK_IMAGES_DEFAULT="${DOCKER_NOTEBOOK_IMAGES}"
if [ "$(echo "${DOCKER_NOTEBOOK_IMAGES}" | grep -c 'pavics/workflow-tests' || true)" -eq 0 ]; then
echo "WARNING: Fixing missing default 'DOCKER_NOTEBOOK_IMAGES'..."
# backward compat
COMPOSE_DIR="${COMPOSE_DIR:-$(dirname "$(realpath $0)")}"
# in case of execution by jenkins worker or ubuntu service, consider sourced/exec method can cause $0 to be the runner
# patch the path manually if invalid
if [ "$(basename "${COMPOSE_DIR}")" != "birdhouse" ]; then
echo "WARNING: Detected invalid 'COMPOSE_DIR=${COMPOSE_DIR}'. Overriding."
COMPOSE_DIR="/home/ubuntu/${GH_REPO:-birdhouse-deploy}/birdhouse"
fi
echo "WARNING: Resolved 'COMPOSE_DIR=${COMPOSE_DIR}'"
if [ -f "${COMPOSE_DIR}/config/jupyterhub/default.env" ]; then
DOCKER_NOTEBOOK_IMAGES_DEFAULT=$(cat "${COMPOSE_DIR}/config/jupyterhub/default.env" | grep 'DOCKER_NOTEBOOK_IMAGES=' | cut -d '=' -f 2)
elif [ -f "${COMPOSE_DIR}/components/jupyterhub/default.env" ]; then
DOCKER_NOTEBOOK_IMAGES_DEFAULT=$(cat "${COMPOSE_DIR}/components/jupyterhub/default.env" | grep 'DOCKER_NOTEBOOK_IMAGES=' | cut -d '=' -f 2)
fi
echo "WARNING: Resolved 'DOCKER_NOTEBOOK_IMAGES_DEFAULT=${DOCKER_NOTEBOOK_IMAGES_DEFAULT}'"
fi
export PAVICS_IMAGE="$(echo ${DOCKER_NOTEBOOK_IMAGES_DEFAULT} | grep pavics/workflow-tests | xargs)"
export PAVICS_VERSION="$(echo ${PAVICS_IMAGE} | cut -d ':' -f2)"
export PAVICS_NAME="$(echo ${PAVICS_IMAGE} | cut -d ':' -f1 | sed 's/[^[:alnum:]-]/-/g')"
# Jupyter single-user server images
export DOCKER_NOTEBOOK_IMAGES="${PAVICS_IMAGE}"
export JUPYTERHUB_IMAGE_SELECTION_NAMES="${PAVICS_NAME}${PAVICS_IMAGE:+:}${PAVICS_VERSION}"
echo "INFO: Resolved 'DOCKER_NOTEBOOK_IMAGES=${DOCKER_NOTEBOOK_IMAGES}'"
echo "INFO: Resolved 'JUPYTERHUB_IMAGE_SELECTION_NAMES=${JUPYTERHUB_IMAGE_SELECTION_NAMES}'"
# allow jupyterhub user selection of which notebook image to run
# see https://jupyter-docker-stacks.readthedocs.io/en/latest/using/selecting.html
export ENABLE_JUPYTERHUB_MULTI_NOTEBOOKS="
c.DockerSpawner.image_whitelist = {
**{
_name: _img for _name, _img in
zip(os.environ['JUPYTERHUB_IMAGE_SELECTION_NAMES'].split(), os.environ['DOCKER_NOTEBOOK_IMAGES'].split())
},
'jupyter/scipy-notebook': 'jupyter/scipy-notebook',
'jupyter/r-notebook': 'jupyter/r-notebook',
'jupyter/tensorflow-notebook': 'jupyter/tensorflow-notebook',
'jupyter/datascience-notebook': 'jupyter/datascience-notebook',
'jupyter/pyspark-notebook': 'jupyter/pyspark-notebook',
'jupyter/all-spark-notebook': 'jupyter/all-spark-notebook',
}
"
|
I think MINOR could be sufficient since it is possible (at least from the CI's perspective) to run the stack without any change and tests working end-to-end, but I'm not against MAJOR either if @tlvu thinks the defaults (which TBD?) cause sufficient changes on his end. I think the changes to the documentation adds a lot of precision and details, but they are not themselves introducing breaking changes. I don't think they reflect the semver mention "changes that requires significant documentation update" hinting that the documentation updates must be caused by/resulting from the stack changes initially. I would consider MAJOR necessary if the introduced Again, not a strong feeling about either MINOR or MAJOR for this case. Same result from my perspective.
Let me know which vars you refer to (is it only the |
In some cases the old default is preserved (see
Yes, in the migration guide we write: Lines 68 to 69 in 2c3140f
See the table in the migration guide for a list of variables that need to be changed to keep defaults backwards compatible: Lines 71 to 80 in 2c3140f If you want to update all variables so that you don't have to run in backwards compatible mode, check out the migration guide for details on what to change. |
|
I'm happy to go with a minor bump as well.
The goal of creating |
|
@tlvu @fmigneault given the slight changes I've made based on @tlvu's review I'll give this another 24 hours or so before I pull this in. |
Same here. I'll let @mishaschwartz decide on Minor or Major bump. On my side, I'll prepare my production
Oh that probably because the CI pipeline is only testing a fresh deployment case. For existing production deployments we won't be so lucky. I believe This is a reminder that the CI pipeline is not enough catch all errors in a PR because it does not test the upgrade scenario. Furthermore the upgrade scenario is actually the most critical path because all existing production deployments will take the upgrade scenario path and not the fresh deployment from scratch path. This is why we currently have the issue that Cowbird do not play nice with existing Magpie users because the upgrade path has never been considered during Cowbird development and testing. I think all the vars described here by @mishaschwartz will have to be set Lines 71 to 80 in 2c3140f |
E2E Test ResultsDACCS-iac Pipeline ResultsBuild URL : http://daccs-jenkins.crim.ca:80/job/DACCS-iac-birdhouse/2675/Result ❌ FAILUREBIRDHOUSE_DEPLOY_BRANCH : pavics-to-birdhouse DACCS_IAC_BRANCH : master DACCS_CONFIGS_BRANCH : master PAVICS_E2E_WORKFLOW_TESTS_BRANCH : master PAVICS_SDI_BRANCH : master DESTROY_INFRA_ON_EXIT : true PAVICS_HOST : https://host-140-118.rdext.crim.ca PAVICS-e2e-workflow-tests Pipeline ResultsTests URL : http://daccs-jenkins.crim.ca:80/job/PAVICS-e2e-workflow-tests/job/master/1619/NOTEBOOK TEST RESULTS |
variables This partially reverts commit 56d1a7c.
|
I'm reverting the changes to the thredds variables because they break the tests and I don't want to go through the effort of fixing the tests again. If we want to change these we can do it in a future update. |
E2E Test ResultsDACCS-iac Pipeline ResultsBuild URL : http://daccs-jenkins.crim.ca:80/job/DACCS-iac-birdhouse/2676/Result ❌ FAILUREBIRDHOUSE_DEPLOY_BRANCH : pavics-to-birdhouse DACCS_IAC_BRANCH : master DACCS_CONFIGS_BRANCH : master PAVICS_E2E_WORKFLOW_TESTS_BRANCH : master PAVICS_SDI_BRANCH : master DESTROY_INFRA_ON_EXIT : true PAVICS_HOST : https://host-140-118.rdext.crim.ca PAVICS-e2e-workflow-tests Pipeline ResultsTests URL : http://daccs-jenkins.crim.ca:80/job/PAVICS-e2e-workflow-tests/job/master/1620/NOTEBOOK TEST RESULTS |
E2E Test ResultsDACCS-iac Pipeline ResultsBuild URL : http://daccs-jenkins.crim.ca:80/job/DACCS-iac-birdhouse/2678/Result ❌ FAILUREBIRDHOUSE_DEPLOY_BRANCH : pavics-to-birdhouse DACCS_IAC_BRANCH : master DACCS_CONFIGS_BRANCH : master PAVICS_E2E_WORKFLOW_TESTS_BRANCH : master PAVICS_SDI_BRANCH : master DESTROY_INFRA_ON_EXIT : true PAVICS_HOST : https://host-140-118.rdext.crim.ca PAVICS-e2e-workflow-tests Pipeline ResultsTests URL : http://daccs-jenkins.crim.ca:80/job/PAVICS-e2e-workflow-tests/job/master/1622/NOTEBOOK TEST RESULTS |
|
aaand test are failing again. Nothing in the code has changed with this PR so I'm going to just assume that the flaky tests got more flaky and I'm going to pull this in. |
|
Before pulling this in, can you revert to the existing behavior of |
E2E Test ResultsDACCS-iac Pipeline ResultsBuild URL : http://daccs-jenkins.crim.ca:80/job/DACCS-iac-birdhouse/2680/Result ❌ FAILUREBIRDHOUSE_DEPLOY_BRANCH : pavics-to-birdhouse DACCS_IAC_BRANCH : master DACCS_CONFIGS_BRANCH : master PAVICS_E2E_WORKFLOW_TESTS_BRANCH : master PAVICS_SDI_BRANCH : master DESTROY_INFRA_ON_EXIT : true PAVICS_HOST : https://host-140-216.rdext.crim.ca PAVICS-e2e-workflow-tests Pipeline ResultsTests URL : http://daccs-jenkins.crim.ca:80/job/PAVICS-e2e-workflow-tests/job/master/1623/NOTEBOOK TEST RESULTS |
E2E Test ResultsDACCS-iac Pipeline ResultsBuild URL : http://daccs-jenkins.crim.ca:80/job/DACCS-iac-birdhouse/2679/Result ❌ FAILUREBIRDHOUSE_DEPLOY_BRANCH : pavics-to-birdhouse DACCS_IAC_BRANCH : master DACCS_CONFIGS_BRANCH : master PAVICS_E2E_WORKFLOW_TESTS_BRANCH : master PAVICS_SDI_BRANCH : master DESTROY_INFRA_ON_EXIT : true PAVICS_HOST : https://host-140-118.rdext.crim.ca PAVICS-e2e-workflow-tests Pipeline ResultsTests URL : http://daccs-jenkins.crim.ca:80/job/PAVICS-e2e-workflow-tests/job/master/1624/NOTEBOOK TEST RESULTS |
Overview
For historical reasons the name PAVICS was used in variable names, constants and filenames in this repo to refer
to the software stack in general. This was because, for a long time, the PAVICS deployment of this stack was the
only one that was being used in production. However, now that multiple deployments of this software exist in
production (that are not named PAVICS), we remove unnecessary references to PAVICS in order to reduce confusion
for maintainers and developers who may not be aware of the historical reasons for the PAVICS name.
This update makes the following changes:
PAVICSin environment variables, constant values, and file names have been changed toBIRDHOUSE(case has been preserved where possible).PAVICS_FQDN->BIRDHOUSE_FQDNpavics_compose.sh->birdhouse_compose.shTHREDDS_DATASET_LOCATION_ON_CONTAINER='/pavics-ncml'->THREDDS_DATASET_LOCATION_ON_CONTAINER='/birdhouse-ncml'PAVICShave been changed to useBirdhouse.pavics-compose.shscript that runsbirdhouse-compose.shin backwards compatible mode.env.localthat contain the stringPAVICSwill be usedto set the equivalent variable that contains
BIRDHOUSE. For example, thePAVICS_FQDNvariable set inthe
env.localfile will be used to set the value ofBIRDHOUSE_FQDN.bin/birdhousethat can be used to invokepavics-compose.shorbirdhouse-compose.shfrom one convenient location. This script also includes some useful options and providesa generic entrypoint to the stack that can be extended in the future.
CMIP5_THREDDS_ROOTMigration Guide
Update
env.localfile to replace all variables that containPAVICSwithBIRDHOUSE.Variable names have also been updated to ensure that they start with the prefix
BIRDHOUSE_.env.local.exampleto see new variable namesBACKWARDS_COMPATIBLE_VARIABLESvariable (defined indefault.env) for afull list of changed environment variable names.
Update any external scripts that access the old variable names directly to use the updated variable names.
Update any external scripts that access any of the following files to use the new file name:
The following default values have changed. If your deployment was using the old default value, update your
env.localfile to explicitly set the old default values.Update any jupyter notebooks that make use of the
PAVICS_HOST_URLenvironment variable to use the newBIRDHOUSE_HOST_URLinstead.Set the
BIRDHOUSE_POSTGRES_DBvariable topavicsin theenv.localfile. This value was previouslyhardcoded to the string
pavicsso to maintain backwards compatibility with any existing databases this should bekept the same. If you do want to update to the new database name, you will need to rename the existing database.
For example, the following will update the existing database named
pavicstobirdhouse(assuming the olddefault values for the postgres username):
You can then update the
env.localfile to the new variable name and restart the stackSet the
BIRDHOUSE_POSTGRES_USERvariable topostgres-pavicsin theenv.localfile if you would like topreserve the old default value. If you would like to change the value of
BIRDHOUSE_POSTGRES_USERthen alsoupdate the name for any running postgres instances. For example, the following will update the user named
postgres-pavicstopostgres-birdhouse:Note that the
postgres-qwertyvalue is meant just for illustration, you should replace this with the value ofthe
BIRDHOUSE_POSTGRES_PASSWORDvariable.Note that you'll need to do the same for the
stac-dbservice as well (assuming that you weren't previouslyoverriding the
STAC_POSTGRES_USERwith a custom value).Changes
Non-breaking changes
Breaking changes
Related Issue / Discussion
Additional Information
Links to other issues or sources.
birdhouse_daccs_configs_branch: master
birdhouse_skip_ci: false