Skip to content

Latest commit

 

History

History
166 lines (120 loc) · 12.6 KB

2020-12-04.md

File metadata and controls

166 lines (120 loc) · 12.6 KB
Raw

This Week in Enhancements - 2020-12-4

Due to the US holiday last week, we did not send the newsletter. This week's update includes changes since 2020-11-20 to cover both weeks.

Cluster profiles continue to be a theme as we transition planning for 4.8. The single-node-developer profile (482) was merged. There was more discussion on the single-node-production profile enhancement (504). And there is a new proposal for a cluster-wide "capabilities" API (555) that will expose some of the intents of different profiles without

Merged Enhancements

<PR ID>: (activity this week / total activity) summary

There were 12 Merged pull requests:

  • 450: (0/3) ingress: Adds Contour Operator Enhancement Proposal (danehans)

    This enhancement proposal is for adding an operator to manage Contour. Contour has been chosen for implementing Service APIs. Refer to the OpenShift Service APIs Project Plan for additional background on why Contour has been selected. The operator will have its own CRD, that will initially expose limited configuration capabilities. Existing operators will be used to guide the design of the Contour Operator. Tooling will be included to make it easy to build, run, test, etc. the operator for OpenShift.

  • 482: (11/212) general: Add single-node-developer Cluster Profile (rkukura)

    Add a new 'single-node-developer' cluster profile that defines the set of OpenShift payload components, and the configuration thereof, applicable to single-node resource-constrained non-production OCP clusters that support the development of OpenShift applications to be deployed for production on other OCP clusters, such as those using the default 'self-managed-high-availability' profile. The 'single-node-developer' profile will be defined for and utilized in producing the Code Ready Containers (CRC) product that runs in a single VM on a developer’s workstation or laptop. This profile is not intended or supported for any kind of production deployment.

  • 541: (22/68) scheduling: Scheduling profiles (damemi)

    This enhancement proposes a new field in the schedulers.config.openshift.io/v1 API to allow configuration of enabled and disabled scheduler plugins via defined profiles.

    This will simplify how users configure pod scheduling beyond the default set of enabled plugins in the default scheduler managed by the OpenShift operator.

  • 543: (27/31) update: extend design for how the CVO knows the cluster profile (guillaumerose)

    Cluster profiles are a way to support different deployment models for OpenShift clusters. A profile is an identifier that the Cluster Version Operator uses to determine which manifests to apply. Operators can be excluded completely or can have different manifests for each supported profile.

  • 544: (0/3) kubelet: describe kubelet credentials for authn/authz (deads2k)

    Kubelets need to be individually authenticated so that they can be individually authorized. Individual authentication and authorization allows for fine-grained API access control which limits API access to only those resources required to run the pods scheduled on a particular node. For example, kubelets can only read secrets that are mounted by pods scheduled to the node running the kubelet.

  • 548: (13/13) scheduling: Descheduler profiles (damemi)

    This enhancement proposes the v1 design for configuring the Descheduler Operator via API fields which select pre-defined policy configurations, which will then be propagated by the operator to the descheduler operand.

  • 550: (22/22) ingress: Add header-case-adjustment enhancement (Miciah)

    This enhancement extends the IngressController API to allow the cluster administrator to specify rules for transforming the case of HTTP header names in HTTP/1 requests. By default, an IngressController may down-case HTTP header names (but not HTTP header values; for example, X-Foo: Bar may be transformed to x-foo: Bar). This transformation is permitted by the HTTP protocol, according to which header names are case-insensitive. However, some non-conformant legacy HTTP clients and servers require headers names to be capitalized in a specific way. This new API provides a means to accommodate such legacy applications until they are fixed to conform to the HTTP protocol.

  • 553: (1/1) scheduling: Mark scheduler profiles implementable (damemi)

    This enhancement proposes a new field in the schedulers.config.openshift.io/v1 API to allow configuration of enabled and disabled scheduler plugins via defined profiles.

    This will simplify how users configure pod scheduling beyond the default set of enabled plugins in the default scheduler managed by the OpenShift operator.

Minor Merged Enhancements

  • 556: (0/0) network: Register baremetal provisioning ports (zaneb)

Closed Enhancements

<PR ID>: (activity this week / total activity) summary

