#5636: Use a staging area for test composes and safe practices when naming them

Fedora Release Engineering rel-eng at fedoraproject.org
Fri Jun 14 09:26:55 UTC 2013


#5636: Use a staging area for test composes and safe practices when naming them
-----------------------------+------------------------
 Reporter:  kparal           |       Owner:  rel-eng@…
     Type:  task             |      Status:  new
Milestone:  Fedora 19 Final  |   Component:  other
 Keywords:                   |  Blocked By:
 Blocking:                   |
-----------------------------+------------------------
 Summary: There was a hiccup for F19 TC3 compose. First it was created with
 an old anaconda, then it was deleted and created with a new anaconda. The
 announcement was sent only afterwards. Unfortunately the mirrors do not
 heed announcements, they periodically sync everything. For Brno office our
 mirror synced the old TC3 -> we came to work -> saw TC3 announcement ->
 saw TC3 on our local mirror -> tested the (outdated) TC3 version for the
 whole day -> and *by pure chance* learned that we have been using an
 outdated compose (and wasted a day's work) at the end of the day.

 I don't mean to blame anyone. It was unfortunate, and I'd like to improve
 our workflow to minimize a chance of that happening again.

 I have heard a solution "If you download images before announcement, make
 sure they match the upstream checksums after the announcement is out".
 First, a lot of people (e.g. us) don't download images manually, our
 mirror does. So this essentially means checking timestamps or checksums
 for every compose that we sync. That 1) requires some time spent for
 dozens of individuals 2) is error-prone, because *nobody* will do that
 every time, like a machine. Can we do better?

 I see two very simple solutions and they can be combined:
 1. Use a "staging area" for new composes. It's really simple - create a
 directory that is not world-readable (thus not mirrored) and create the
 compose there. Once you are sure everything looks OK, move the compose to
 the correct directory. The other benefit is that this is nearly atomic,
 thus making sure we don't have half-synced mirrors.
 2. Once something is public, don't change contents. It might happen that
 we publish something in error. But this is the same situation as in source
 tarballs for software projects. You can never change it, because you never
 know if somebody hasn't downloaded it in the (albeit short) meantime. You
 can delete, sure, but the fixed file/tarball/compose should always have a
 bumped version. There's no problem in that, really. If TC3 is published in
 error, delete it if you want, and create TC3.1 or TC4. It's just a safety
 practice and we don't mind, really, quite the opposite. This is a risk-
 prevention.

 If we combine these approaches, I believe there is no actual increase in
 your workload (these are just work approaches, but no extra load) and we
 increase the reliability of our tools and processes.

 Thanks.

-- 
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5636>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project


More information about the rel-eng mailing list