Epic Goal

• Many users end up with similar questions when we do office hours. Things like:

• • What's the difference between CRI-O and containerd?
  • What is the performance comparison between CRI-O and containerd?
  • Why should I use CRI-O?
• Many of these questions could be answered with some more investigation/more blogging. This epic encompasses that work.
• Ideally, this could be done before CRI-O graduates in the CNCF, so the CRI-O team has content to provide users when announcing the graduation.

Why is this important?

• Part of upstream legitimacy is related to the number of users that a project has, as well as the number of organizations that are developing that project. CRI-O is used by a handful of users, but doesn't have that many external contributors. Evangelizing CRI-O provides an avenue for advertising to new users/contributors why CRI-O is special and useful, potentially allowing it to gain more.

Scenarios

1. As an openshift user, I would like to know my CRI implementation is the best out there.
2. As a CRI-O developer, I would like a healthy upstream to help move features/fix bugs.

Acceptance Criteria

• This epic describes some soft goals, not necessarily related to CI or production readiness.
• Some acceptance could look like: a performance analysis, and some blogs written

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. …

Open questions::

1. …

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>