Can not update port without creation new one

Bug #1624036 reported by Sergey Kraynev
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mirantis OpenStack
Fix Released
Sergey Kraynev
Fix Released
Sergii Rizvan
Sergii Rizvan

Bug Description

How it affects MOS:
Current bug blocks update of the port with required MAC address.
This functionality is necessary for configuration Calico networking in Kubernetes Murano Application.
Without fix, port will be re-created with different MAC address and IP, what makes cluster dead.

Original description:

Neutron client allows to update property: allowed_address_pairs,update-port-detail

Right now it cause if I want to update this resource it's not possible to use mac address of the same port, because setting new property cause update replace.
This update supported from liberty, so we also need backport fix to mitaka and liberty.

 - create stack with follow template:

heat_template_version: 2015-04-30


    type: string
    default: private


    type: OS::Neutron::Port
      network: { get_param: network }

    type: OS::Nova::Server
      image: cirros-0.3.4-x86_64-uec
      flavor: m1.micro
        - port: { get_resource: port }

- get port mac address via outputs or port-show command
- update template by adding follow properties:
    type: OS::Neutron::Port
      network: { get_param: network }
        - mac_address: port_mac_address

Expected result:
allowed_address_pairs will be applied to the same mac address as port has.

Current result:
new port with different mac address during Update replace be created and allowed_address_pairs will contains old mac address, mentioned early

Tags: area-heat
Revision history for this message
Igor Marnat (imarnat) wrote :
Revision history for this message
Sergey Kraynev (skraynev) wrote :

Murano Kubernetes Application, which should be released on the next week, requires support of Calico networking. Right now it does not work as expected due to some conflicts with Openstack networking.
The solution of this issue is to update port via neutron command.
However in light of Murano Application it should be done via Heat template.
When we tried to apply this approach we discovered, that there is an bug in Heat:

We have a patch on review in upstream

Also the same bug was created on mos 9.1 and proposed patch on review:

Current fix does not affect any Openstack components except:
Heat, Sahara, Murano.
Also it affects only Port resource, which is used by these services.
The risk for all these components is minimal, because it changes behavior of Port resource only if allowed_address_pairs is specified.
AFAIK, nobody use this option yet.
We may ask confirmation from Murano and Sahara teams if it's necessary.

Revision history for this message
Vitaly Sedelnik (vsedelnik) wrote : merged, setting to Fix Committed

Changed in mos:
status: Triaged → Fix Committed
tags: added: area-heat
tags: added: on-verifiaction
Revision history for this message
Alexander Nagovitsyn (gluk12189) wrote :

Log file before and after update template:

Changed in mos:
status: Fix Committed → Fix Released
Revision history for this message
Sergii Rizvan (srizvan) wrote :
Revision history for this message
Ekaterina Shutova (eshutova) wrote :

Verified on MOS 7.0 + mu6 updates.

Before: after stack-update new port was created and updated, old port was deleted.
With fix: old port is updated, mac, ip adresses added to allowed_address_pairs.

tags: removed: on-verifiaction
Revision history for this message
Denis Meltsaykin (dmeltsaykin) wrote :

A fix for 8.0 is obtained with a sync from liberty.

Revision history for this message
Fuel Devops McRobotson (fuel-devops-robot) wrote : Change abandoned on openstack/heat (openstack-ci/fuel-8.0/liberty)

Change abandoned by Sergii Rizvan <email address hidden> on branch: openstack-ci/fuel-8.0/liberty
Reason: The fix obtained via sync with upstream

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.