m (Jkurik moved page Automated AMI test and release to Changes/Automated AMI test and release: Moving to the "Changes" section) |
|||
| Line 58: | 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: | * Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1416383 #1416383] | ||
== Detailed Description == | == Detailed Description == | ||
Revision as of 12:02, 25 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
- Name: Kushal Das
- Email: <mail@kushaldas.in>
- Name: Sayan Chowdhury
- Email: <sayanchowdhury@fedoraproject.org>
- 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)
- List of deliverables: 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)