From Fedora Project Wiki
(Update the change to target F27, owned by me, and mark it as ready for a wrangler.)
 
(10 intermediate revisions by 2 users not shown)
Line 36: Line 36:
<!-- 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: bowlofeggs@fedoraproject.org
* Email: bowlofeggs@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> -->[mailto:sclark@fedoraproject.org Simon Clark] ([[User:sclark|sclark]])
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
Line 72: Line 72:
* Proposal owners:
* Proposal owners:
<!-- 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?-->
** Database model changes
** Document the existing REST API: https://github.com/fedora-infra/bodhi/issues/1323
** Masher modifications to the push process
** Requirements gathering
** Web UI changes
** Database model changes: https://github.com/fedora-infra/bodhi/issues/1324
** CLI modifications
** Modify the REST API so that the content type can be specified. It would be ideal to do this backwards-compatible if possible, but we can also release Bodhi 3.0.0 if we need to make an incompatible change: https://github.com/fedora-infra/bodhi/issues/1325
** Modify fedmsgs so they declare which content type is being references: https://github.com/fedora-infra/bodhi/issues/1326
** Python bindings modifications: https://github.com/fedora-infra/bodhi/issues/1327
** CLI modifications: https://github.com/fedora-infra/bodhi/issues/1328
** Documentation
** Web UI changes: https://github.com/fedora-infra/bodhi/issues/1329
** Masher modifications to the push process: https://github.com/fedora-infra/bodhi/issues/1330
** Unit tests
** Unit tests
** Documentation
** Upstream tracker issue: https://github.com/fedora-infra/bodhi/issues/653
** Upstream tracker issue: https://github.com/fedora-infra/bodhi/issues/653
** Upstream milestone for this effort: https://github.com/fedora-infra/bodhi/milestone/4


* Other developers: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Other developers:
<!-- What work do other developers 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 other developers 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?-->
** QA: Taskotron will need handle kicking off tests for non-RPM updates
** QA: Taskotron will need handle kicking off tests for non-RPM updates
Line 88: Line 94:
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuid required?  If a rel-eng ticket exists, add a link here.  
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuid required?  If a rel-eng ticket exists, add a link here.  
Please work with releng prior to feature submission, and ensure that someone is on board to do any process development work and testing; don't just assume that a bullet point in a change puts someone else on the hook.-->
Please work with releng prior to feature submission, and ensure that someone is on board to do any process development work and testing; don't just assume that a bullet point in a change puts someone else on the hook.-->
** We will need to ensure that the current signing process will work with non-RPM content
** We will need to ensure that the current signing process will work with non-RPM content
** Ensure that the new content has a proper home in the directory structure.
** Ensure that the new content has a proper home in the directory structure.
 
** [https://pagure.io/releng/issue/6660 Releng ticket: #6660]
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings -->
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings -->
Line 146: Line 151:
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
** We can simply switch back to the old compose processes for these components instead of using Bodhi.
** We can simply switch back to the old compose processes for these components instead of using Bodhi.
* Contingency deadline: F25 Beta  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency deadline: F26 Beta  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Line 164: Line 169:
-->
-->


[[Category:ChangeReadyForWrangler]]
[[Category:ChangeAcceptedF27]]
<!-- 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 16:20, 27 October 2017


Bodhi Non-RPM Artifacts

Summary

Bodhi, the Fedora Updates System, should be able to process more than just RPMs.

Owner

Current status

Detailed Description

As Fedora starts to deliver more than just RPMs and ISOs, we need a way to handle delivering updates to these artifacts. Bodhi currently handles this workflow for RPMs only, but we want to start using it for other content, such as Docker containers, Flatpak apps, OSTrees, etc. If it can be tagged in Koji, it should be accepted by Bodhi.

Benefit to Fedora

By using Bodhi for the updates process for all artifacts, we are able to better leverage community testers, enforce gating based on automated test results, handle bugzilla interactions, send email announcements, etc.

Scope

  • Other developers:
    • QA: Taskotron will need handle kicking off tests for non-RPM updates
    • QA: Client-side updates-testing tools like fedora-easy-karma could optionally be updated to detect these new artifacts
  • Release engineering:
    • We will need to ensure that the current signing process will work with non-RPM content
    • Ensure that the new content has a proper home in the directory structure.
    • Releng ticket: #6660
    • 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

  • Once a non-RPM artifact is built and tagged in Koji, the maintainer should be able to submit it to Bodhi.
  • The maintainer should be able to set the karma thresholds and require gating based on any Taskotron or Wiki-based test.
  • Testers should be able to submit feedback.
  • Release engineering should be able to "push" the content out in the standard updates process.

User Experience

  • Users of these various components will notice more frequent updates, ideally with more stability and less breakage.

Dependencies

  • This plan relies on these artifacts having tags in Koji.

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
    • We can simply switch back to the old compose processes for these components instead of using Bodhi.
  • Contingency deadline: F26 Beta
  • Blocks release? No
  • Blocks product? No

Documentation

N/A (not a System Wide Change)

Release Notes

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/BodhiNonRPMArtifacts&oldid=504232"