Skip to content

Deployment.md

Latest commit

 

History

History
76 lines (70 loc) · 5.21 KB

Deployment.md

File metadata and controls

76 lines (70 loc) · 5.21 KB
Raw

Deployment information for Babel, NodeNorm and NameRes

There are two main installations of NodeNorm that would be of interest to users who aren't system administrators for these tools:

Release process and checkpoints

  1. Create a new Babel release (see README.md for information) and add it to releases/releases.yaml, which records which NodeNorm and NameRes versions ship with which build. Every later step reads from that entry, and the next release uses it as its comparison baseline, so fill in the service versions as you deploy them below.

  2. Store the Babel outputs alongside other Babel releases on Hatteras.

  3. Deploy a new NodeNorm instance

    1. Split the Babel outputs into smaller files to improve load times and put them on a public web server. The split sizes and the reason for splitting are documented in NodeNorm's loader documentation.
    2. Update the Translator-devops repo with the URL to these Babel output files.
    3. Create a Redis R3 External instance to store identifiers.
    4. Run the NodeNorm loader to load the Babel outputs into a Redis instance.
    5. Create a NodeNorm web server to share the data in a Redis instance.

  4. Deploy a new NameRes instance (either locally or on Kubernetes)

    1. Create an empty Apache Solr instance.
    2. Load it with synonym information from Babel outputs.
    3. Write out a Solr backup and store it as a tarball.
    4. Copy the Solr backup to a publicly accessible URL.
    5. Update the Translator-devops repo with the new URL.
    6. Create a NameRes instance that will download the Solr backup and start the instance with it.

  5. Use the Babel Validator to test this release and check how it performs compared to the previous release.

  6. Write the release note. The build has already compared its own prefix counts against the previous release — babel_outputs/reports/tables/prefix_comparison.md and the two CSVs beside it, produced by src/reports/prefix_comparison.py against the baseline pinned in config.yaml. This replaces the external Babel Validator Prefix Comparator, which had to have both reports uploaded to it by hand.

    releases/scripts/draft_release_notes.py turns those reports, the three repositories' pull request lists, and the deployed services' /status endpoints into a draft note. Run it once the build is up on Exp (step 3/4), which is what the /status defaults point at — the note is written while the release is on Exp and before it is promoted to Dev, because Exp is publicly reachable, so the note is what tells people they can test against it. The script warns if a service is still answering from the previous Babel version, which is what pointing either URL at Dev too early looks like. The full process is in releases/README.md; archiving the prefix report and bumping the pins is in RunningBabel.md.

  7. Check with RENCI NodeNorm users before updating RENCI NodeNorm and NameRes instances

  8. Update RENCI NodeNorm and NameRes instances.

  9. Announce on Translator and RENCI channels and ask people to try it out.

  10. Deploy to ITRB

    1. Use the bastion servers to delete all data from the ITRB CI Redis R3 server.
    2. Update the Translator-Devops repo and create a PR for the develop branch. Once merged, the new Babel outputs should be loaded into the ITRB CI Redis R3 server.
    3. Use the bastion servers to delete all data from the ITRB Test Redis R3 server.
    4. Ask ITRB to run the NodeNorm loader to populate the ITRB Test Redis R3 server.
    5. Announce upcoming downtime to NodeNorm Prod.
    6. Ask ITRB to take down NodeNorm Prod.
    7. Use the bastion servers to delete all data from the ITRB Prod Redis R3 server.
    8. Ask ITRB to run the NodeNorm loader to populate the ITRB Prod Redis R3 server.
    9. Ask ITRB to start the NodeNorm Prod instance.

  11. Use the Babel Validator to test this release and check how it performs compared to the previous release. As a side-benefit, running these tests will warm up NameRes Solr's caches.