Skip to content

Latest commit

 

History

History
124 lines (87 loc) · 8.26 KB

2020-10-02.md

File metadata and controls

124 lines (87 loc) · 8.26 KB
Raw

This Week in Enhancements - 2020-10-02

Hello, everyone!

Here you will find an overview of activity in the OpenShift enhancements repository in the last week. You can find previous editions on github.

Merged Enhancements

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

There were 3 Merged pull requests:

  • 436: (10/124) enhancement proposal for Packet IPI (displague)

    Support for OpenShift 4 on Packet was initially provided through the user provisioned (UPI) workflow.

    This enhancement proposes adding tooling and documentation to help users deploy OpenShift 4 on Packet using the installer provisioned infrastructure (IPI) workflow.

This enhancement was written by a Packet employee who is working on Packet IPI support for OpenShift. A number of people provided feedback on open questions that will need to be resolved and those have been captured in the enhancement. We reached a point where it was complete enough to merge as "provisional" and further discussion and iteration will take place in follow-up pull requests.

  • 452: (0/16) Add egress router EP (danielmellado)

    Egress traffic is traffic going from OpenShift pods to external systems, outside of OpenShift. There are a few options for enabling egress traffic, such as allow access to external systems from OpenShift physical node IPs, use EgressFirewall, EgressIPs or in our case, EgressRouter.

    In enterprise environments, egress routers are often preferred. They allow granular access from a specific pod, group of pods, or project to an external system or service. Access via node IP means all pods running on a given node can access external systems.

    An egress router is a pod that has two interfaces, (eth0) and (e.g. macvlan0). eth0 is on the cluster network in OpenShift (internal) and macvlan0 has an IP and gateway from the external physical network.

    Pods can access the egress router service thus enabling them to access external services. The egress router acts as a bridge between pods and an external system.

    Traffic going out the egress router goes via node, but it will have the MAC address of the macvlan0 interface inside the egress router.

    In openshift-sdn, the egress router was implemented by adding an annotation to allow a pod to request a macvlan interface. In order to avoid repeating this behavior in ovn-kubernetes, we'd be requesting such interface using multus to ensure feature-parity with openshift-sdn.

Some of the final gaps in ovn-kubernetes prior to making it GA are features gaps with openshift-sdn. This enhancement covers one of those final feature gaps.

  • 484: (6/37) Initial flexibly-enforcing-product-build-constraints-in-ci (jupierce)

    OpenShift, as a supported product (OCP), is built behind the Red Hat firewall using systems and methods that differ greatly from our CI infrastructure. This is not necessarily a negative as it permits our CI to move fast, while production builds maintain enterprise-grade trust through rigorous process and auditability. Until recently, these systems were effectively independent, allowing CI artifacts and production artifacts to vary -- regularly differing in the version of golang being used or the RPM versions installed in base images.

    To aid in the migration from UBI7 to UBI8 for OpenShift 4.6, a mechanism was implemented which periodically drives consistency for base & builder images unidirectionally from downstream production metadata to upstream CI configuration (upstream in this document refers to OpenShift repos and CI; downstream refers to ART/production builds).

    Having established that consistency for the purposes of the migration, we want to swing the pendulum back somewhat to allow upstream repositories greater flexibility and timing to choose precisely when and if they want to migrate to a new version of golang while still keeping upstream and downstream builds tightly aligned.

Closed Enhancements

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

There were 3 Closed pull requests:

  • 235: (0/4) migration to IP (sanchezl)
  • 423: (16/80) Implement OpenStack Cloud Controller Manager support (Fedosin)

This work continues, but the enhancement was closed in favor of 463, which discusses the external cloud provider issue more generally.

  • 487: (37/37) Add build root golang version from repo enhancement (alvaroaleman)

    Further discussion should happen in #484 which actually discusses the whole "keeping art in sync with CI". What was discussed here was really just a different way to configure the build_root which didn't really warrant an enhancement.

New Enhancements

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

There was 1 New pull request:

  • 489: (0/0) p2pnc: update api description (sanchezl)

    There are a few key network connections that are important to the health of the cluster. We can create a CRD to store the the last success time for each point-to-point check. By watching for explicit failures and lack of updates, we can produce a picture of when a point-to-point check failed. This information could be correlated to e2e failures, alerts, events, logs, or other information feeds.

Active Enhancements

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

There were 11 Active pull requests:

  • 463: (92/239) Describing steps to support out-of-tree providers (Danil-Grigorev)

An update from @Danil-Grigorev:

We agreed that the cloud-controller-manager binaries will be managed by a new operator, hosted in this repo. OpenStack will be the pioneer platform to run with the external CCM. It will be the default configuration for OpenStack in the 4.7 release. Initial operator implementation should be functional as well at 4.7. Other supported in-tree providers will be migrated in 4.8.

Running the operator will be a hard requirement for both bootstrap and post-install phase, due to the fact that kubelet and ingress-operator are both dependent on the CCM. Some details are still under discussion, but it is expected that we would use a static-pod implementation to run CCM at bootstrap phase, and later use Deployments in a running cluster.

  • 486: (18/23) Adds proposal for auto partitioning in LSO (rohan47)
  • 411: (10/42) run the Assisted Installer on-premise as opposed to utilizing a cloud service (mhrivnak)
  • 363: (9/196) Enhancement for adding upgrade preflight checks for operators (LalatenduMohanty)
  • 453: (8/92) network: Add a high level BGP use cases overview (russellb)
  • 483: (6/7) WIP: Add proposal for API to automatically spread MachineSets across AZs. (dgoodwin)
  • 419: (6/178) Enhancement for adding a manifest annotation for object removal (jottofar)
  • 137: (4/251) CLI in-cluster management (sallyom)
  • 482: (4/12) Add single-node-developer Cluster Profile (rkukura)
  • 471: (2/52) enhancement: Downstream Operator SDK (jmrodri)
  • 467: (2/13) Add MCO Flattened Ignition proposal (hardys)

-- Russell Bryant Doug Hellmann