Goal:

As an administrator, I would like to deploy OpenShift 4 clusters to AWS C2S region

Problem:

Customers were able to deploy to AWS C2S region in OCP 3.11, but our global configuration in OCP 4.1 doesn't support this.
  

Why is this important:

• Many of our public sector customers would like to move off 3.11 and on to 4.1, but missing support for AWS C2S region will prevent them from being able to migrate their environments..

Lifecycle Information:

• Core

Previous Work:**

Here are the relevant PRs from OCP 3.11.  You can see that these endpoints are not part of the standard SDK (they use an entirely separate SDK).  To support these regions the endpoints had to be configured explicitly.

• Kube: https://github.com/kubernetes/kubernetes/pull/72245
• Autoscaler: https://github.com/kubernetes/autoscaler/pull/1717
• Installer: https://github.com/openshift/openshift-ansible/pull/11277/

Seth Jennings has put together a highly customized POC.

Dependencies:

• Custom API endpoint support w/ CA

• • Cloud / Machine API
  • Image Registry
  • Ingress
  • Kube Controller Manager
  • Cloud Credential Operator
  • others?
• Require access to local/private/hidden AWS environment

Prioritized epics + deliverables (in scope / not in scope):

• Allow AWS C2S region to be specified for OpenShift cluster deployment
• Enable customers to use their own managed internal/cluster DNS solutions due to provider and operational restrictions
• Document deploying OpenShift to AWS C2S region
• Enable CI for the AWS C2S region

Related : https://jira.coreos.com/browse/CORS-1271

Estimate (XS, S, M, L, XL, XXL): L

Customers: North America Public Sector and Government Agencies

Open Questions:

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

• https://github.com/openshift/cluster-samples-operator/pull/313

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.

• https://github.com/openshift/cluster-samples-operator/pull/321

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?

• https://github.com/openshift/image-registry/pull/255

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

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?

• https://github.com/openshift/oc/pull/617

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].

• https://github.com/openshift/origin/pull/25497

An the registry developer
I want e2e-upgrade jobs to monitor availability of the registry during upgrades
So that I can be sure that clients can use the registry without disruptions.

Acceptance Criteria

• A new test in openshift/origin repo.

Notes

https://github.com/openshift/origin/blob/e6b3d1ece61d7c3ab5a23151c9875e1f9ad36838/test/extended/util/disruption/controlplane/controlplane.go#L69

https://bugzilla.redhat.com/show_bug.cgi?id=1884380

• https://github.com/openshift/origin/pull/25679

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/image-registry/pull/258

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?

• https://github.com/openshift/image-registry/pull/252