Red Hat Bugzilla – Bug 1498513
OSP 10 Heat Engine does not support vnic_type "direct-physical"
Last modified: 2017-11-15 08:44:01 EST
Description of problem: OSP 10 supports SRIOV PF passthrough vnic_type "direct-physical" but OSP 10 (Newton based) heat engine does not support this vnic_type. This issue is seen in https://review.openstack.org/#/c/404494/ Version-Release number of selected component (if applicable): How reproducible: Customer is able to reproduce it and they have had to create a patch for the heat engine code. Steps to Reproduce: 1. Part of normal process using heat 2. 3. Actual results: Heat engine does not support vnic_type "direct-physical" Expected results: As this vnic_type is supported in OSP10, heat engine should support it Additional info: Patch given by customer as work around: <=== On Controller, check if the new vnic_type "direct-physical" is supported by heat-engine, if not add it and restart heat-engine service # grep direct-physical /usr/lib/python2.7/site-packages/heat/engine/resources/openstack/neutron/port.py # # sed -i -e "s/'direct', 'macvtap'/'direct', 'direct-physical', 'macvtap'/g" /usr/lib/python2.7/site-packages/heat/engine/resources/openstack/neutron/port.py # grep direct-physical /usr/lib/python2.7/site-packages/heat/engine/resources/openstack/neutron/port.py constraints.AllowedValues(['normal', 'direct', 'direct-physical', 'macvtap']), # systemctl restart heat-engine ===>
neutron port-create --vnic-type direct-physical public Created a new port: +-----------------------+--------------------------------------------------------------------+ | Field | Value | +-----------------------+--------------------------------------------------------------------+ | admin_state_up | True | | allowed_address_pairs | | | binding:host_id | | | binding:profile | {} | | binding:vif_details | {} | | binding:vif_type | unbound | | binding:vnic_type | direct-physical | | created_at | 2017-11-06T08:57:08Z | | description | | | device_id | | | device_owner | | | extra_dhcp_opts | | | fixed_ips | {"subnet_id": "7d73c0e6-b2fd-46fa-a2ba-5f08ccb046bc", | | | "ip_address": "10.0.0.212"} | | id | 7e64b9b0-2f56-49f5-a3b2-04d01df275ec | | mac_address | fa:16:3e:fb:51:04 | | name | | | network_id | 577c2043-a929-4624-8f94-f3551c80dc55 | | port_security_enabled | True | | project_id | 912e382417194f7b90b32d01fb1d2131 | | qos_policy_id | | | revision_number | 6 | | security_groups | 73f87cfc-42d5-47ca-ad27-5f951409c0c5 | | status | DOWN | | tenant_id | 912e382417194f7b90b32d01fb1d2131 | | updated_at | 2017-11-06T08:57:08Z | +-----------------------+--------------------------------------------------------------------+
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:3232