From 5cf97ddaf3cf8d56603bf230732deabefaf65f11 Mon Sep 17 00:00:00 2001 From: Sinny Kumari Date: Nov 19 2018 08:28:03 +0000 Subject: Update Two Week release steps with latest information Signed-off-by: Sinny Kumari --- diff --git a/docs/two-week-release-steps.md b/docs/two-week-release-steps.md index 97ab289..d4b4822 100644 --- a/docs/two-week-release-steps.md +++ b/docs/two-week-release-steps.md @@ -2,71 +2,78 @@ Find ostree version and pungi compose ID for the media we want to release. -Look under https://kojipkgs.fedoraproject.org/compose/twoweek/ +- Now a days, we mostly perform Atomic Two Week release from updates compose + available at https://kojipkgs.fedoraproject.org/compose/updates/ +- Now, we generate ostree and corresponding Atomic Host artifcats in same + compose. +- For example: Atomic Host compose based on Fedora 29 from date 20181119 can be + https://kojipkgs.fedoraproject.org/compose/updates/Fedora-29-updates-20181119.0/ + Right now there are a few different ways to figure out what the ostree version is/should be: - boot media from a compose and run rpm-ostree status -- look at autocloud raw results (the commit/version is in there) -- look at http://ostree-signed-commit-checker-ostree-commit-checker.origin.dustymabe.com/ - to see what the latest version is in the repos and assume that version is what is in - the media +- look at [autocloud](https://apps.fedoraproject.org/autocloud/compose) raw results + of our target compose(the commit/version is in there) -Example ostree version: 27.25 -Example pungi compose ID: Fedora-Atomic-27-20171211.0 +Example ostree version: 29.20181119.0 +Example pungi compose ID: Fedora-29-updates-20181119.0 +Example ostree compose ID: Fedora-29-updates-20181119.0 Before sending out candidate email: - Check to make sure the compose state is FINISHED and not FINISHED_INCOMPLETE or any other state - - ex: https://kojipkgs.fedoraproject.org/compose/twoweek/Fedora-Atomic-27-20171211.0/STATUS -- Check to make sure media from all architectures have the same ostree version - - Can do this by booting the media (or ask ksinny) + - ex: https://kojipkgs.fedoraproject.org/compose/updates/Fedora-29-updates-20181119.0/STATUS +- Check to make sure media from all architectures(aarch64, ppc64le and x86_64) have the same ostree version + - Can ask ksinny if you need access to aarch64 or ppc64le machine - Check to see if latest ostree pass a-h-t via the README.md in repo - https://github.com/projectatomic/atomic-host-tests -- Check to see if latest cloud images pass autocloud +- Check to see corresponding cloud images pass autocloud - https://apps.fedoraproject.org/autocloud/compose + - ex: https://apps.fedoraproject.org/autocloud/jobs/5812 - Check to see if ISO image tests passed in OpenQA - http://openqa.fedoraproject.org/ + - ex: https://openqa.fedoraproject.org/tests/overview?distri=fedora&version=29&build=Fedora-29-updates-20181119.0&groupid=1 - Check to make sure AMIs were published for every region for that compose - - use: https://pagure.io/fedora-websites/blob/master/f/tools/get_ami.py (EX: python get_ami.py | grep Fedora-Atomic-$VERSION-$RELEASE) + - use: https://pagure.io/fedora-websites/blob/master/f/tools/get_ami.py (EX: python get_ami.py | grep Fedora-AtomicHost-$VERSION-$RELEASE) - There should be a standard and gp2 for each of the following: - ap-northeast-1 + - ap-northeast-2 + - ap-south-1 - ap-southeast-1 - ap-southeast-2 + - ca-central-1 - eu-central-1 - eu-west-1 + - eu-west-2 - sa-east-1 - us-east-1 - - us-west - us-west-1 - us-west-2 - - NOTE: Check for possible additions -- Run an openshift test againt the latest AMI - - Use the latest release of openshift-ansible - - If anything breaks, open up bug(s)/issue(s) in proper locations for whatever component is causing problems +- Run an openshift test against the latest AMI + - Use the latest release of openshift-ansible (currently, 3.11 is the latest) - something like: http://www.projectatomic.io/blog/2016/12/part1-install-origin-on-f25-atomic-host/ + - Check https://sinnykumari.fedorapeople.org/openshift/readme for latest updates required to perform + successful openshift cluster install + - If anything breaks, open up bug(s)/issue(s) in proper locations for whatever component is causing problems - If possible, check with jbrooks to see if kube works - talk with jbrooks - or, make sure kubeadm test from wiki https://fedoraproject.org/wiki/User:Jasonbrooks/QA/AtomicTests/Install_Kubeadm works +- Nice to have: We don't have automated tests running for ppc64le and aarch64 architectures. + if time permits, make sure that Basic tests and Atomic tests as mentioned in http://testdays.fedorainfracloud.org/events/49 are running fine -If all of those tests pass then: - -- Send out candidate email. Example: - - example: https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-November/msg00087.html - -Request Release: +If all of those tests pass then, request release: - make request to releng to do the release: - - example: https://pagure.io/releng/issue/7189 + - example: https://pagure.io/releng/issue/7916 - talk with mohan in #fedora-releng irc channel to sync up - - mostly, "hey I created this ticket, can we make sure we run the release - before we start bodhi pushes for the day". + - mostly, "Hey! I created this ticket for Atomic Two Week release, can we perform the release?". After release: -- Update Vagrant Boxes in Vagrant Cloud (only Dusty has credentials for now) +- Update Vagrant Boxes in Vagrant Cloud ( Dusty can provide access) - issue for having us automate this via API calls: https://pagure.io/atomic-wg/issue/393 - Send out "follow up" email: - - example: https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-November/msg00092.html + - example: https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2018-November/msg00001.html - Verify static delta works for upgrade from previous release