(ChangeReadyForWrangler) |
(→Release Notes: Deffering as of FESCo decision: https://pagure.io/fesco/issue/1710#comment-443651) |
||
| (7 intermediate revisions by 2 users not shown) | |||
| Line 35: | 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 | * Name: [[User:Sayanchowdhury| Sayan Chowdhury]] | ||
* Email: < | * 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 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 == | ||
| Line 74: | 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?--> | ||
| Line 150: | Line 150: | ||
--> | --> | ||
[[Category: | [[Category:ChangePageIncomplete]] | ||
<!-- When your change proposal page is completed and ready for review and announcement --> | <!-- When your change proposal page is completed and ready for review and announcement --> | ||
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | ||
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
- 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)