#240 Note about following Fedora branching after enabling chroot
Merged 6 years ago by frostyx. Opened 6 years ago by frostyx.
copr/ frostyx/copr doc-enable-chroot-r2r  into  master

@@ -39,8 +39,6 @@ 

  

  * :ref:`brainstorming`

  

- * :ref:`rawhide_to_release`

- 

  * :ref:`seeddb`

  

  SRPM URL/Upload build schema

file modified
+52 -15
@@ -3,49 +3,86 @@ 

  How to manage chroots

  ======================

  

- This article explains how to enable new chroots when a new Fedora is released and also how to disable them once the particular Fedora version is not supported.

+ This article explains how to enable new chroots when a new Fedora is released and also how to disable them once the

+ particular Fedora version is not supported anymore.

  

  

- Enable chroots

- --------------

+ Commands overview

+ -----------------

  

- Some requirements need to be met before you can add the chroot for new Fedora. Copr uses `Mock <https://github.com/rpm-software-management/mock>`_ for building packages, so before adding a new chroot, you need to `check if there is already available mock config <https://github.com/rpm-software-management/mock/tree/devel/mock-core-configs/etc/mock>`_ for it. In such case, you also need check in which version of the :code:`mock-core-configs` package it was added and be sure that the version is installed on builders.

- 

- Then you can easily add a new chroot by

+ Chroots can be easily managed with these few commands.

  

  ::

  

      copr-frontend create_chroot <name>

+     copr-frontend alter_chroot --action activate <name>

+     copr-frontend alter_chroot --action deactivate <name>

+     copr-frontend rawhide_to_release <rawhide-chroot> <newly-created-chroot>

+ 

+ However, `enablement process upon Fedora branching <#branching-process>`_ and also

+ `chroot deactivation when Fedora reaches it's EOL phase <#eol-deactivation-process>`_, are not that simple.

+ That's why the rest of this article explains the certain use-cases rather than atomic actions.

+ 

  

- After the Fedora release, you probably want to do something like this

+ Branching process

+ -----------------

+ 

+ Immediately after Fedora branching, you want to do something like this

  

  ::

  

      copr-frontend create_chroot fedora-27-x86_64 fedora-27-i386 fedora-27-ppc64le

  

  

- Disable chroots

- ---------------

+ Copr uses `Mock <https://github.com/rpm-software-management/mock>`_ for building packages, so you should check if

+ the mock configs

+ `are already available <https://github.com/rpm-software-management/mock/tree/devel/mock-core-configs/etc/mock>`_

+ and in which version of the :code:`mock-core-configs` package they were added. If that version is not installed

+ on builders, you should temporarily disable the chroots.

+ 

+ ::

+ 

+     copr-frontend alter_chroot --action deactivate fedora-27-x86_64 fedora-27-i386 fedora-27-ppc64le

+ 

+ 

+ Projects can be configured to follow Fedora branching. That means, that once a chroot for new Fedora release is

+ enabled, it should be automatically turned-on for such projects. Moreover, builds from Rawhide should be forked into

+ this new chroot. It can be done like this

+ 

+ ::

  

- When some Fedora version reaches the end of its release cycle and is marked as EOL, you can safely disable its chroots. Though we want to keep the chroots enabled for a short period of time (few weeks) even after EOL, so our users can comfortably deal with it.

+     copr-frontend rawhide_to_release fedora-rawhide-x86_64 fedora-27-x86_64

+     copr-frontend rawhide_to_release fedora-rawhide-i386 fedora-27-i386

+     copr-frontend rawhide_to_release fedora-rawhide-ppc64le fedora-27-ppc64le

  

- It can be done with

+ Once the mock configs are available on the builders, you can re-enable the chroots

  

  ::

  

-     copr-frontend alter_chroot --action deactivate <name>

+     copr-frontend alter_chroot --action activate fedora-27-x86_64 fedora-27-i386 fedora-27-ppc64le

+ 

+ When everything is done, `send an information email to a mailing list <#mailing-lists>`_.

  

- 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.

  

+ EOL deactivation process

+ ------------------------

  

- After a Fedora version is marked as EOL, you probably want to do something like this

+ When some Fedora version reaches the end of its release cycle and is marked as EOL, you can safely disable its chroots.

+ Though we want to keep the chroots enabled for a short period of time (few weeks) even after EOL, so our users can

+ 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

  

+ 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.

+ 

+ When it is done, `send an information email to a mailing list <#mailing-lists>`_.

+ 

  

  Mailing lists

  -------------

  

- After adding or disabling chroots on the production instance, an information email about the action should be sent to copr-devel@lists.fedorahosted.org .

+ After adding or disabling chroots on the production instance, an information email about the action should be sent to

+ copr-devel@lists.fedorahosted.org . When doing both actions at the same time, describing it in one email is sufficient.

@@ -1,17 +0,0 @@ 

- .. _rawhide_to_release:

- 

- Rawhide to release

- ==================

- 

- When new Fedora is released, we may want to add new chroot in Copr for it. This can be done running the following commands on copr-frontend machine::

- 

-     cd /usr/share/copr/coprs_frontend/

-     python manage.py create_chroot <name>

- 

- Such chroot is empty and does not contain any built packages. Therefore users of the new release will fail to install them. 

- 

- That is why we may want to copy the newest version of built packages from rawhide chroot to newly created chroot::

- 

-     python manage.py rawhide_to_release <rawhide-chroot> <newly-created-chroot>

- 

- This command will also check-on the <newly-created-chroot> in all Copr projects which builds for rawhide.

There is currently no note about executing copr-frontend rawhide_to_release ... after enabling a chroot. This PR adds it.

I've also renamed Rawhide to release article to a much more friendly Follow Fedora branching.

