Back to index

4.5.36

Jump to: Incomplete Features | Complete Epics | Incomplete Epics | Other Complete |

Changes from 4.4.33

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

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)
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)
The details of this Jira Card are restricted (Only Red Hat employees and contractors)

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

Goal: as a cluster admin, I want to registry credentials across a cluster so that teams can use the credentials for importing images and in builds (pull/push) without having to configure secrets within every project.

 

Red Hat registry authorization rules have changed which is not required when images are pulled from registry.access.redhat.com. Given that new Red Hat images are only available via registry.redhat.io which requires authentication, users are not able to just pull and use (deploy or use with builds) OpenShift images from the Red Hat registry in their namespaces like they did before and have to ask a cluster admin to import them into the openshift namespace. The openshift namespace contains a secret called samples-registry-credentials with the Red Hat registry credentials which is created by the samples-operator.  That facilitates image stream import in that particular project but nothing more. 

 

MCO is able to put the installer pull secret and any user specified credentials on the nodes. Taking advantage of that, Build and ImageStream controllers could leverage these credentials to handle the complete set of desired scenarios.

 

A developer should be able to pull images from either the Red Hat registry or users’ specific registries that require credentials (where they have provided those credentials to the MCO)  without any extra steps (e.g. configuring extra secrets). The targeted scenarios in this epic are:

  1. Import images into imagestream
  2. Image registry pull-through
  3. Build image pull.

 

When the above works, users should be able to successfully run the following commands on a vanilla OpenShift 4 cluster:

Problem: accessing Red Hat registry content (even images that are part of OpenShift) is cumbersome, and requires each user to acquire Red Hat registry credentials and perform a number of cumbersome steps to configure the credential in each namespace. Alternatively, they have to ask the cluster admin to the same for each namespace and skip acquiring their own credentials. The same problem applies to access other private registries.

 

Why is this important: to allow OpenShift users to consume Red Hat registry content on OpenShift in a self-service manner and simplify accessing private image registries. 

 

Dependencies (internal and external):

  • MCO - puts credentials on nodes the same way that it does it for RHCC credentials

 

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

  • Add node credentials to builds as pull/push secret
  • Add node credentials to imagestreams for pulling images
  • End-to-end docs for configuring private registries credentials (using MCO)

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

 

Previous Work:

 

Customers:

  • OpenShift Dedicated has this issue in both v3 and v4.  The permissions model in OSD does not allow a customer to read secrets in any openshift-* namespaces.  Therefore the workaround of having the cluster-admin copy the secret manually into namespaces will not work on OSD.  The 3 example commands (oc new-build / oc new-app / oc import-image) all fail with an “unauthorized” response from registry.redhat.io in OSD 4.x.  In OSD 3, we solve this issue using a config-loop which creates a systemd service which runs this script.  Again, we have no solution for this in 4.x and 3.x uses said workaround.
  • ARO (v3) puts the pull secret in the openshift namespace and on each node for docker to access.  ARO v4 does not yet exist, and would likely leverage any solution delivered in the product.

 

Open questions:

  • Is this day-1? If so, are we going to reuse the pullsecret from install config?
    Yes, reusing the same pull secrets from the install config, provided that’s all needed for using images from Red Hat registry with imagestreams and builds
  • Day-2: where is the additional pull secret living? Configmap? Which ns? There is no “additional pull secret” - additional secrets are added by updating the master pull secret in openshift-config
  • Day-1-2: are this crio pull secrets? Right now the MCO lands the pull secret to path: "/var/lib/kubelet/config.json", these are the crio pull secrets.
  • Do ARO or OSD do anything special wrt pull secrets? - Answered in the “Customers” section within this epic.

User Story

As an OpenShift user
I want the node credentials to be available for all builds
So that builds can always pull from registry.redhat.io
And other registries which require a pull secret

Acceptance Criteria

  • Build pod always mounts pull secrets that are available on the node
  • Pull secret from node is used when pulling images from authenticated registries, such as registry.redhat.io
  • Node credentials are used in addition to user-provided credentials. Order of precedence:
    • User-provided pull secrets (from build controller)
    • Pull secrets from service accounts (from build controller)
    • Node credentials - to be mounted and merged in

Launch Checklist

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

Notes

Related to using mirrors in builds.
It is possible that the user-provided creds and node creds can have overlapping registries.
We should submit an enhancement proposal - done.
Code needs to comment where we are mounting items from the host for future unprivileged/secured builds.
In a follow-up story we can add the ability to opt in/out of this feature.

