From Fedora Project Wiki
(ChangeReadyForWrangler)
Line 74: Line 74:


== Scope ==
== Scope ==
* Proposal owners: kushal, sayanchowdhury
* Proposal owners: to implement this Change
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->



Revision as of 13:42, 10 January 2017


Automated AMI test and release

Summary

We will test the AMI image we build on one single region using the same tests used in Vagrant/local Autocloud testing, and if the tests pass, then only the AMI will be uploaded to all the regions and released.

Owner

  • Release notes owner:

Current status

  • Targeted release: Fedora 26
  • Last updated: 2017-01-10
  • Tracker bug: <will be assigned by the Wrangler>

Detailed Description

Currenly fedming tool creates and uploads the AMI images to AWS, in all the regions. It only tests the output /usr/bin/true command to determine if an image is right or not.

The proposed change will split the process in the two parts. fedimg will first upload the image to only one region and emit a fedmsg message. Autocloud listening to these message will start testing the image using the same tests it uses for Vagrant/Atomic qcow2. Autocloud will upload the test details to ResultsDB. Fedimg will listen to ResultsDB fedmsg messages for the results of the test and if all the tests passes then then fedimg would copy the images to other regions as well.

Benefit to Fedora

Fedora AMI images will get the same level of testing like rest of the Atomic/Cloud images. Currently, qcow2 images for OpenStack are tested automatically, and while the same bits go to EC2, we have to validate the EC2 images manually (or trust that everything is close enough, which is not a good assumption). The automation will bring us to the same level of testing for AMIs as the rest of the images already get.


Scope

  • Proposal owners: to implement this Change
  • Other developers: N/A (not a System Wide Change)
  • Release engineering: N/A (not a System Wide Change)
  • Policies and guidelines: N/A (not a System Wide Change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

N/A (not a System Wide Change)

How To Test

N/A (not a System Wide Change)

User Experience

N/A (not a System Wide Change)

Dependencies

N/A (not a System Wide Change)

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No
  • Blocks product? product

Documentation

N/A (not a System Wide Change)

Release Notes