• Icon: Story Story
    • Resolution: Done
    • Icon: Undefined Undefined
    • None
    • None
    • None
    • None
    • False
    • None
    • False
    • Hypershift Sprint 245, Hypershift Sprint 246
    • 0
    • 0
    • 0

      • As an API consumer I don't want to be able to modify ports that are implementation details and have no consumer impact on features.
      • As a hypershift dev I want to support all the KAS exposure features while keeping the code sustainable and extensible

      Hypershift requires the kas corev1.endpoint port to be exposed in the data plane hosts. This is so when resolving traffic via SVC we capture traffic in that endpoint port and we leet haproxy redirect it to the LB that resolves to KAS.
      A while ago we introduced spec.metworking.apiServer.port to enable IBM to choose which port would be exposed in the data plane hosts, as using hardcode one might conflict with their env requirements.
      However as we evolved the different support matrix for our endpoints publishing strategy, we mistakenly used that input as the source for other ports exposure as the internal HCP namespace SVC. We also forced overwriting the corev1.endpoint value to avoid a discrepancy with what the kas pod was generating.

      Untangle the above by:

      • Never overriding the corev1.endpoint
      • Using spec.metworking.apiServer.port only for what's meant, i.e the KAS pod port.
      • Hiding the KAS SVC port. This is an impl detail.
      • If we ever require the dedicated KAS LB port to be a choice, that would be input in the LB publishing strategy



            agarcial@redhat.com Alberto Garcia Lamela
            agarcial@redhat.com Alberto Garcia Lamela
            Jie Zhao Jie Zhao
            0 Vote for this issue
            3 Start watching this issue