There were 12 Closed pull requests:

  • 173: (0/0) autoscaling: Enable webhook serving on localhost of hostnetwork (tkashem)
  • 208: (0/6) etcd: etcd/cluster-etcd-operator: add steps to migrate quorum-guard (hexfusion)
  • 209: (0/21) installer: Support AWS China install (wanghaoran1988)
  • 215: (0/11) migration: CAM non-admin design (dymurray)
  • 223: (0/8) etcd: add replacing single lost master recovery steps (alaypatel07)
  • 226: (0/24) etcd: etcd DR leveraging cluster-etcd-operator scale up (alaypatel07)
  • 239: (0/2) monitoring: enhancements/monitoring/user-workload-monitoring: fix formatting, add details (s-urbaniak)
  • 271: (0/0) kube-apiserver: stability: logging in CI (deads2k)
  • 273: (0/0) kube-apiserver: stability: check cluster ingress with NO_PROXY both ways (deads2k)
  • 274: (0/0) kube-apiserver: stability: check every level of a managed route (deads2k)
  • 275: (0/0) machine-config: stability: check to see if machineconfigs are properly honored (deads2k)
  • 467: (0/19) machine-config: Add MCO Flattened Ignition proposal (hardys)

New Enhancements

<PR ID>: (activity this week / total activity) summary

There were 8 New pull requests:

  • 545: (0/0) network: Add BGP design section (markdgray)

    (no '## Summary' section found in enhancements/network/bgp-overview.md)

  • 547: (0/0) baremetal: Propose BMC-less remediation enhancement (AKA poison pill) (n1r1)

    Existing baremetal remediation strategies utilize BMC credentials to power-cycle and/or reprovision the host. However there are also environments that either do not include BMCs, or there are policies in place that prevent them from being utilized. Such environments would also benefit from the ability to safely recover affected workloads and restore cluster capacity (where possible).

    This proposal describes an alternate mechanism for a node in a cluster to detect its health status and take actions to remediate itself in case of a failure. While not all remediation events can result in the node returning to a healthy state, the proposal does allow surviving parts of the cluster to assume the node has reached a safe state so that its workloads can be automatically recovered.

    This work can also be useful for clusters with BMC credentials. If there’s a network outage between the node running CAPBM (which expects to use BMC commands like power-off etc.) and the unhealthy node, the power-cycle attempt cannot succeed. Self health checks and remediation can resolve such cases, however that work/scenario is out of scope for this proposal.

  • 549: (0/0) storage: Add proposal for CSI migration (bertinatto)

    We want to allow cluster administrators to enable and disable the migration of in-tree volumes to their counterparts CSI drivers.

  • 551: (24/24) machine-api: Propose to backport the "external remediation template" feature (slintes)

    By using MachineHealthChecks a cluster admin can configure automatic remediation of unhealthy machines and nodes. The machine healthcheck controller's remediation strategy is deleting the machine, and letting the cloud provider create a new one. This isn't the best remediation strategy in all environments.

    There is already a mechanism to provide an alternative, external remediation strategy, by adding an annotation to the MachineHealthCheck and then to Machines. However, this is isn't very maintainable and diverges from upstream.

    With this enhancement we propose a better, future-proof mechanism, that aligns us with the mechanism implemented upstream. This proposal is a backport of parts of the upstream machine healthcheck proposal [0], which also is already implemented [1].

  • 552: (19/19) guidelines: Add operational criteria to Enhancement template (jeremyeder)

  • 554: (0/0) general: conventions: Clarify when workload disruption is allowed (smarterclayton)

    During normal operation, workload disruption is not allowed (such as for CA rotation). Describe the boundaries of disruption, and provide guidelines about what availability components must maintain during normal operation.

  • 555: (29/29) general: cluster capabilities api (dhellmann)

    As we add more deployment topologies for OpenShift, we need a way to communicate expectations to the operators managing the cluster. This enhancement describes an API for expressing the expected "capabilities" of a cluster, including aspects such as how hard operators should work to provide high-availability and whether operators should configure their operands in a way to minimize resource consumption for especially constrained environments.

Active Enhancements

<PR ID>: (activity this week / total activity) summary

There were 8 Active pull requests:

  • 518: (58/71) cluster-logging: Enhancement proposal: Forwarding JSON logs. (alanconway)
  • 443: (43/64) machine-config: Support a provisioning token for the Machine Config Server (cgwalters)
  • 417: (4/42) installer: Add enhancement: IPI kubevirt provider (ravidbro)
  • 504: (4/42) general: single-node production deployments (dhellmann)
  • 486: (2/68) local-storage: Adds proposal for auto partitioning in LSO (rohan47)
  • 462: (2/17) ingress: Add client-tls enhancement (Miciah)
  • 524: (2/38) network: New method for providing configurable self-hosted LB/DNS/VIP for on-prem (yboaron)
  • 201: (1/32) general: bootimages: Downloading and updating bootimages via release image (cgwalters)