Uploaded image for project: 'OpenShift Request For Enhancement'
  1. OpenShift Request For Enhancement
  2. RFE-1994

Display Cluster CA Cert Expiry and Button to Force Cert Rotation in Console

XMLWordPrintable

    • False
    • False
    • 0
    • 0% 0%
    • Undefined

      1. Proposed title of this feature request

      Display Cluster CA Cert Expiry and Button to Force Cert Rotation in the OpenShift Web Console

      2. What is the nature and description of the request?

      As a customer and an administrator of an OpenShift cluster, I want to clear understanding of when a CA cert expiry and rotation events are going to take place, and a simple and supported way to force rotation (with/without subsequent reboot) during my own maintenance schedules. This option should be presented as a button in the console, in the same way the upgrade button works.

      Without this, I am at the mercy of the apiserver-operator and its pre-defined schedule of cert rotation at 80% of the the cert lifetime (to which we have no visibility - however is something that is calculable). Even with the existing work being done (due to customer demand) to prevent node reboots by the MCO, I, as an administrator still need to have awareness of the inner workings at cert mechanics of my cluster to work around it.

      3. Why does the customer need this? (List the business requirements here)

      Cert rotations and node reboots are disruptive for customers, even when we preach that properly architecture cloud native application applications should survive these operations, there are countless reasons customers do not wish for maintenance operations such as cert rotation and node reboots to be managed by the cluster. See number of linked cases here.

      The product is working to incorporate the standard procedure to force cert rotatation use by OSD SREs into the documentation, at the request of our top tier customers. This is a step in the right direction for cluster administrators who are already aware of these background cluster events and wish to pre-empt them, however this does little to help the class of cluster administrators who do not have that experience or knowledge. Not exposing this information in the cluster console continues to risk these background operations being disruptive for customers, and they learn the hard way once then have cluster/application outages, then dependent on RH support of consulting to help.

      4. List any affected packages or components.

      Web Console

            wcabanba@redhat.com William Caban
            rhn-support-trees Timothy Rees
            Votes:
            1 Vote for this issue
            Watchers:
            17 Start watching this issue

              Created:
              Updated:
              Resolved: