• As a OCP engineering, I would like to understand the limitations of deploying OCP worker nodes in Wavelength Zones with the edge implementation (introduced with Local Zones feature), so we can leverage the worker nodes using the "edge compute pool" capabilities to the fair-edge on RAN (Radio Access Network).

DESCRIPTION:

The Wavelength Zones is requested by RFE-3045, and as a results of research in SPLAT-670, we identified the limitations of creating nodes in Wavelength Zones using the edge pool, introduced in Local Zones (EP-1232).

The limitations are directly related when deploying worker nodes using public subnets, as Machine API did not support advanced network interface fields on the platformSpec for Machine to tell the AWS API to set public IPs from Carrier Gateways (component that replaces Internet Gateway from a regular and local zones, responsible to assign public IP from the carrier, infrastructure where the node will run).

On Local Zones implementation Phase II (SPLAT-657), the installer is creating public and private subnets, creating the worker node manifests configuration to use private subnets. That implementation may unblock the utilization of Wavelength Zones, letting installer to create public and private subnets with all development needed to be done on installer codebase.

The tests using the Local Zones Phase II automation with Wavelength Zones using the edge compute pool was done using public subnets with minimal changes on installer (when using Phase II for Local Zones).

Goal:

A) Identify changes/limitations on installer to follow the flow like this:

• 1) recognize the Wavelength Zone as part of edge compute pool, ensuring MachineSet manifests will be created for Wavelength private subnets; 
• 2) let terraform known about Wavelength Zones on the edge zone pool, to:
• 2a) create the Carrier Gateway (CAGW) and attach to the VPC
• 2b) create a Public Route Table for Wavelength, adding the default route entry to CAGW
• 2c) create public subnet(s) on Wavelength Zones added on the edge compute pool entry
• 2d) create private subnets on Wavelength Zones using the same flow of Local Zones: using parent's Nat Gateway (due limitation of NLB and NGW resources on those locations)

B) Document the steps to support decisions of BU on RFE-3045.

Note:

Considering the similarity of Local and Wavelength Zones, the quick evaluation deploying edge/worker nodes using the edge flow with Wavelength private subnets was done (Goal items 1 and 2d) on the AWS Local Zones Phase II development life cycle (not merged yet, ETA 4.14), and documented on here. Scenarios #14, #15 and #16 cover tests with many combinations using full zones (AZ, LZ and WLZ) available on us-east-1.

controlPlane:   
  hyperthreading: Enabled 
  name: master
  platform:
    aws:
      zones:
      - us-east-1b

compute:
- name: worker
  platform:
    aws:
      zones:
      - us-east-1b
- name: edge
  platform:
    aws:
      zones:
      - us-east-1-atl-1a
      - us-east-1-bos-1a
      - us-east-1-bue-1a
      - us-east-1-chi-1a
      - us-east-1-dfw-1a
      - us-east-1-iah-1a
      - us-east-1-lim-1a
      - us-east-1-mci-1a
      - us-east-1-mia-1a
      - us-east-1-msp-1a
      - us-east-1-nyc-1a
      - us-east-1-phl-1a
      - us-east-1-qro-1a
      - us-east-1-scl-1a
      - us-east-1-wl1-atl-wlz-1
      - us-east-1-wl1-bna-wlz-1
      - us-east-1-wl1-bos-wlz-1
      - us-east-1-wl1-chi-wlz-1
      - us-east-1-wl1-clt-wlz-1
      - us-east-1-wl1-dfw-wlz-1
      - us-east-1-wl1-dtw-wlz-1
      - us-east-1-wl1-iah-wlz-1
      - us-east-1-wl1-mia-wlz-1
      - us-east-1-wl1-msp-wlz-1
      - us-east-1-wl1-nyc-wlz-1
      - us-east-1-wl1-tpa-wlz-1
      - us-east-1-wl1-was-wlz-1 

ENGINEERING REFERENCES

• Contributes to RFE-3045 SDE-1460
• Blocked by Local Zones Phase II (full IPI) SPLAT-657
• Original spike SPLAT-670

• Wavelength Zones summary:

"AWS Wavelength is an infrastructure offering optimized for mobile edge computing applications. Wavelength Zones are AWS infrastructure deployments that embed AWS compute and storage services within communications service providers’ (CSP) 5G networks, so application traffic from 5G devices reach application servers running in Wavelength Zones without leaving the telecommunications network. This avoids the latency that would result from application traffic traversing multiple hops across the internet to reach its destination, which allows customers to take full advantage of the latency and bandwidth benefits offered by modern 5G networks."