Uploaded image for project: 'OpenShift Virtualization'
  1. OpenShift Virtualization
  2. CNV-35223

[TP] OVN Kubernetes: Self-service secondary overlay

XMLWordPrintable

    • cnv-ovnk2-self-service-tp
    • Hide
      • (must-have) Overlay network can be created by a developer with project-admin role
      • (must-have) Access to this feature can be extended or restricted using RBAC
      • (must-have) This overlay network is secure and not beyond developer's privileges -  no access to VLANs, host networks
      • (must-have) When using the default bridge, we must not DOS our neighbors - egress must be subjected to EgressQoS https://docs.openshift.com/container-platform/4.14/rest_api/network_apis/egressqos-k8s-ovn-org-v1.html.
      • (must-have) Downstream documentation.
      • (should-have) Tier-2 test coverage.
      Show
      (must-have) Overlay network can be created by a developer with project-admin role (must-have) Access to this feature can be extended or restricted using RBAC (must-have) This overlay network is secure and not beyond developer's privileges -  no access to VLANs, host networks (must-have) When using the default bridge, we must not DOS our neighbors - egress must be subjected to EgressQoS https://docs.openshift.com/container-platform/4.14/rest_api/network_apis/egressqos-k8s-ovn-org-v1.html . (must-have) Downstream documentation. (should-have) Tier-2 test coverage.
    • Red
    • To Do
    • CNV-16692 - Networking OVN and UDN Integration
    • CNV-16692Networking OVN and UDN Integration
    • 10% To Do, 0% In Progress, 90% Done
    • dev-ready, doc-ready, po-ready, qe-ready, ux-ready
    • Hide

      For awareness. Due to shift of 4.18 priorities, we are putting our 4.17 work on pause. I will remove the target release after the next leads call....

      Show
      For awareness. Due to shift of 4.18 priorities, we are putting our 4.17 work on pause. I will remove the target release after the next leads call....

      Goal

      Allow developers to create secondary overlay networks for their projects.

      User Stories

      • As a cluster admin,
        I want developers to be able to create additional networks themselves,
        so they don't bother me unnecessarily,
        but only if these networks cannot be abused to gain access to other unavailable networks or exhaust cluster resources they would not be able to exhaust otherwise.
      • As the cluster admin,
        I want to restrict access to this feature by using RBAC,
        so I have a granular and native control over who can do what.
      • As a developer,
        I want to be able to request an overlay network for my project by myself.

      Non-Requirements

      • This epic is to track productization under CNV. The actual upstream feature should be tracked in the SDN project.

      Notes

      • Access to this feature should be controlled through RBAC. To be able to do that, we will need a custom CRD for "safe-to-be-created-and-used-by-an-untrusted-user network".

          1.
          		 upstream roadmap issue Sub-task New Normal Unassigned
          2.
          		 upstream documentation Sub-task New Normal Unassigned
          3.
          		 upgrade consideration Sub-task New Normal Unassigned
          4.
          		 CEE/PX summary presentation Sub-task New Normal Unassigned
          5.
          		 test plans in polarion Sub-task New Normal Unassigned
          6.
          		 automated tests Sub-task New Normal Unassigned
          7.
          		 downstream documentation merged Sub-task New Normal Unassigned

              ehaas1@redhat.com Edward Haas
              phoracek@redhat.com Petr Horacek
              Yossi Segev Yossi Segev
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: