From Fedora Project Wiki
(First version)
 
(→‎Release Notes: Deffering as of FESCo decision: https://pagure.io/fesco/issue/1710#comment-443651)
 
(11 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.<br/> '''Copy the source to a ''new page'' before making changes!  DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.'''}}
<!-- Self Contained or System Wide Change Proposal?
<!-- Self Contained or System Wide Change Proposal?
Use this guide to determine to which category your proposed change belongs to.
Use this guide to determine to which category your proposed change belongs to.
Line 37: Line 35:
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
* Email: <mail@kushaldas.in>
* Email: <mail@kushaldas.in>
* Name: [[User:Sayanchowdhury,| Sayan Chowdhury]]
* Name: [[User:Sayanchowdhury| Sayan Chowdhury]]
* Email: <sayan.chowdhury2012@gmail.com,>
* Email: <sayanchowdhury@fedoraproject.org>


* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
Line 60: Line 58:
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1416383 #1416383]


== Detailed Description ==
== Detailed Description ==
Line 66: Line 64:
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.
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 slip 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.
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 ==
== Benefit to Fedora ==


Fedora AMI images will get the same level of testing like rest of the Atomic/Cloud images. Currently, we have to manually test the images for everything. The automation will help us to be in the same level of the rest of the images.
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.
   
   
    
    
Line 76: Line 74:


== Scope ==
== Scope ==
* Proposal owners:
* 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?-->



Latest revision as of 07:37, 5 June 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

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