User Story

As an OpenShift user
I want the node credentials to be used in imagestream pull-through
So that I can import images from registry.redhat.io
And other registries which require a pull secret
And cache the content on the internal registry

Acceptance Criteria

  • Image registry operator mounts the node pull secret into the image registry container
  • Image registry merges secrets during pull-through, with following precedence:
    • dockercfg secrets that exist in the image stream's namespace
    • Node credentials
  • Test cases
    • Import an image from registry.redhat.io without adding a pull secret in the namespace. Must use the --reference-policy=local flag to enable pull-through.
    • Import uses a pull secret that exists only in the image stream's namespace (regression test)

Launch Checklist

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

Notes

Existing issues with multiple creds for same registry are out of scope.
Potentially reuse code in DEVEXP-423 via github.com/openshift/runtime-utils repo or library-go.
(docker client used to be shared in origin).

User Story

As an OpenShift user
I want the node credentials to be used in imagestream import
So that I can import images from registry.redhat.io
And other registries which require a pull secret

Acceptance Criteria

  • Imagestream import mounts node pull secrets and uses them in imagestream import
  • Node credentials are merged with secrets used during import, with following precedence:
    • dockercfg secrets that exist in the namespace
    • Node credentials
  • Test case - import an image from registry.redhat.io without adding a pull secret in the namespace. Does not need to be a pull-through imagestream.

Launch Checklist

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

Notes

Needs input from the node and apiserver teams.
Existing issues with multiple creds for same registry are out of scope.
Potentially reuse code in DEVEXP-423 via github.com/openshift/runtime-utils repo.

Goal: Rebase to Kubernetes 1.18

Problem: DevExp components include control plane operators. These should be kept up with the upstream release to ensure these do not fall more than 1 release behind.

Why is this important: Rebasing reduces tech debt in future releases.

Dependencies (internal and external):

  • Apiserver - kubernetes 1.18 rebase
  • openshift/api and openshift/client-go - k8s rebase (wire in context)

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

  • DEVEXP-553 Rebase openshift-controller-manager on k8s 1.18
  • DEVEXP-554 Rebase openshift-controller-manager-operator on k8s 1.18
  • DEVEXP-556 Rebase image registry operator on Kubernetes 1.18
  • DEVEXP-555 Rebase image registry on Kubernetes 1.18
  • DEVEXP-557 Rebase samples operator on k8s 1.18
  • DEVEXP-558 Rebase openshift/builder on k8s 1.18

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

Previous Work:

Customers:

Open questions:

User Story

As a developer using OpenShift
I want the image registry operator to use k8s 1.18 libraries
So that the image registry operator can take advantage of the latest Kubernetes features.

Acceptance Criteria

  • Image registry operator works with k8s 1.18 libraries
  • Image registry is deployed on k8s 1.18 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:

  • 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 developer using OpenShift
I want the the samples operator to use k8s 1.18 libraries
So that the samples operator s can take advantage of the latest Kubernetes features.

Acceptance Criteria

  • Samples operator can work with k8s 1.18 libraries
  • Sample imagestreams and templates install on k8s 1.18 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:

  • 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 developer using OpenShift
I want the image registry to use k8s 1.18 libraries
So that the image registry can take advantage of the latest Kubernetes features.

Acceptance Criteria

  • Image registry works with k8s 1.18 libraries
  • Image registry capabilities work on k8s 1.18 clusters (image pull, image push, etc.)

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 developer using OpenShift
I want the builder image to use k8s 1.18 libraries
So that builds can take advantage of the latest Kubernetes features.

Acceptance Criteria

  • Builds can work with k8s 1.18 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:

  • 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?

Incomplete 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 not completed when this image was assembled

Applying pre-existing IAM roles will require some new fields in the install-config.yaml and a list of required permissions for each IAM role that are unique for each cloud platform. This applies for only AWS; work for supporting this for Azure and GCP have been broken out into a future release.

Other Complete

This section includes Jira cards that are not linked to either an Epic or a Feature. These tickets were completed when this image was assembled

Right now the CRD supports nodeSelector and tolerations.

We'd like to use nodeAffinity to ensure if we cannot land on infra nodes, that it lands somewhere else.

Background / discussion: https://coreos.slack.com/archives/CFJD1NZFT/p1580422383093000

Risk with nodeSelector is we'll have no image-registry if infra are offline.

Also look into bootstrapping such that image registry pods do not want to land on the same node.

Naveen Malik