Historically, infrastructure maintenance has been on an as-needed “if it ain't broke, don't fix it” basis. Now that most Infrastructure services are highly available and the lab network/services/suite have stabilized, we're able to afford occasional downtime to perform system updates, hardware swaps, OS upgrades, etc.

This document (like all good documentation) will be ever-evolving.

The PnT Labs team has scheduled monthly maintenance on the second Friday of every month. Since this maintenance only has the potential to disrupt operations in the downstream/Octo lab, it could be a good candidate. Maintenance on Fridays allows for troubleshooting and rollbacks, if necessary, either late Friday evening or on Saturdays during a time when the lab is usually only running scheduled test suites.

Maintenance should not disrupt testing cycles when an upstream release is imminent.

Maintenance should be announced on the Status Portal and sepia-users mailing list at least a week prior and all stakeholders, yet TBD, should give a green light before proceeding.

Updating the dev chacra nodes ({1..5}.chacra.ceph.com) has little chance to affect upstream teuthology testing except while the chacra service is redeployed or a host is rebooted. Because of thise, it's relatively safe to perform CI maintenance separate from Sepia lab maintenance. To be extra safe, you could pause the Sepia queue and wait ~30min to make sure no package manager processes get run against a chacra node.

1. Log into each Jenkins instance, Manage Jenkins → Prepare for Shutdown
2. Again in Jenkins, go to Manage Jenkins → Manage Plugins
3. Select All at the bottom and click Download now and install after restart
4. Wait for all jobs to finish and make sure plugins are downloaded
5. Once all jobs are completed, ssh to each Jenkins instance
   1. Updating the jenkins package or rebooting will restart the service so:
   2. systemctl stop jenkins
   3. systemctl disable jenkins
   4. apt update
   5. apt install linux-image-generic (or equivalent to just update the kernel)
   6. Reboot the host so you're running the latest kernel
6. If no service redeploy is needed for chacra, shaman, or mita, just ssh to each of those hosts and apt update && apt upgrade && reboot
7. ssh to each static slave (smithi{119..128} and slave-{centos,ubuntu}-* as of this writing), update packages, and reboot
8. If a redeploy is needed, see each service's individual wiki page
   1. Once all the other CI hosts are up to date, update each Jenkins instance: apt upgrade
   2. This should restart Jenkins but if it doesn't, systemctl start jenkins
   3. systemctl enable jenkins
9. Spot check a few jobs to make sure all plugins are working properly
   1. You can check this by commenting jenkins test make check in a PR
   2. Make sure the Github hooks are working (Was a job triggered? When the job finishes, does it update the status in the PR?)
   3. Make sure postbuild scripts are running when they're supposed to (Is the FAILURE script running when the build PASSED? That's a problem)
10. Make sure all static slaves reconnect to Jenkins

For the most part, these hosts' packages can be updated and hosts rebooted whenever. If you're feeling friendly, you could send a heads up to ceph-devel and/or ceph-users.

• Log in to tracker.ceph.com and modify a bug
• Spot check a few pages on www.ceph.com
• Log in to www.ceph.com if you have a login to wordpress

As long as there isn't a job running, this host can be updated and rebooted whenever.

• Does http://docs.ceph.com load?
• Is the host reattached as a slave in Jenkins?

Rebooting this host is disruptive to upstream testing and should be part of a planned pre-announced outage to the ceph-users and ceph-devel mailing lists.

• Does https://download.ceph.com load?

1. Send a planned outage notice to sepia at lists dot ceph.com
2. Instruct teuthology workers to die
   1. Wait for there to be no jobs running. This can take up to 12 hours.
   2. If you don't want to wait:
      1. Ask Yuri if scheduled_teuthology runs can be killed
      2. Ask individual devs if their runs can be killed
3. Kill idle workers

   ssh teuthology.front.sepia.ceph.com
   sudo su - teuthworker
   bin/worker_kill_idle

4. Once there are no jobs running and no workers (teuthworker@teuthology:~$ bin/worker_count)
   1. Update packages on teuthology.front.sepia.ceph.com
   2. shutdown -r +5 "Rebooting during planned maintenance. SAVE YOUR WORK!"
   3. Update and reboot:
      1. labdashboard.front.sepia.ceph.com
      2. circle.front.sepia.ceph.com
      3. cobbler.front.sepia.ceph.com
      4. conserver.front.sepia.ceph.com
      5. drop.ceph.com
      6. git.ceph.com
      7. fog.front.sepia.ceph.com
      8. ns1.front.sepia.ceph.com
      9. ns2.front.sepia.ceph.com
      10. nsupdate.front.sepia.ceph.com
      11. vpn-pub.ovh.sepia.ceph.com
      12. satellite.front.sepia.ceph.com
      13. sentry.front.sepia.ceph.com
      14. pulpito.front.sepia.ceph.com
5. Finally, update and reboot gw.sepia.ceph.com ¹⁾

1. ssh $(whoami)@8.43.84.131 (circle.front/GFW proxy)
2. Log in to Cobbler
3. console smithi001.front.sepia.ceph.com (Do you get a SOL session?)
4. ssh drop.ceph.com
5. Does git.ceph.com load? Is it up to date?
6. Log in to FOG ²⁾
7. dig smithi001.front.sepia.ceph.com @vpn-pub.ovh.sepia.ceph.com
8. dig smithi001.front.sepia.ceph.com @ns1.front.sepia.ceph.com
9. dig smithi001.front.sepia.ceph.com @ns2.front.sepia.ceph.com
10. teuthology-lock --lock-many 1 -m ovh --os-type ubuntu --os-version 16.04 (Do you get a functioning OVH node? dig its hostname against vpn-pub and make sure nsupdate is working)
11. teuthology-lock --lock-many 1 -m smithi --os-type rhel
    1. Run ceph-cm-ansible against that host and verify it subscribes to Satellite and can yum update
12. Does http://sentry.ceph.com/sepia load?
13. Does http://pulpito.ceph.com load?

Finally, once all post-maintenance tasks are complete,

ssh teuthology.front.sepia.ceph.com
sudo su - teuthworker
bin/worker_start smithi 25
^D^D

Check how many running workers there should be in /home/teuthworker/bin/worker_start and start 1/4 of them at a time. If too many start at once, they can overwhelm the teuthology VM with ansible processes or overwhelm FOG with Deploy tasks.