Back to index

4.4.21

Jump to: Incomplete Features |

Changes from 4.3.40

Note: this page shows the Feature-Based Change Log for a release

Incomplete Features

When this image was assembled, these features were not yet completed. Therefore, only the Jira Cards included here are part of this release

Feature OCPPLAN-2388: The details of this Jira Card are restricted (Only Red Hat employees and contractors)
The details of this Jira Card are restricted (Only Red Hat employees and contractors)
Epic OSASINFRA-1112: The details of this Jira Card are restricted (Red Hat Employee and Contractors only)
The details of this Jira Card are restricted (Red Hat Employee and Contractors only)
Story DEVEXP-523: Allow Recreate Rollouts for Image Registry

User Story

As an OpenShift cluster admin
I want to be able to use the Recreate rollout strategy for the image registry's deployment
So that I can use ReadWriteOnce PVs and successfully upgrade an OpenShift cluster.

Acceptance Criteria

  • Image registry's deployment defaults to the RollingUpdate strategy (current default behavior)
  • Cluster admins can use the image registry operator config to change the rollout strategy to Recreate.
  • Cluster upgrades succeed under the following scenario:
    • Image registry is provisioned with an RWO persistent volume
    • Image registry is configured to have one (and only one) replica

Launch Checklist

Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated

Notes

  • We do not need to check the number of replicas specified if the admin provisions RWO storage. If more than 1 is set in this circumstance, it is perfectly valid for the registry to report itself Degraded or Progressing (deployment will fail to scale up).
  • During upgrade the image registry operator may temporarily report itself Degraded (no replicas).

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 DEVEXP-475: 4.4 DevExp k8s Rebase

Goal: rebase to Kubernetes 1.17

Problem: 

Why is this important: 

Dependencies (internal and external):

  • Apiserver - kubernetes 1.17 rebase

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

  • DEVEXP-460 [1.16] Rebase openshift-controller-manager
  • Rebase openshift-controller-manager on k8s 1.17 DEVEXP-489
  • Rebase image registry operator on Kubernetes 1.17 DEVEXP-492
  • Rebase image registry on Kubernetes 1.17 DEVEXP-491
  • Rebase samples operator on k8s 1.17 DEVEXP-493
  • Rebase openshift-controller-manager-operator on k8s 1.17
  • Rebase openshift/builder on k8s 1.17 DEVEXP-488

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

Previous Work:

Customers:

Open questions:

  • Does the k8s rebase for the registry affected by the planned rebase of docker/distribution? No.
Story DEVEXP-489: [1.17] Rebase openshift-controller-manager

User Story

As a developer using OpenShift
I want the openshift controller manager to use k8s 1.17 libraries
So that builds, image triggers, and templates can take advantage of the latest Kubernetes features.

Acceptance Criteria

  • Builds can work with k8s 1.17 libraries
  • Build and image change triggers work with k8s 1.17 libraries
  • Templates work with k8s 1.17 libraries

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:

  • No documentation required
  • QE - no new features will be added with this story. Only regression testing is required.

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?
Story DEVEXP-490: [1.17] Rebase openshift controller manager operator

User Story

As a cluster administrator
I want the openshift controller manager to use k8s 1.17 libraries
So that the operator works in Kubernetes 1.17 clusters

Acceptance Criteria

  • The openshift-controller-manager-operator works in k8s 1.17 clusters

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:

  • No docs required
  • QE note - only regression testing is required. No new features will be added with this story.

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?
Story DEVEXP-493: [1.17] Rebase samples operator

User Story

As a cluster admin
I want the samples operator to use k8s 1.17 libraries
So that samples can be deployed on Kubernetes 1.17 clusters

Acceptance Criteria

  • Samples operator installs imagstreams and templates on Kubernetes 1.17 clusters

Launch Checklist

Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated

Notes

  • No docs required
  • QE note - only regression testing required. No new features will be added.

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?
Story DEVEXP-488: [1.17] Rebase openshift/builder

User Story

As a developer using OpenShift
I want builds to use k8s 1.17 libraries
So that builds can take advantage of the latest Kubernetes features

Acceptance Criteria

  • Builds are able to run on OpenShift using k8s 1.17 libraries.

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:

  • No docs required for this story
  • QE note - this story only requires regression testing. No new user-facing features will be added.

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?
Feature OCPPLAN-2389: The details of this Jira Card are restricted (Only Red Hat employees and contractors)
The details of this Jira Card are restricted (Only Red Hat employees and contractors)
Epic DEVEXP-472: Automated image pruning

Goal: Automate the image pruning process

Problem:

  • Registry image pruning is a manual process that adds toil to cluster admins
  • Scheduled pruning is an often-ignored day 2 task

Why is this important: 

  • Pruning works best when done regularly
  • Operators let us provide this capability by default

Dependencies (internal and external):

  • API support for current registry and quay
  • Direction of quay integration with OpenShift

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

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

Previous Work: 

Customers:

  • AXA Technology Services SAS (case 01685658)
  • Telecom Italia (case 02266154)
  • Inditex (Quay customer in the meantime)

Open questions:

  • Long-term support for current registry given Quay direction - we are keeping the internal registry as is through FY2020.
  • How can we handle downgrades when the upgrade adds a new component? On downgrade we may orphan a CronJob - for a short period of time this is acceptable, and we anticipate any downgrade is temporary in nature. The “fixed” upgrade must be able to create or update the pruning CronJob
Story DEVEXP-191: Add CronJob to automate image pruning

User Story

As an OpenShift cluster admin
I want the registry operator to create a CronJob to run regular image pruning
So that I don't have to manually configure pruning
And that my cluster remains healthy

Acceptance Criteria

