########################
OpenAFS Partition Scheme
########################

Partitions Stored in Ceph
-------------------------

=========================== ============= ========= =====================
RBD NAME                    SERVER        PARTITION CONTENTS
=========================== ============= ========= =====================
rbdafs-home/home-1          afsfile       vicepu    user.* RW, mail.* RW
rbdafs-home/service-1       afsfile       vicepa    service.* RW
rbdafs-home/group-1         afsfile       vicepg    group.* RW

rbdafs-homescr/groupscr-0   afsscratch    vicepg    gscr.* RW
rbdafs-homescr/homescr-1    afsscratch    viceps    scr.* RW
rbdafs-homescr/genscratch-0 afsscratch    vicept    scratch RW

rbdafs-mirror/mirror-1      afsscratch    vicepm    mirror.* RW
=========================== ============= ========= =====================

Partitions on Chicago
---------------------

While, properly speaking, volumes are released and archived and volumes
live on partitions, we speak in this table of a partition's schedule as
the setup we have built treats all volumes on each of these partitions
uniformly.

+---------+------------------------+------------------+-----------------+------------------+
|PARTITION|CONTENTS                |RELEASE SCHEDULE  |ARCHIVE SCHEDULE |SEE               |
+=========+========================+==================+=================+==================+
|  vicepa | user,group,service RO; |nightly by chicago|weekly by chicago|[#afspart_vicepa]_|
|         | chicago specific RW    |                  | (RO only)       |                  |
+---------+------------------------+------------------+-----------------+------------------+
|  vicepb | various special cases  |nightly by chicago| manually / never|                  |
+---------+------------------------+------------------+-----------------+------------------+
|  vicepi |  mail RO volumes       |nightly by chicago|weekly by chicago|[#afspart_vicepi] |
|         |                        |                  | (RO only)       |                  |
+---------+------------------------+------------------+-----------------+------------------+
|  vicepm |       mirror.* RO      |mirrors automation| manually / never|                  |
+---------+------------------------+------------------+-----------------+------------------+
|  viceps |       gscr,scr RO      | manually / never | manually / never|                  |
+---------+------------------------+------------------+-----------------+------------------+
|  vicepz |        misc            | manually / never | manually / never|[#afspart_vicepz]_|
+---------+------------------------+------------------+-----------------+------------------+

.. [#afspart_vicepa]
   :doc:`bup` and various scripts in chicago's ~root/bin (backed up to
   file:///afs/acm.jhu.edu/group/admins.pub/scripts/chicago )

.. [#afspart_vicepi] See [#afspart_vicepa]_ for details of release and archive;
   mail.* volumes are hosted on Chicago, i.e. outside the cluster, so that our mail
   system can deliver even if the larger backing stores are offline, as there is
   typically some urgency associated with mail.

.. [#afspart_vicepz] Reserved for experiments

Worth noting, while here, is that ``/afs/acm.jhu.edu/readonly`` is
deliberately designed as a shadow copy of the cell, containing entirely RO
mounts.  Our various volume-creation scripts mount things over here too, and
if you're doing something fancy you might consider playing along.  This
helps to ensure that even in the event of a catastrophic failure of the
cluster and ACM services, data will remain online enough that someone can at
least copy it elsewhere, without admin intervention or having to replay from
backup media.

Release and Backup Schedules of Volumes
---------------------------------------

+------------+--------------------------------------------------------------+
| Volumes    |  Schedule                                                    |
+============+==============================================================+
| group.*,   | Expected to exist on Chicago /vicepa and will be picked      |
| service.*, | up by its weekly scan script.                                |
| user.*     |                                                              |
| root.*     | (But see below for special cases!)                           |
+------------+--------------------------------------------------------------+
| gscr.*     | ``vos backupsys`` on afsscratch as bos cronjob               |
| scr.*      |                                                              |
+------------+--------------------------------------------------------------+
| scratch    | ``vos backup`` on afsscratch as bos cronjob                  |
+------------+--------------------------------------------------------------+
| mirror.*   |  manages itself via mirrors automation (see below)           |
+------------+--------------------------------------------------------------+

Note that ``admins.pub`` is a special case; see :doc:`admins-pub`.

The Special Case of Mirrors and Other Unprivileged Release Operations
---------------------------------------------------------------------

Mirrors (``/vicepm`` wherever it may be found) are on their own release
schedule, as part of the mirrors update automation.  However, since release
is a privileged operation in AFS, we run remctld and afs-backend on one of
our AFS servers.  Users of this service are encouraged to use ``wrapsrv``
and the DNS SRV record(s) under the namespace ``_remctl.acm.jhu.edu``,
rather than pointing at a particular server.
  
afs-backend is configured to allow the
``host/mirrors-updater.vm.acm.jhu.edu`` (AKA ``rcmd.mirrors-upater``)
principal to release any volume whose name matches ``/^mirror\..*$/``.  For
details, see the configuration on ``afsptvl.vm`` and the scripts in
``service/mirrors`` .

Members of ``system:non-admin-hats`` are authorized to release any volume.
So if you're cruising along inside the cluster and want to release a volume
without your /admin hat on, run ::

  remctl afsptvl.trinidad.acm.jhu.edu afs-backend release $VOLUMENAME

Other Special Cases
-------------------

``user.fumbeya.hd`` is a special-purpose volume for some medical imaging data
that Fumbeya is hosting with us; it is located on a non-archival partition,
but is nonetheless replicated to Chicago.