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

[TP] Device role tagging for network devices in API

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • None
    • CNV Network
    • device-role-tagging-for-vnics
    • Incidents & Support
    • Hide

      1. Device roles can be exposed to the guest as a disk

      Show
      1. Device roles can be exposed to the guest as a disk
    • To Do
    • VIRTSTRAT-325 - Device role tagging
    • 57% To Do, 14% In Progress, 29% Done
    • dev-ready, doc-ready, po-ready, qe-ready, ux-ready
    • Technology Preview
    • Proposed

      Goal

      Today it's hard for a guest to understand to which network a NIC is connected to

      Provide a way to expose device informations to the guest in order to understand which resources they are attached to (i.e. to tell which vNIC is attached to which logical network)

      User Stories

      • As an application developer I want to know to what resource which device is connected in order to connect my application to i.e. to the correct network
      • I want to be able to create golden images which can be used fully automated via a common VM spec. In order to achieve that, I need a way to get from within the guest the devices, without first having to define e.g. MAC addresses upfront on VMs, or getting them assigned via kubemacpool.

      Without device tagging, automation flows have to look like this, due to the need of customized cloud-init payloads:

      1) Only works for VMs
       2) To automate this on VMs, one has to:
         a) post a VM
         b) read out the generated MAC addresses
         c) now create the cloud-init payload based on that, to bake the MAC address in, which means
            d) either updating the embedded cloud-config in the VM, or
            e) creating an extra secret and then updating the VM to point it to that secret

      Goal

      Non-Requirements

      • List of things not included in this epic, to alleviate any doubt raised during the grooming process.

      Notes

      • Read RHBZ#1874096 to learn about correlation options and limitations.

      Owners

      Role Contact
      PM TBD
      Documentation Owner TBD
      Delivery Owner (See assignee)
      Quality Engineer (See QA contact)

      Done Checklist

      Who What Reference
      DEV Upstream code and tests merged <link to meaningful PR or GitHub Issue>
      DEV Upstream documentation merged https://kubevirt.io/user-guide/virtual_machines/startup_scripts/#device-role-tagging
      DEV gap doc updated <name sheet and cell>
      DEV Upgrade consideration <link to upgrade-related test or design doc>
      DEV CEE/PX summary presentation label epic with cee-training and add a <link to your support-facing preso>
      QE Test plans in Polarion <link or reference to Polarion>
      QE Automated tests merged <link or reference to automated tests>
      DOC Downstream documentation merged <link to meaningful PR>

              phoracek@redhat.com Petr Horacek
              fdeutsch@redhat.com Fabian Deutsch
              Yossi Segev Yossi Segev
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

                Created:
                Updated: