From b8e1923dba1415c65ea6a4c9a29de8ec12166093 Mon Sep 17 00:00:00 2001 From: Jakub Kadlčík Date: Feb 05 2019 17:19:21 +0000 Subject: [doc] describe how to delete outdated chroots --- diff --git a/doc/how_to_delete_outdated_chroots.rst b/doc/how_to_delete_outdated_chroots.rst new file mode 100644 index 0000000..9c1fc9d --- /dev/null +++ b/doc/how_to_delete_outdated_chroots.rst @@ -0,0 +1,84 @@ +.. _how_to_delete_outdated_chroots: + +How to delete outdated chroots +============================== + +.. note:: All of these tasks are automatized for the main Copr instance in Fedora. + This page might be rather useful for maintainers of other instances or developers enhancing this feature. + +.. note:: Please read :ref:`copr_outdated_chroots_removal_policy` to see + how the deletion of outdated chroots work from the user perspective. + + +This article explains how to mark a chroot as outdated, how to notify project owners, that some of their chroots are +outdated and going to be deleted in the future, and lastly how to actually delete them. + + +Mark chroot as outdated +----------------------- + +This step is described as :ref:`eol_deactivation_process` in the :ref:`how_to_manage_chroots` document. +To briefly summarize it, first, it is required to mark a chroot as EOL (aka outdated). + +:: + + copr-frontend alter_chroot --action eol fedora-25-x86_64 + +It doesn't matter whether the chroot is currently activated or deactivated, using ``--action eol`` +always deactivates it. More importantly, for every related ``CoprChroot`` it generates a ``delete_after`` timestamp +saying when the copr chroot should be deleted. + + +Notify project admins +--------------------- + +Once the ``delete_after`` is set, the notification command starts to notice such copr chroot. The following command +prints to the stdout a list of people and about what they should be notified. Please be aware, that not only +project owners are going to be notified, but rather all project admins. + +:: + + copr-frontend notify_outdated_chroots --dry-run + +When working on a non-production instance and wanting to really send the emails, filter the recipients to just yourself +or team members. Any *real* users shouldn't be contacted from devel instances! + +:: + + copr-frontend notify_outdated_chroots --dry-run -e myself@redhat.com + +If this command prints that it would notify just the expected people (which were specified with the ``-e`` parameter), +then it is safe to run it without ``--dry-run`` parameter. + +:: + + copr-frontend notify_outdated_chroots -e myself@redhat.com + + +When the notification about a particular copr chroot is sent and then the ``notify_outdated_chroots`` command +is executed again, it will not send the notification for the second time. It is designed to be daily executed via Cron +and it needs to avoid spamming the people over and over again. Therefore when a notification is sent, a timestamp when +to send a next one is stored to the ``delete_notify`` column. In a case that this logic needs to be suppressed, +please use ``--all`` parameter. Then notifications are going to be sent regardless of the previous notification. + + +Delete the data +--------------- + +Once the ``delete_after`` timestamp is reached, the particular copr chroot should be deleted. To print +all the chroots for which this applies, use this command. + +:: + + copr-frontend delete_outdated_chroots --dry-run + +To really delete them (i.e. creating an action which will delete the chroot directory on the backend), +run the command without ``--dry-run`` parameter. + +:: + + copr-frontend delete_outdated_chroots + +When deleting the chroot (creating an action to delete the data on the backend), the ``delete_after`` +and ``delete_notify`` columns are set to NULL and therefore ``notify_outdated_chroots`` +and ``delete_outdated_chroots`` commands don't see the chroot anymore. diff --git a/doc/how_to_manage_chroots.rst b/doc/how_to_manage_chroots.rst index ccd84c2..6fa3e37 100644 --- a/doc/how_to_manage_chroots.rst +++ b/doc/how_to_manage_chroots.rst @@ -64,6 +64,8 @@ Once the mock configs are available on the builders, you can re-enable the chroo When everything is done, `send an information email to a mailing list <#mailing-lists>`_. +.. _eol_deactivation_process: + EOL deactivation process ------------------------ @@ -73,7 +75,7 @@ comfortably deal with it. It can be done like this :: - copr-frontend alter_chroot --action deactivate fedora-25-x86_64 fedora-25-i386 fedora-25-ppc64le + copr-frontend alter_chroot --action eol fedora-25-x86_64 fedora-25-i386 fedora-25-ppc64le After running such command, no data are going to be removed. All repositories for the chroot are preserved. It is just disabled and users can't build new packages in it anymore. diff --git a/doc/maintenance_documentation.rst b/doc/maintenance_documentation.rst index 254a8c3..4f34ac5 100644 --- a/doc/maintenance_documentation.rst +++ b/doc/maintenance_documentation.rst @@ -10,3 +10,5 @@ This section contains information about maintenance topics. You may also be inte * :ref:`how_to_upgrade_builders` -- how to upgrade openstack builders * :ref:`how_to_manage_chroots` -- how to manage active chroots + +* :ref:`how_to_delete_outdated_chroots` -- sending notifications and removing data from outdated chroots