Complete Epics
This section includes Jira cards that are linked to an Epic, but the Epic itself is not linked to any Feature. These epics were completed when this image was assembled
User Story
As an cluster administrator of a disconnected OCP cluster,
I want a list of possible sample images to mirror
So that I can configure my image mirror prior to installing OCP in a disconnected environment.
Acceptance Criteria
- Publish the list of the sample images to mirror as a ConfigMap in the samples operator namespace.
- Provide instructions on how to obtain the current image SHAs from the list above (via podman or skopeo).
- Reference the ConfigMap name in our "import failing" alert.
- [optional] Reference the ConfigMap name in our "Removed" condition message.
Notes
it is too onerous to find a connected cluster in order to obtain the list of possible samples images to mirror using the current documented procedures.
I need a list make available to me in my disconnected cluster that I can reference after initial install.
User Story
Sample operator use of the reason field in its config object to track imagestream import completion has resulted in that singleton being a bottleneck and source of update conflicts (we are talking 60 or 70 imagestreams potentially updating that once field concurrently).
Acceptance Criteria
- Reduction in reconciliation errors when imagestream imports complete (success or failure).
- ConfigMaps containing failing imagstream imports are added to must-gather
- After all imagestreams successfully import, there are no error-recording ConfigMaps in the samples-operator namespace.
Notes
See this hackday PR
for an alternative approach which uses a configmap per imagestream
Goal: Support OCI images.
Problem: Buildah and podman use OCI format by default and OpenShift Image Registry and ImageStream API doesn't understand it.
Why is this important: OCI images are supposed to replace Docker schema 2 images, OpenShift should be ready when OCI images become widely adopted.
Dependencies (internal and external):
Prioritized epics + deliverables (in scope / not in scope):
Estimate (XS, S, M, L, XL, XXL): XL
Previous Work:
Customers:
Open Questions:
User Story
As a user of OpenShift
I want to push OCI images to the registry
So that I can use buildah and podman with their defaults to push images
Acceptance Criteria
- An OCI image can be pushed to the registry by buildah or podman
- An imported OCI image can be pulled from the registry
- The registry should be able to pull-through OCI images from other registries
Launch Checklist
Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated
Notes
Add pertinent notes here:
- Enhancement proposal link
- Previous product docs
- Best practices
- Known issues
Guiding Questions
User Story
- Is this intended for an administrator, application developer, or other type of OpenShift user?
- What experience level is this intended for? New, experienced, etc.?
- Why is this story important? What problems does this solve? What benefit(s) will the customer experience?
- Is this part of a larger epic or initiative? If so, ensure that the story is linked to the appropriate epic and/or initiative.
Acceptance Criteria
- How should a customer use and/or configure the feature?
- Are there any prerequisites for using/enabling the feature?
Notes
- Is this a new feature, or an enhancement of an existing feature? If the latter, list the feature and docs reference.
- Are there any new terms, abbreviations, or commands introduced with this story? Ex: a new command line argument, a new custom resource.
- Are there any recommended best practices when using this feature?
- On feature completion, are there any known issues that customers should be aware of?
User Story
As a user of OpenShift
I want the image pruner to be aware of OCI images
So that it doesn't delete their layers/configs
Acceptance Criteria
-
- When
- an OCI image is pushed/mirrored to the registry
- an schema 2 image is pushes/mirrored to the registry and share its layers/config with the OCI image
- the schema 2 image is eligible to be pruned
- the shared layers/config are not shared with other images
- the pruner
- will delete the schema 2 image
- will NOT delete the OCI image and its layers/config
- When
Launch Checklist
Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated
Notes
Add pertinent notes here:
- Enhancement proposal link
- Previous product docs
- Best practices
- Known issues
Guiding Questions
User Story
- Is this intended for an administrator, application developer, or other type of OpenShift user?
- What experience level is this intended for? New, experienced, etc.?
- Why is this story important? What problems does this solve? What benefit(s) will the customer experience?
- Is this part of a larger epic or initiative? If so, ensure that the story is linked to the appropriate epic and/or initiative.
Acceptance Criteria
- How should a customer use and/or configure the feature?
- Are there any prerequisites for using/enabling the feature?
Notes
- Is this a new feature, or an enhancement of an existing feature? If the latter, list the feature and docs reference.
- Are there any new terms, abbreviations, or commands introduced with this story? Ex: a new command line argument, a new custom resource.
- Are there any recommended best practices when using this feature?
- On feature completion, are there any known issues that customers should be aware of?
Epic Goal
- Improve CI testing of the image registry components.
Why is this important?
- The image registry, image API and the image pruner had a lot of tests removed during transition 4.0. This may make the platform less stable and/or slow down the team.
Scenarios
- ...
Acceptance Criteria
- CI - tests should be more stable and have broader coverage
Dependencies (internal and external)
- ...
Previous Work (Optional):
- …
Open questions::
- …
Done Checklist
- CI - CI is running, tests are automated and merged.
The integration tests for the image registry expect that OpenShift and tests are run on the same machine (i.e. OpenShift can connect to sockets that the tests listen). This is not the case with e2e tests.
Acceptance Criteria
- every integration test is converted into an e2e test or a techdebt story
- image-registry tests are green
https://github.com/openshift/origin/pull/25475/files marked our tests for ISI as Disruptive.
Tests should wait until operators become stable, otherwise other tests will be run on an unstable cluster and it'll cause flakes.
Acceptance Criteria
- The tests wait until operators stable after image.config changes.
- The tests is no longer [Disruptive].
- If tests are slow (it depends on other operator, but MCO tends to be slow), they should be [Slow].
Goal: Rebase registry to Docker Distribution
Problem: The registry is currently based on an outdated version of the upstream docker/distribution project. The base does not even have a version associated with it - DevEx last rebased on an untagged commit.
Why is this important: Update the registry with improvements and bug fixes from the upstream community.
Dependencies (internal and external):
Prioritized epics + deliverables (in scope / not in scope):
DEVEXP-505Rebase on Docker Distribution v2.7.1
Estimate (XS, S, M, L, XL, XXL): M
Previous Work:
Customers:
Open questions:
User Story
As a user of OpenShift
I want the image registry to be rebased on the latest docker/distribution release (v2.7.1)
So that the image registry has the latest upstream bugfixes and enhancements
Acceptance Criteria
- Image registry is based on docker/distribution v2.7.1
Launch Checklist
Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated
Notes
Add pertinent notes here:
- Enhancement proposal link
- Previous product docs
- Best practices
- Known issues
Guiding Questions
User Story
- Is this intended for an administrator, application developer, or other type of OpenShift user?
- What experience level is this intended for? New, experienced, etc.?
- Why is this story important? What problems does this solve? What benefit(s) will the customer experience?
- Is this part of a larger epic or initiative? If so, ensure that the story is linked to the appropriate epic and/or initiative.
Acceptance Criteria
- How should a customer use and/or configure the feature?
- Are there any prerequisites for using/enabling the feature?
Notes
- Is this a new feature, or an enhancement of an existing feature? If the latter, list the feature and docs reference.
- Are there any new terms, abbreviations, or commands introduced with this story? Ex: a new command line argument, a new custom resource.
- Are there any recommended best practices when using this feature?
- On feature completion, are there any known issues that customers should be aware of?