yahoo-eng-team team mailing list archive

[OpenStack Infra <1930432@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.opendev.org/c/openstack/neutron/+/794130
Committed: https://opendev.org/openstack/neutron/commit/e0ea4a51ba36e227130c3b2a29d4eadc84615a6b
Submitter: "Zuul (22348)"
Branch:    master

commit e0ea4a51ba36e227130c3b2a29d4eadc84615a6b
Author: LIU Yulong <i@xxxxxxxxxxxx>
Date:   Wed Jun 2 13:23:44 2021 +0800

    [L2] no provisioning block for internal service port
    
    Provisioning Blocks [1] was introduced to manage composite
    object status. Port object is the one Neutron sets provisioning
    block during the port processing life cycle. Here is the compute
    port (VM's NIC port) processing procedure:
    1. nova creates port
    2. the 'openvswitch' mechinism driver inserts provisioning block
       for this port
    3. nova calls related interface to plug the device
    4. L2-agent sets the flows (or rules/devices) for the port and
       call update_device_list to neutron-server
    5. neutron-server try to set port status to ACTIVE
    6. neutron-server notify nova that "vif-plugged" success
    
    This works fine for VM with its ports. But for neutron service port,
    like router_gateway, router_interface and dhcp, it is unnecessary.
    Because there is no dependency among neutron resources. Neutron
    just knows that the ports had been set properly. And another thing
    is, for most of these internal service port, there is no need of
    DHCP, security group or port security.
    
    So for neutron internal service ports, the procesure can be:
    1. neutron L3/DHCP/X related service plugin creates port
    2. no provisioning_block
    3. L3/DHCP/X related agent plug the port
    4. L2-agent sets the flows (or rules/devices) for the port and
       call update_device_list to neutron-server
    5. neutron-server sets port status to ACTIVE directly, then done!
    
    This patch will set neutron *AgentMechanismDrver (including built-in
    drivers: linuxbridge, macvtap, sriov, openvswitch) to skip inserting
    the provisioning_block for Neutron internal service ports.
    
    [1] https://docs.openstack.org/neutron/latest/contributor/internals/provisioning_blocks.html
    
    Closes-Bug: #1930432
    Change-Id: Iaf7788bf0cba19a693cbf456f98e50d7b5de9e41


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

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1930432

Title:
  [L2] provisioning_block should be added to Neutron internal service
  port? Or should not?

Status in neutron:
  Fix Released

Bug description:
  provisioning_blocks are mostly used for compute port to notify that
  Neutron has done the networking settings, so VM can go power-on now.
  But now, Neutron does not check the port's device owner, it adds
  provisioning_block to all types of ports, even it is used by neutron.

  For some internal service ports, neutron does not notify anything to
  neutron itself, but the provisioning_block may cause some timeout for
  resource setup.

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