yahoo-eng-team team mailing list archive

[Sylvain Bauza <sbauza@xxxxxxx>]

Reassigning to the Neutron project as the notification is emitted by it.

** Summary changed:

- Inconsistent RabbitMQ messages after subnet update
+ Inconsistent notifications after subnet update

** Also affects: neutron
   Importance: Undecided
       Status: New

** Changed in: nova
       Status: New => Invalid

** Tags removed: rabbitmq

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

Title:
  Inconsistent notifications after subnet update

Status in neutron:
  New
Status in OpenStack Compute (nova):
  Invalid

Bug description:
  Description
  ===========

  When I use horizon UI to update name of an existing subnet (through
  "Edit Subnet" dialog), the relevant message that gets posted to nova
  message queue (RabbitMQ) is inconsistent in both "event_type" field
  and structure in general.

  
  Steps to reproduce
  ==================
  Prerequisite: Project should contain a network.

  In Horizon UI:
  1. In sidebar go to Project -> Network -> Networks.
  2. In Subnets list click "Create subnet", fill the details and bind it to an existing network, click Next -> Create.
  3. On networks screen click "Edit Subnet" button next to newly created subnet.
  4. Change name to a new value, click Next -> Save.
  Repeat steps 3-4 at least 3 times (preferably, each time use a previously unused name).

  For "Expected/actual result" sections I'll refer to the subnet as "test-subnet". The sequence of updated names is the following:
  "test-subnet" -> "test-subnet1" -> "test-subnet2" -> "test-subnet3" -> "test-subnet4" -> "test-subnet5" -> "test-subnet6"

  
  Expected result
  ===============

  For each update a message is posted to RabbitMQ of the following
  structure (only important fields specified):

  {
    "event_type": "subnet.update.end",
    "payload": {
      "subnet": {
        "id": uuid of subnet,
        "name": updated subnet name 
      }
    }
  }

  
  Actual result
  =============
  For these consequential updates the pattern observed is the following:

  1) "test-subnet" -> "test-subnet1"
  {
    "event_type": "subnet.update.end",
    "payload": {
      "subnet": {
        "id": uuid of subnet,
        "name": "test-subnet1"
      }
    }
  }

  2) "test-subnet1" -> "test-subnet2"
  {
    "event_type": "subnet.update.start" (different event type),
    "payload": {
      "id": uuid of subnet (note the location of field)
      "subnet": {
        "name": "test-subnet2" (note the absence of id on this level)
      }
    }
  }

  
  3) "test-subnet2" -> "test-subnet3"
  No message was caught at all

  4) "test-subnet3" -> "test-subnet4"
  {
    "event_type": "subnet.update.end",
    "payload": {
      "subnet": {
        "id": uuid of subnet,
        "name": "test-subnet4"
      }
    }
  }
  // The same as in p.1, except for the new name
  5) "test-subnet4" -> "test-subnet5"
  // The same as in p.2, except for the new name
  6) "test-subnet5" -> "test-subnet6"
  // The same as in p.3

  This cycle repeats in this very order indefinitely.

  
  Environment
  ===========
  1. Mirantis-Mitaka (nova version 13.1.2)
  2. libvirt+KVM
  3. LVM
  4. neutron with OVS
  5. Python AMQP listener - kombu 4.0.2

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