The registry operator should create a CronJob to run pruning at a regular interval

  1. This should be configurable through a separate custom resource:
    1. Ability to enable or disable, set schedule
    2. Configure/tune parameters as described in the enhancement proposal
  2. All necessary RBAC/service accounts should be created by the operator if custom resource instance is created
  3. If pruning custom resource instance is deleted, all components related to the pruning should also be deleted
  4. The custom resource definition for the pruner should be installed via the CVO.
  5. The schema for the pruner CRD must be readable via oc explain

Launch Checklist

Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated

Notes

Dependencies

  • None

Design

Enhancement Proposal

Story DEVEXP-433: Report that Auto Pruning has been enabled

User Story

As an OpenShift cluster admin
I want the registry operator to create a CronJob to run regular image pruning
So that I don't have to manually configure pruning
And that my cluster remains healthy

Acceptance Criteria

  1. The registry operator should publish metrics reporting if the CronJob has been installed, and if so report if it is active or suspended, number of successful jobs, and the number of failed jobs. https://docs.google.com/document/d/1rCKAYTrYMESjJDyJ0KvNap05NNukmNXVVi6MShISnOw/edit?usp=sharing
  2. An alert is fired if the most recent pruning job failed - this is provided by kube-state-metrics
  3. Registry operator should alert if pruning is suspended or not installed.

Launch Checklist

Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated

Notes

Kube-state-metrics provides generic metrics around jobs and CronJob - as such new metrics would duplicate these values and should not added.

Enhancement proposal: https://github.com/openshift/enhancements/blob/master/enhancements/image-registry/automate-pruning.md

Stretch goals not completed:

  1. Nice to have metric - report duration of the most recent pruning job (potentially split by success/failure).
  2. Nice to have metric - number of images (may already exist via etcd or openshift-state-metrics). If exists propose adding to Telemeter's whitelist (ideally no more than 100 possible label value combinations).
Feature OCPPLAN-3288: The details of this Jira Card are restricted (Only Red Hat employees and contractors)
The details of this Jira Card are restricted (Only Red Hat employees and contractors)
Epic DEVEXP-478: IPv6 Enablement

Goal: Enhance Devex-related components to work in IPv6 and dual-stack clusters.

Problem: OCP 4.3 and earlier assume clusters use IPv4 for network addresses. k8s 1.16 introduces beta support for IPv6 and dual-stack networking.

Why is this important: IPv6 support is identified as a critical requirement for Telecom/Edge deployments of OpenShift.

Dependencies (internal and external)

  1. Install team - deploy OpenShift with dual-stack or IPv6 configuration
  2. Test Platform - CI for IPv6 and/or dual-stack
  3. Networking - the heavy lifting of making IPv6 real

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

  1. DEVEXP-501 Audit IPv6 in OCM
  2. DEVEXP-497 Support IPv6 for image registry
  3. DEVEXP-498 Audit IPv6 in imagestream import
  4. DEVEXP-499 R&D IPv6 Support in Builds
  5. DEVEXP-500 Use HTTPS port (443) to serve image registry content Not in scope
  6. DEVEXP-507 Remove Samples Operator in IPv6 Single-Stack Environments

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

Previous Work:

Customers:

Open questions:

Story DEVEXP-497: Support IPv6 for Image Registry

User Story

As an OpenShift cluster admin
I want the image registry (and operator) to support IPv6
So that I can deploy the image registry on IPv6 clusters

Acceptance Criteria

  • Image registry is able to be installed and run on IPv6 clusters
  • Image registry is able to be installed and run on dual-stack clusters Dual stack is out of scope
  • Images can be pulled and pushed from/to the internal registry within an IPv6 cluster. This will depend on SDN working within an IPv6 cluster.
  • Images on the internal registry running in IPv6 clusters can be pulled and pushed from outside the cluster. Note - this will depend on Ingress/Routes working on IPv6 clusters as well.
  • Image registry operator is able to configure AWS S3 storage in an IPv6 or dual-stack environment.

Launch Checklist

Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated

Notes

Image registry only uses HTTP clients to connect to object storage or the apiservers.
This task may simply involve auditing the code and adding unit tests where appropriate.
Storage provider support for IPv6 is out of scope.

Bugs/issues in docker/distribution do require patches upstream - we are able to patch our fork.

We do not need to expose the UseDualStack option in the image registry operator. We are operating on the assumption that the AWS dualstack option does not impact customers who bring their own s3 appliances and use custom endpoints.

Node CA DaemonSet should work - it is only adding DNS locations to the pull secret.

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?
Story DEVEXP-507: Bootstrap Samples Operator as Removed when TBR inaccessible

User Story

As an OpenShift cluster admin
I want the samples operator to not report Degraded after initial installs with IPv6 or disconnected clusters
So that OpenShift installations are successful

Acceptance Criteria

  • Samples operator is able to be installed on IPv6/disconnected clusters
  • Samples operator detects the TBR (registry.redhat.io) is accessible on initial startup during creation of config object.
  • If TBR is inaccessible, bootstrap itself as Removed on new installations.

Launch Checklist

Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated

Notes

registry.redhat.io does not support IPv6 yet. Therefore the samples should not be installed on IPv6 single-stack clusters.
Jenkins comes in from the payload, but there is no explicit support for IPv6 yet.

We will need a release note and doc update indicating the Samples are Removed in IPv6, and that setting to Managed won't work unless:

  1. registry.redhat.io supports IPv6 or
  2. Samples content is mirrored and the cluster is appropriately configured to pull samples from the mirror.

Due diligence - make sure that upgrades work (existing Samples operator setting is respected on upgrade). Ensure that when Removed the samples operator reports appropriate status.

We should also create an enhancement proposal to further the discussion on what (if any) network related details are exposed to the cluster. Ex - if cluster was installed in a restricted/disconnected environment.

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?