yahoo-eng-team team mailing list archive

[OpenStack Infra <2106073@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.opendev.org/c/openstack/ironic/+/946677
Committed: https://opendev.org/openstack/ironic/commit/ea8b3fcc3fd3805a857dccad77f435f6340caf76
Submitter: "Zuul (22348)"
Branch:    master

commit ea8b3fcc3fd3805a857dccad77f435f6340caf76
Author: Julia Kreger <juliaashleykreger@xxxxxxxxx>
Date:   Mon Apr 7 06:36:11 2025 -0700

    Patch configdrive metadata
    
    Functionally, the behavior is a little different from Nova's metadata
    generation. Specifically nova exposes internal interface names in the
    form of the name of taps to the instance, and in the context
    of baremetal, that is much more noise than signal. Furthermore, Nova's
    network_data generation is a bit simplifed in that it also just refers
    to networks as network[0,1,n]. Ironic uses the actual Ids instead.
    
    It also looks like Ironic is properly injecting MTUs... which is likely
    an entirely separate bug which we can fix later. Filed as
    https://bugs.launchpad.net/ironic/+bug/2110322
    
    Where Nova would generate something like:
    
    {"links": [
        {"id": "tap397cd29c-f2",
         "vif_id": "397cd29c-f267-4925-bd3f-58d39bfd685a",
         "type": "phy",
         "mtu": null,
         "ethernet_mac_address": "52:54:00:b1:25:62"},
        {"id": "tap88fd06bc-c0",
         "vif_id": "88fd06bc-c006-46f6-bc9a-ff04a7ee0779",
         "type": "phy",
         "mtu": null,
         "ethernet_mac_address": "52:54:00:a8:f0:64"}],
     "networks": [
        {"id": "network0",
         "type": "ipv6_slaac",
         "link": "tap397cd29c-f2",
         "ip_address": "fd34:4b51:21c8:0:5054:ff:fe53:5cb4",
         "netmask": "ffff:ffff:ffff:ffff::",
         "routes": [{"network": "::", "netmask": "::", "gateway": "fd34:4b51:21c8::1"}],
         "network_id": "fef900f0-fb86-4f6e-9d24-d379b6a57f9c", "services": []},
        {"id": "network1",
         "type": "ipv4_dhcp",
         "link": "tap88fd06bc-c0",
         "network_id": "a73bc031-3984-4f40-80d1-a4d9d62a4caa"}],
     "services": []}
    
    Ironic neutron integrated VIF code generates:
    
    {"links": [
        {"id": "privateport",
         "type": "phy",
         "ethernet_mac_address": "52:54:00:b1:25:62",
         "vif_id": "397cd29c-f267-4925-bd3f-58d39bfd685a",
         "mtu": 1380},
        {"id": "privateport2",
         "type": "phy",
         "ethernet_mac_address": "52:54:00:a8:f0:64",
         "vif_id": "88fd06bc-c006-46f6-bc9a-ff04a7ee0779",
         "mtu": 1430}],
     "networks": [
        {"id": "e070764c-7641-4b35-80db-6056a8937193",
         "network_id": "fef900f0-fb86-4f6e-9d24-d379b6a57f9c",
         "type": "ipv6",
         "link": "privateport",
         "ip_address": "fd34:4b51:21c8:0:5054:ff:feb1:2562",
         "netmask": "ffff:ffff:ffff:ffff::",
         "routes": [{"network": "::0", "netmask": "::0", "gateway": "fd34:4b51:21c8::1"}]},
         {"id": "1923957a-94f2-4169-a1bb-b133b342c2b6",
          "network_id": "a73bc031-3984-4f40-80d1-a4d9d62a4caa",
          "type": "ipv4",
          "link": "privateport2",
          "ip_address": "192.0.2.96",
          "netmask": "255.255.255.0",
          "routes": [{"network": "0.0.0.0", "netmask": "0.0.0.0", "gateway": "192.0.2.1"}]}],
     "services": []}
    
    Related-Bug: 2110322
    Closes-Bug: 2106073
    Change-Id: If6125cf7af84dd1b4fa869f13932c43ac013d443


** Changed in: ironic
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/2106073

Title:
  Nova fails to generate network metadata with deferred ports

Status in Ironic:
  Fix Released
Status in OpenStack Compute (nova):
  Invalid

Bug description:
  When creating an instance with Nova using routed provider networks,
  Nova creates a port with `ip_allocation` set to `deferred`.  This will
  let Neutron add an IP address to the interface once it's bound to a
  host to ensure that it's part of the right segment.

  When using this in combination with ConfigDrive, you end up with a
  broken ConfigDrive with no links due to the fact that you have a
  `network_info` on create that looks like this:

  ```
  [
    {
      "id": "2f28d85a-c215-4c73-91cd-c7d965254711",
      "address": "fa:16:3e:85:b4:60",
      "network": {
        "id": "8c178449-cc1f-4f02-8a58-09f09a975b59",
        "bridge": null,
        "label": "baremetal",
        "subnets": [],
        "meta": {
          "injected": false,
          "tenant_id": "14f0af4a69ea4148b7b18939ae2ebcca",
          "mtu": 1500,
          "physical_network": "external-rack001",
          "tunneled": false
        }
      },
      "type": "unbound",
      "details": {},
      "devname": "tap2f28d85a-c2",
      "ovs_interfaceid": null,
      "qbh_params": null,
      "qbg_params": null,
      "active": false,
      "vnic_type": "normal",
      "profile": {},
      "preserve_on_delete": false,
      "delegate_create": true,
      "meta": {}
    }
  ]
  ```

  This `network_info` eventually refreshes later to be the correct
  value, however, since that is what is used in spawn time, it's also
  what is used in deploy time to geneate the config drive and never
  updated, meaning that you end up with no correct network_data.json.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ironic/+bug/2106073/+subscriptions