I would also recommend to split this into multiple lines next. I know it autowraps eventually but I think shorter lines are easier to edit (and also easier to review).

1 new commit added

  • [doc] wrap lines on 120 characters
6 years ago

I would also recommend to split this into multiple lines next. I know it autowraps eventually but I think shorter lines are easier to edit (and also easier to review).

Done, wrapped on 120 characters.

I wouldn't really say these are (hard) requirements. There is also an alternative of providing our own mock configs installed to builders from infra playbooks. And of course, we could just make it so that the build fails but with some friendly message in the copr-rpmbuild like "Mock config for fXX is not available." I think we should just do this operation at the day of branching or day after it. If there are mock configs already, then good. If not...well, it will take a bit of time until new builds are possible (and if that time should be long, we can provide the temporary configs).

I wouldn't really say these are (hard) requirements. There is also an alternative of providing our own mock configs installed to builders from infra playbooks.

Yep, but as you say, it is an alternative option. When you (I mean you personally) want to do it because you want to enable chroots before they are in Mock, you know how to do it. If someone else without such knowledge wants to enable chroots, he will probably do it standard way (i.e. wait until they are in Mock)

I think we should just do this operation at the day of branching or day after it. If there are mock configs already, then good.

You mean providing new configs for builders from somewhere else than mock-core-configs? We can. Just update the docs, we are all going to follow them when enabling chroots. Or submit an issue / explain me the new process and I will update them.

I basically wanted to say the following:

  • the rawhide_to_release script should be invoked ASAP after branching happens so that the builds are copied and are available to download&install in the new branched Fedora
  • the rawhide_to_release script needs the destination chroot to exist first in COPR DB so it can only be called after creation of it
  • That means we also need to create the destination chroot immediately after branching
  • if the new mock config is not available yet at this point, you can create the chroot but create it deactivated (not sure if we have an option for it)
  • That way the chroot won't be enabled for building (that would always fail until the new configs are available) but it will be possible to call the rawhide_to_release script, which should really be called asap after branching because it is related to "Follow Fedora branching" (so we should follow the branching as well as we can)
  • when the mock configs for the new chroots become available, the chroots should be activated with alter_chroot --action activate

So this is the procedure that we should follow when Fedora branching takes place. It's a bit complicated but there is no other way around it. Can you include it in the documentation or should I do it?

Okay, now I see it. I can update the docs :-)

when the mock configs for the new chroots become available, the chroots should be activated with alter_chroot --action activate

This means when mock-core-configs package with those configs is available or we should put .cfg files into backend/files/provision/files/mock/ ?

This means when mock-core-configs package with those configs is available or we should put .cfg files into backend/files/provision/files/mock/ ?

I would just suggest waiting until new configs are available in mock-core-configs.

(Note that there also needs to be a successful fXY compose. Right now, e.g. mock configs are available but building for f28 is not possible (at least not in ppc64le). But I would either omit that from docs or I would suggest to setup and enable the chroot at dev and then making sure the builds are succeeding for all available archs before the chroots are activated in production).

1 new commit added

  • [doc] add chroots even though mock configs are not available yet
6 years ago

I've updated the documentation accordingly to #comment-45849

This and the following text should be in a separate section called "Branching procedure".

This section should be called something like "Branching procedure". And the "Follow Fedora Branching" option should be explained as a part of it. Also the enabling chroot procedure should be here (with the --deactivate thing). You cannot really explain that procedure on two separate places (so that it can be easily understood) because it's just a single procedure and can only be properly understood as a single process.

So, the follow_fedora_branching.rst file should be renamed to branching_process.rstand the whole process, that I described in the last commit, should be moved there, or the file should be removed and rawhide_to_release description should be part of the how_to_manage_chroots.rst file?

how_to_manage_chroots.rst

should describe only most basic commands needed to create, activate, and deactivate chroots. There should be links to the "procedure files" (like branching_process, release EOL) where those commands are actively used to do a certain thing.

Then there should be:

branching_process.rst document that describes what should be done during branching (creating chroot, deactivating it, calling rawhide_to_release, activating the chroot when mock configs are available).

release_eol.rst should just say that when releases go EOL, we need to disable chroots for them.

If this is too complicated (it actually is quite complicated), you can also just keep one document how_to_manage_chroots.rst and make two subsections there: Branching, Release EOL. This seems to be a good option.

1 new commit added

  • [doc] describe processes rather than atomic chroot operations
6 years ago

Thanks for the opinion @clime. I had the same idea, but I wanted to know, what do you think.

I picked the second option for few reasons. The separation between three files would be nice if the processes were extremely complicated and if the atomic operations with chroots needed a long description. But it doesn't seem to be the case. how_to_manage_chroots.rst and release_eol.rst would be really short and the cross-referencing would be unnecessarily complicated.

Therefore I created a brief section showing the atomic chroot commands and then described the enablement and deactivation processes. And then also removed the current rawhide_to_release file as it is not needed anymore. I am quite satisfied with the current state of the article.

Thanks for the opinion @clime. I had the same idea, but I wanted to know, what do you think.
I picked the second option for few reasons. The separation between three files would be nice if the processes were extremely complicated and if the atomic operations with chroots needed a long description. But it doesn't seem to be the case. how_to_manage_chroots.rst and release_eol.rst would be really short and the cross-referencing would be unnecessarily complicated.
Therefore I created a brief section showing the atomic chroot commands and then described the enablement and deactivation processes. And then also removed the current rawhide_to_release file as it is not needed anymore. I am quite satisfied with the current state of the article.

Yes, agreed. Looks good to me too.

Thanks! I am going to merge it. We will see whether it is good once the F29 will be here :-)

rebased onto 8a6a650

6 years ago

Pull-Request has been merged by frostyx

6 years ago