Skip to content

Latest commit

 

History

History
124 lines (100 loc) · 9.36 KB

2021-01-08.md

File metadata and controls

124 lines (100 loc) · 9.36 KB
Raw

This Week in Enhancements - 2021-1-8

Merged Enhancements

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

There were no merged pull requests.

Closed Enhancements

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

There were 12 Closed pull requests:

  • 141: (0/11) machine-api: maintenance-lock enhancement request (beekhof)
  • 277: (0/0) general: Describe how to deploy OLM based operator on operatorhub.io (ingvagabund)
  • 307: (0/54) network: Add infiniband SR-IOV enhancement (zshi-redhat)
  • 325: (0/20) update: Bug 1773419: enhancements/update/cluster-version-operator-x509-upstream-trust: Propose a new enhancement (wking)
  • 328: (0/25) baremetal: improve debuggability of ipi deployments (stbenjam)
  • 343: (0/15) authentication: cluster-wide oauth-proxy settings (deads2k)
  • 359: (0/7) etcd: : Provide automated cluster backups (retroflexer)
  • 365: (0/17) network: enhancement for egress IP for OVN-Kubernetes (alexanderConstantinescu)
  • 366: (0/10) kata-containers: kata containers enhancement proposal (ariel-adam)
  • 380: (0/11) kube-apiserver: describe delete protection for resources to avoid client-side delete coordination (deads2k)
  • 395: (0/26) installer: add enhancement for custom trust for infra APIs (abhinavdahiya)
  • 424: (0/0) authentication: updates Separate-OAuth-API-Resources enhancement to reflect the current state of the world (p0lyn0mial)

New Enhancements

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

There were 5 New pull requests:

  • 571: (43/43) network: Cloud API component for egress IP (alexanderConstantinescu)

    OVN-Kubernetes and openshift-sdn today support the feature egress IP on bare-metal platforms. Going forwards OpenShift will need to support the feature on conventional cloud provider platforms (such as: GCP, AWS, Azure). Cloud providers require additional management of the egress IP address via the cloud provider's cloud API. That is required since the cloud provider will not let the network plugin claim an additional IP on the node, which it does not recognize.

    To be able to do this we will need to add logic (to either a dedicated component or to the network plugins themselves) as to be able to handle this. This enhancement proposal concerns itself with a discussion surrounding questions such as:

    • If the component should be generic enough as to allow other resources the capability to talk to the cloud API and modify host/cluster configurations? If the answer is yes, then we probably need an separate enhancement proposal for that, as this one only goes into the details of additional IP address assignment (within the scope of egress IP) - If the component should be a dedicated OpenShift component / upstream one? - If something existing in Kubernetes/OpenShift already exists which satisfies the requirements specified in this document? Certain resources have been found in the initial investigation leading to this enhancement proposal, which seem to indicate such. It is however not abundantly clear what those components do, and what their limitations are, see: [1], [2], [3], [4], [5]

    Moreover, this document goes into detail concerning:

    • The cloud provider data model required as to manage egress IP assignments in the cloud - The model and interaction between this future entity, the network plugin and any additional component required for this interaction to happen.

    OpenShift 4.8 aims to support egress IP assignments on Azure and AWS. GCP is targeted for OpenShift 4.9. This document tries however to make an abstraction from the requirements and deadlines set for each cloud w.r.t. each OpenShift release. Hence it does not solely focus on AWS or Azure, but instead aims at defining an architecture which is cloud agnostic and which would be applied with minimal implementation efforts for additional clouds.

    [1]: https://kubernetes.io/docs/concepts/architecture/cloud-controller/ [2]: https://github.com/kubernetes/cloud-provider [3]: https://github.com/kubernetes/cloud-provider-aws [4]: https://github.com/kubernetes/cloud-provider-gcp [5]: https://github.com/kubernetes-sigs/cloud-provider-azure

  • 574: (185/185) installer: First iteration of running the Assisted Installer in end-user clusters. (mhrivnak)

    The Assisted Installer currently runs as a SaaS on cloud.redhat.com, enabling users to deploy OpenShift clusters with certain customizations, particularly on bare metal hardware. It is necessary to bring those capabilities on-premise in users' clusters for two purposes:

    1. A cluster created by the Assisted Installer needs the ability to add workers on day 2. 2. Multi-cluster management, such as through hive and ACM, should be able to utilize the capabilities of the Assisted Installer.

    This enhancement proposes the first iteration of running the Assisted Installer in end-user clusters to meet the purposes above.

  • 575: (29/29) installer: Installer Enhacement Proposal: Manifests from STDIN (oglok)

    In many occasions, users need to customize the install-config target and/or the manifests generated by the OpenShift Installer in a reproducible manner. The most popular tool to allow this type of customization is “Kustomize”, and it is already well-known by the Kubernetes ecosystem. The result of any “Kustomization” is sent to standard output as a stream of manifests.

    This OpenShift enhancement proposes to allow the installer to read a stream of manifests from STDIN on the main targets that consume manifests.

  • 576: (0/0) cluster-logging: Move ES cert management into Elasticsearch Operator (ewolinetz)

    Currently to use the Elasticsearch Operator, one would need to generate secrets in a specific manner which creates a high amount of complexity for use. This proposal seeks to outline a mechanism where the Elasticsearch Operator creates and maintains these certificates and the elasticsearch/kibana secret instead of other operators (e.g. Cluster Logging and Jaeger), and allows an annotation mechanism on secrets for injecting required keys and certificates for mTLS with Elasticsearch.

New Minor Updates

  • 573: (1/1) network: host-port-registry: "workers" → "nodes" (Miciah)

Active Enhancements

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

There were 15 Active pull requests:

  • 565: (105/229) installer: single-node deployment with bootstrap-in-place (eranco74)
  • 560: (95/136) general: single-node production deployment approach (dhellmann)
  • 570: (95/113) cluster-logging: Enhancement Proposal: API to Forward Logs to CloudWatch (alanconway)
  • 555: (55/103) general: Cluster High-availability Mode API (dhellmann)
  • 524: (40/94) network: New method for providing configurable self-hosted LB/DNS/VIP for on-prem (yboaron)
  • 547: (29/29) baremetal: Propose BMC-less remediation enhancement (AKA poison pill) (n1r1)
  • 566: (20/28) general: Separating provider-specific code in the installer (janoszen)
  • 562: (17/57) security: Enhancing SCC to Gate Runtime Classes (haircommander)
  • 567: (12/12) machine-api: Added proposal for remediation history (slintes)
  • 518: (9/86) cluster-logging: Enhancement proposal: Forwarding JSON logs. (alanconway)
  • 438: (8/34) ingress: Add ingress fault detection proposal (sgreene570)
  • 569: (4/5) network: Bug 1908145: Add workloads localhost ports for recovery-controllers (damemi)
  • 346: (3/33) installer: Installer pre-flight validations (mandre)
  • 564: (2/3) cluster-logging: Allowing users to specify a delete policy based on amount of storage used within the ES cluster (ewolinetz)
  • 522: (2/7) olm: Update OLM managed operator metrics enhancement (awgreene)