Back to index

4.3.25

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

Changes from 4.2.36

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

Complete Features

These features were completed when this image was assembled

The details of this Jira Card are restricted (Only Red Hat employees and contractors)

User Story

As an OpenShift cluster admin/installer
I want the registry to be Removed on Baremetal installations
So that I can provision other storage providers
And later enable the image registry with the desired storage

Acceptance Criteria

  • On baremetal IPI installs (platform = BareMetal):
    • Registry management state is Removed
    • Registry reports itself as Available with a reason that makes it clear the registry has been removed (ex: Reason=Removed) - likely already done
  • Day 2 configuration works as expected (should work today):
    • Cluster admin is able to configure storage for the registry (ex: EmptyDir for CI testing).
    • Registry can be transitioned to Managed.
    • Once Managed, registry is available and operating normally.
    • Verify that the internal registry hostname has been published on image.config.openshift.io/cluster
  • Telemetetry and alerting
    • Report the registry has been removed (reason code `Removed` in the cluster operator status conditions)
    • Warning alert if the registry has been removed.

Launch Checklist

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

Notes

Enhancement proposal: https://github.com/openshift/enhancements/pull/45

Dependencies

  • CI needs an e2e-baremetal job (or equivalent)

Questions

  • Do different baremetal platforms need to be distinguished? Ex: what RHHI needs vs. RHV. For registry no, but perhaps other components will need this.
  • Telemetry/alerting - we may get Management state in telemeter. We can/should report the Available reason as Removed.
  • Baremetal testing - Need to make sure that our baremetal test suites are updated and can be invoked via an e2e-baremetal job

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 (Only Red Hat employees and contractors)

User Story

As an OpenShift user on Power and Z
I want the Samples operator to not provision templates on Power and Z
So that customers do not have images and templates that do not work on Power and Z

Acceptance Criteria

  • Samples operator installs vetted content from openshift/library appropriate for the cluster architecture
  • Samples operator does not install Jenkins imagestreams and templates on Power or Z (even though a Jenkins image may be in the release payload).
  • Samples operator behaves normally if no imagestreams/templates are available for the cluster architecture (reports itself Available=true, Progressing=false, Degraded=false).

Launch Checklist

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

Notes

Assumptions

  • Clusters will be homogeneous - mixed x86 and Power/Z nodes are not in scope.

Dependencies

  • Jenkins will not be available on Power and Z in the 4.3 timeframe. Decision has been made to put the x86 image in the release payload (it will break if somehow ran).
  • Platform architecture may need to be available on the cluster so we can bootstrap with the correct arch.
    • If not available, use GOARCH variable.

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

The details of this Jira Card are restricted (Only Red Hat employees and contractors)

User Story

As a cluster admin
I want to be alerted if the image registry is degraded
So that I can take action if human intervention is needed

Acceptance Criteria

  • Image registry operator has service monitor/Prometheus configured properly
  • Meaningful and actionable alerts are triggered
    • Alert if image registry does not have storage configured after X period of time (48 hours)  
    • Alert if degraded for a reason other than StorageNotConfigured  
    • Alert if registry storage is being re-recreated (potential data loss event)

Notes:

Refer to Fredric's guide on configuring Prometheus monitoring and alerting: https://docs.google.com/document/d/1rCKAYTrYMESjJDyJ0KvNap05NNukmNXVVi6MShISnOw/edit#heading=h.sndx01stw9z9

 

 This alert overlaps with or is already provided by Cluster Version Operator, removed from scope.

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

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

User Story

As a cluster admin
I want to be alerted if the image registry is degraded
So that I can take action if human intervention is needed

Acceptance Criteria

  • Service monitor is set up so that Prometheus can gather metrics on the Samples operator.
  • Samples operator code is updated to publish a Prometheus metrics endpoint, and fire alerts.
  • Samples operator reports degraded status in appropriate situations
  • Metrics for business consumption
    • Imagestream metrics - add label by namespace? (consider for discussion)
    • Samples operator condition metrics
    • Samples operator - active imports (along the lines of builds)
  • Meaningful and actionable alerts are triggered
    • Always fire alert when degraded is reporting

Notes:

Refer to Fredric's guide on configuring Prometheus monitoring and alerting: https://docs.google.com/document/d/1rCKAYTrYMESjJDyJ0KvNap05NNukmNXVVi6MShISnOw/edit#heading=h.sndx01stw9z9