[Yahoo-eng-team] [Bug 1861401] [NEW] Renaming instance brokes DNS integration
Public bug reported: Colleagues, Description === Renaming instance (e.g. using "openstack server set --name") brokes DNS integration, since it makes it impossible to bind port with new instance's name. So, if user renamed instance and want to access it using name, he can not. Steps to reproduce == 1) You have an instance with some name (e.g. "web01") 2) You rename it using "openstack server set --name web02 web01" 3) You create port with instance's new name (e.g. web02) in order to attach it to the instance $ openstack port create --network e-net --fixed-ip subnet=e-subnet --dns-name web02 test_port 4) You're trying to attach the port to the instance: $ nova interface-attach --port-id web02 Expected result === Port binds to the instance and instance can be accessed using hostname "web02" Actual result = Last command in steps above fails with the following message: ERROR (ClientException): Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. Nova log says the following: 2020-01-30 11:43:32.652 17476 ERROR nova.api.openstack.wsgi PortNotUsableDNS: Port 0425701f-d958-4c81-931a-9594fba7d7d2 not usable for instance 2d49b781-cef5-4cdd-a310-e74eb98aa514. Value web02 assigned to dns_name attribute does not match instance's hostname web01 MySQL content show that renaming instance changed column "display_name", but "hostname" remained with old name: mysql> select hostname, display_name from instances where uuid='2d49b781-cef5-4cdd-a310-e74eb98aa514'; +--+--+ | hostname | display_name | +--+--+ | web01| web02| +--+--+ Thus, DNS integration compares port's dns_name to "hostname" not the "display_name", which makes it unusable after renaming instance. Either renaming instance need to change both "hostname" and "display_name" columns or DNS integration need compare port's dns_name with "display_name". Environment === Host OS: Ubuntu 18.04 LTS Openstack: Rocky $ dpkg -l |grep nova ii nova-api 2:18.2.3-0ubuntu1~cloud0 ii nova-common2:18.2.3-0ubuntu1~cloud0 ii nova-conductor 2:18.2.3-0ubuntu1~cloud0 ii nova-novncproxy2:18.2.3-0ubuntu1~cloud0 ii nova-placement-api 2:18.2.3-0ubuntu1~cloud0 ii nova-scheduler 2:18.2.3-0ubuntu1~cloud0 ii python-nova2:18.2.3-0ubuntu1~cloud0 ii python-novaclient 2:11.0.0-0ubuntu1~cloud0 Thank you. ** Affects: nova Importance: Undecided Status: New -- 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/1861401 Title: Renaming instance brokes DNS integration Status in OpenStack Compute (nova): New Bug description: Colleagues, Description === Renaming instance (e.g. using "openstack server set --name") brokes DNS integration, since it makes it impossible to bind port with new instance's name. So, if user renamed instance and want to access it using name, he can not. Steps to reproduce == 1) You have an instance with some name (e.g. "web01") 2) You rename it using "openstack server set --name web02 web01" 3) You create port with instance's new name (e.g. web02) in order to attach it to the instance $ openstack port create --network e-net --fixed-ip subnet=e-subnet --dns-name web02 test_port 4) You're trying to attach the port to the instance: $ nova interface-attach --port-id web02 Expected result === Port binds to the instance and instance can be accessed using hostname "web02" Actual result = Last command in steps above fails with the following message: ERROR (ClientException): Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. Nova log says the following: 2020-01-30 11:43:32.652 17476 ERROR nova.api.openstack.wsgi PortNotUsableDNS: Port 0425701f-d958-4c81-931a-9594fba7d7d2 not usable for instance 2d49b781-cef5-4cdd-a310-e74eb98aa514. Value web02 assigned to dns_name attribute does not match instance's hostname web01 MySQL content show that renaming instance changed column "display_name", but "hostname" remained with old name: mysql> select hostname, display_name from instances where uuid='2d49b781-cef5-4cdd-a310-e74eb98aa514'; +--+--+ | hostname | display_name | +--+--+ | web01| web02| +--+--+ Thus, DNS integration compares port's dns_name to "hostname" not the "display_name", which makes it unusable after renaming instance. Either renaming instance need to change both "hostname" and "display_name" columns or DNS integration need compare port's dns_name with "display_name". Environment === Host OS: Ubuntu 18.
[Yahoo-eng-team] [Bug 1824477] [NEW] dhcp: need to reorder classless static route record
Public bug reported: Dear colleagues, if there are Subnet1 with Host1 and Subnet2 with Host2 and Host2 serves Network2 behind it, in order to reach Network2 it is required to add Network2 to Subnet1's host_routes with Host2 as a nexthop. In this case Neutron will offer in Subnet1 the following set of RFC3442 routes: Network2 -> Host2 Subnet2_cidr -> 0.0.0.0 which will lead to fail installing Network2 route on the Host1 since at the moment of Network2's appearance there is no information about Subnet2 route. I've submitted for review the patch, which orders routes in such a way that 'connected' routes (0.0.0.0) will be placed first and, thus, all subsequent routes will be installed successfully. https://review.openstack.org/#/c/651994/ Thank you. ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1824477 Title: dhcp: need to reorder classless static route record Status in neutron: New Bug description: Dear colleagues, if there are Subnet1 with Host1 and Subnet2 with Host2 and Host2 serves Network2 behind it, in order to reach Network2 it is required to add Network2 to Subnet1's host_routes with Host2 as a nexthop. In this case Neutron will offer in Subnet1 the following set of RFC3442 routes: Network2 -> Host2 Subnet2_cidr -> 0.0.0.0 which will lead to fail installing Network2 route on the Host1 since at the moment of Network2's appearance there is no information about Subnet2 route. I've submitted for review the patch, which orders routes in such a way that 'connected' routes (0.0.0.0) will be placed first and, thus, all subsequent routes will be installed successfully. https://review.openstack.org/#/c/651994/ Thank you. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1824477/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1791944] Re: boot_index ignorance when booting VM
The issue is inside VM, not Nova's one.
** Changed in: nova
Status: New => Invalid
--
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/1791944
Title:
boot_index ignorance when booting VM
Status in OpenStack Compute (nova):
Invalid
Bug description:
Dear colleagues,
seems I'm experiencing the issue, similar to
https://bugs.launchpad.net/nova/+bug/1570107 but on Queens. When I try
to boot VM with two volumes attached (both volumes made from bootable
images and are bootable as well) and use boot_index, Nova ignores
boot_index regardless of whether I use or don't use
disk_bus/device_type. I see the following debug in nova-api.log:
"block_device_mapping_v2": [
{"source_type": "volume", "delete_on_termination": false, "boot_index": 0,
"uuid": "df338f65-71b2-4735-909b-29693f8f80c8", "destination_type": "volume"},
{"source_type": "volume", "delete_on_termination": false, "boot_index": -1,
"uuid": "3461d1ec-102a-4372-a009-2d693a93a884", "destination_type": "volume"}]
but VM booted from uuid "3461d" (both are of the same bus_type - first
one is sda, 2nd is sdb). Absolutely same result for the another
configuration:
"block_device_mapping_v2": [
{"boot_index": 0, "uuid": "08c94175-0491-4339-ac39-b5a5aab51037", "disk_bus":
"virtio", "source_type": "volume", "device_type": "disk", "destination_type":
"volume", "delete_on_termination": false},
{"boot_index": -1, "uuid": "39184a9b-32cf-49fe-b3f9-5a98fdec9c24",
"disk_bus": "virtio", "source_type": "volume", "device_type": "disk",
"destination_type": "volume", "delete_on_termination": false}]
VM booted from "39184" (which is vdb, marked with -1), while another
volume (08c94, vda) marked with "0".
And even more - if I change order in configuration in the way:
"block_device_mapping_v2": [
{"boot_index": -1, "uuid": "1a6672b7-c196-4e91-b157-92432741d6d7",
"disk_bus": "virtio", "source_type": "volume", "device_type": "disk",
"destination_type": "volume", "delete_on_termination": false},
{"boot_index": 0, "uuid": "eee78267-385a-4bae-b53f-8ee4ec2e64e9", "disk_bus":
"virtio", "source_type": "volume", "device_type": "disk", "destination_type":
"volume", "delete_on_termination": false}]
I get booted from "-1" volume. Well, may be, some info in images
metadata influence boot order? These are:
- Image which always boot in all three examples above:
hw_disk_bus='scsi', hw_qemu_guest_agent='yes', hw_scsi_model='virtio-scsi',
img_hide_hypervisor_id='true', locations='[{u'url':
u'cinder://0fb40899-d22e-465d-981b-ce35d07180c3', u'metadata': {}}]
- Image, which I want to boot from:
hw_boot_menu='true', hw_disk_bus='scsi', hw_qemu_guest_agent='yes',
hw_scsi_model='virtio-scsi', img_hide_hypervisor_id='true',
locations='[{u'url':
u'swift+config://ref1/glance/7a71b12c-4a1e-479f-8676-cc2e671b7cc4',
u'metadata': {}}]
If this matters - Swift is CEPH Object Storage (for second image).
And surprise - SOMETIMES (in rare cases) VM boots with correct image,
but I can't find any system in this behavior.
- My environment is:
Operating system: Ubuntu 16.04
Openstack: Queens (Nova 2:17.0.5-0ubuntu1~cloud0, Glance
2:16.0.1-0ubuntu1.1~cloud0)
ADDITIONAL INFO:
- For the last example:
#virsh domblklist instance-077d
Target Source
vdavolumes/volume-eee78267-385a-4bae-b53f-8ee4ec2e64e9
vdbvolumes/volume-1a6672b7-c196-4e91-b157-92432741d6d7
and autogenerated libvirt config for the domain is available here -
https://pastebin.com/N51Kzysb
I use Heat to produce these configurations and config is the
following:
n1:
type: OS::Nova::Server
properties:
flavor: ...
config_drive: False
name: jex-n1
block_device_mapping_v2:
- volume_id: { get_resource: n1-attach }
delete_on_termination: false
device_type: disk
disk_bus: virtio
boot_index: -1
- volume_id: { get_resource: n1-vol }
delete_on_termination: false
device_type: disk
disk_bus: virtio
boot_index: 0
n1-vol:
type: OS::Cinder::Volume
properties:
size: 8
name: jex-n1-vol
image: bionic-Qpub
n1-attach:
type: OS::Cinder::Volume
properties:
size: 8
name: jex-n1-att
image: xenial
I will highly appreciate if anybody can help to solve this issue. Any
additional information can be provided by request.
Thank you.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1791944/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.la
[Yahoo-eng-team] [Bug 1791944] [NEW] boot_index ignorance when booting VM
Public bug reported:
Dear colleagues,
seems I'm experiencing the issue, similar to
https://bugs.launchpad.net/nova/+bug/1570107 but on Queens. When I try
to boot VM with two volumes attached (both volumes made from bootable
images and are bootable as well) and use boot_index, Nova ignores
boot_index regardless of whether I use or don't use
disk_bus/device_type. I see the following debug in nova-api.log:
"block_device_mapping_v2": [
{"source_type": "volume", "delete_on_termination": false, "boot_index": 0,
"uuid": "df338f65-71b2-4735-909b-29693f8f80c8", "destination_type": "volume"},
{"source_type": "volume", "delete_on_termination": false, "boot_index": -1,
"uuid": "3461d1ec-102a-4372-a009-2d693a93a884", "destination_type": "volume"}]
but VM booted from uuid "3461d" (both are of the same bus_type - first
one is sda, 2nd is sdb). Absolutely same result for the another
configuration:
"block_device_mapping_v2": [
{"boot_index": 0, "uuid": "08c94175-0491-4339-ac39-b5a5aab51037", "disk_bus":
"virtio", "source_type": "volume", "device_type": "disk", "destination_type":
"volume", "delete_on_termination": false},
{"boot_index": -1, "uuid": "39184a9b-32cf-49fe-b3f9-5a98fdec9c24", "disk_bus":
"virtio", "source_type": "volume", "device_type": "disk", "destination_type":
"volume", "delete_on_termination": false}]
VM booted from "39184" (which is vdb, marked with -1), while another
volume (08c94, vda) marked with "0".
And even more - if I change order in configuration in the way:
"block_device_mapping_v2": [
{"boot_index": -1, "uuid": "1a6672b7-c196-4e91-b157-92432741d6d7", "disk_bus":
"virtio", "source_type": "volume", "device_type": "disk", "destination_type":
"volume", "delete_on_termination": false},
{"boot_index": 0, "uuid": "eee78267-385a-4bae-b53f-8ee4ec2e64e9", "disk_bus":
"virtio", "source_type": "volume", "device_type": "disk", "destination_type":
"volume", "delete_on_termination": false}]
I get booted from "-1" volume. Well, may be, some info in images
metadata influence boot order? These are:
- Image which always boot in all three examples above:
hw_disk_bus='scsi', hw_qemu_guest_agent='yes', hw_scsi_model='virtio-scsi',
img_hide_hypervisor_id='true', locations='[{u'url':
u'cinder://0fb40899-d22e-465d-981b-ce35d07180c3', u'metadata': {}}]
- Image, which I want to boot from:
hw_boot_menu='true', hw_disk_bus='scsi', hw_qemu_guest_agent='yes',
hw_scsi_model='virtio-scsi', img_hide_hypervisor_id='true',
locations='[{u'url':
u'swift+config://ref1/glance/7a71b12c-4a1e-479f-8676-cc2e671b7cc4',
u'metadata': {}}]
If this matters - Swift is CEPH Object Storage (for second image).
And surprise - SOMETIMES (in rare cases) VM boots with correct image,
but I can't find any system in this behavior.
- My environment is:
Operating system: Ubuntu 16.04
Openstack: Queens (Nova 2:17.0.5-0ubuntu1~cloud0, Glance
2:16.0.1-0ubuntu1.1~cloud0)
ADDITIONAL INFO:
- For the last example:
#virsh domblklist instance-077d
Target Source
vdavolumes/volume-eee78267-385a-4bae-b53f-8ee4ec2e64e9
vdbvolumes/volume-1a6672b7-c196-4e91-b157-92432741d6d7
and autogenerated libvirt config for the domain is available here -
https://pastebin.com/N51Kzysb
I use Heat to produce these configurations and config is the following:
n1:
type: OS::Nova::Server
properties:
flavor: ...
config_drive: False
name: jex-n1
block_device_mapping_v2:
- volume_id: { get_resource: n1-attach }
delete_on_termination: false
device_type: disk
disk_bus: virtio
boot_index: -1
- volume_id: { get_resource: n1-vol }
delete_on_termination: false
device_type: disk
disk_bus: virtio
boot_index: 0
n1-vol:
type: OS::Cinder::Volume
properties:
size: 8
name: jex-n1-vol
image: bionic-Qpub
n1-attach:
type: OS::Cinder::Volume
properties:
size: 8
name: jex-n1-att
image: xenial
I will highly appreciate if anybody can help to solve this issue. Any
additional information can be provided by request.
Thank you.
** Affects: nova
Importance: Undecided
Status: New
--
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/1791944
Title:
boot_index ignorance when booting VM
Status in OpenStack Compute (nova):
New
Bug description:
Dear colleagues,
seems I'm experiencing the issue, similar to
https://bugs.launchpad.net/nova/+bug/1570107 but on Queens. When I try
to boot VM with two volumes attached (both volumes made from bootable
images and are bootable as well) and use boot_index, Nova ignores
boot_index regardless of whether I use or don't use
disk_bus/device_type. I see the following debug in nova-api.log:
"block_device_mapping_v2": [
{"source_type": "vol
[Yahoo-eng-team] [Bug 1785227] [NEW] Router port: no dataplane update on change
Public bug reported:
Hi colleagues,
I'm using Heat to provision Neutron and faced the bug which is rather
Neutron's than Heat's, since Neutron receives all information,
provisions control plane ('openstack port/router show' gives updated
config), but do nothing in dataplane.
My config, which I'm sending to Heat in order to change existing stack -
https://pastebin.com/7J6emmSt
Changes are: qnet2-gwport's ip_address changed from 1.1.1.1 to 1.1.1.2
Information about environment is below.
After I apply changes, I see everything is updated to 1.1.1.2 in
'openstack show' outputs:
$ openstack port show cbb4bb4b-7ce4-4e58-b81e-fc6262d8c53d
[ ... ]
| fixed_ips | ip_address='1.1.1.2',
subnet_id='95f6bce5-cb46-43f6-86b5-16a71306e54e'
| id| cbb4bb4b-7ce4-4e58-b81e-fc6262d8c53d
| device_id | 771bbc70-a4e9-4f42-9c51-71ba3e6b525f
$ openstack router show 771bbc70-a4e9-4f42-9c51-71ba3e6b525f
[ ... ]
| id | 771bbc70-a4e9-4f42-9c51-71ba3e6b525f
| interfaces_info | [{"subnet_id":
"95f6bce5-cb46-43f6-86b5-16a71306e54e", "ip_address": "1.1.1.2", "port_id":
"cbb4bb4b-7ce4-4e58-b81e-fc6262d8c53d"}]
but actual ip address in netns is old:
# ip netns exec qrouter-771bbc70-a4e9-4f42-9c51-71ba3e6b525f ip a
[ ... ]
265: qr-cbb4bb4b-7c: mtu 1450 qdisc noqueue
state UNKNOWN group default qlen 1000
link/ether d0:1c:a0:97:50:fb brd ff:ff:ff:ff:ff:ff
inet 1.1.1.1/24 brd 1.1.1.255 scope global qr-cbb4bb4b-7c
Logs with debug are available here - https://pastebin.com/Aj8WrGUt .
There you will find that neutron-openvswitch-agent see changes to port:
===
Resource Port cbb4bb4b-7ce4-4e58-b81e-fc6262d8c53d updated (revision_number
26->29).
Old fields: {'fixed_ips': [IPAllocation(ip_address=1.1.1.1,network_id
=d608a42b-984c-46c8-9537-8249aee4ce29,port_id=cbb4bb4b-7ce4-4e58-b81e-
fc6262d8c53d,subnet_id=95f6bce5-cb46-43f6-86b5-16a71306e54e)],
'binding_levels':
[PortBindingLevel(driver='openvswitch',host='compute1',level=0,port_id
=cbb4bb4b-7ce4-4e58-b81e-fc6262d8c53d,segment=NetworkSegment(a72cc202
-b6ec-49ed-8e42-6f7875a9131b))]}
New fields: {'fixed_ips':
[IPAllocation(ip_address=1.1.1.2,network_id=d608a42b-984c-46c8-9537-8249aee4ce29,port_id=cbb4bb4b-7ce4-4e58-b81e-fc6262d8c53d,subnet_id=95f6bce5-cb46-43f6-86b5-16a71306e54e)],
'binding_levels':
[PortBindingLevel(driver='openvswitch',host='compute1',level=0,port_id=cbb4bb4b-7ce4-4e58-b81e-fc6262d8c53d,segment=NetworkSegment(a72cc202-b6ec-49ed-8e42-6f7875a9131b))]}
===
but later reports "Transaction caused no change do_commit" for all
commands ("Running txn command") that openvswitch-agent runs.
ENVIRONMENT:
OS: Ubuntu 16.04.5 LTS (Xenial Xerus)
Kernel: 4.15.0-24-generic #26~16.04.1-Ubuntu SMP
Neutron: 2:12.0.3-0ubuntu1~cloud0 (Queens)
Openvswitch: 2.9.0-0ubuntu1~cloud0
Patches for bug 1776468 (https://bugs.launchpad.net/neutron/+bug/1776468/) are
applied.
Any help on this issue is highly appreciated. Any additional information
is available upon request.
Thank you!
** Affects: neutron
Importance: Undecided
Status: New
** Tags: neutron neutron-openvswitch-agent
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1785227
Title:
Router port: no dataplane update on change
Status in neutron:
New
Bug description:
Hi colleagues,
I'm using Heat to provision Neutron and faced the bug which is rather
Neutron's than Heat's, since Neutron receives all information,
provisions control plane ('openstack port/router show' gives updated
config), but do nothing in dataplane.
My config, which I'm sending to Heat in order to change existing stack -
https://pastebin.com/7J6emmSt
Changes are: qnet2-gwport's ip_address changed from 1.1.1.1 to 1.1.1.2
Information about environment is below.
After I apply changes, I see everything is updated to 1.1.1.2 in
'openstack show' outputs:
$ openstack port show cbb4bb4b-7ce4-4e58-b81e-fc6262d8c53d
[ ... ]
| fixed_ips | ip_address='1.1.1.2',
subnet_id='95f6bce5-cb46-43f6-86b5-16a71306e54e'
| id| cbb4bb4b-7ce4-4e58-b81e-fc6262d8c53d
| device_id | 771bbc70-a4e9-4f42-9c51-71ba3e6b525f
$ openstack router show 771bbc70-a4e9-4f42-9c51-71ba3e6b525f
[ ... ]
| id | 771bbc70-a4e9-4f42-9c51-71ba3e6b525f
| interfaces_info | [{"subnet_id":
"95f6bce5-cb46-43f6-86b5-16a71306e54e", "ip_address": "1.1.1.2", "port_id":
"cbb4bb4b-7ce4-4e58-b81e-fc6262d8c53d"}]
but actual ip address in netns is old:
# ip netns exec qrouter-771bbc70-a4e9-4f42-9c51-71ba3e6b525f ip a
[ ... ]
265: qr-cbb4bb4b-7c: mtu 1450 qdisc noqueue
state UNKNOWN group default qlen 1000
link/ether d0:1c:a0:97:50:fb brd ff:ff:ff:ff:ff:ff
inet 1.1.1.1/24 brd 1.1.1.255 scope global qr-cbb4bb4b-7c
Logs with debug are available here - https://pastebin.com/Aj8WrGUt .
[Yahoo-eng-team] [Bug 1755414] [NEW] VR replaces connected routes
Public bug reported: Hi colleagues, The idea behind this design is to easily switch VM between different address scopes (e.g. "grey" addresses in Subnet-1 and "white" in Subnet-2), using same port/MAC (which always is in E-Network). If VR connected to subnets belonging to same network (preformatted scheme also is at https://pastebin.com/AesqkcXa) : E-Network +--+ Subnet-1Subnet-2 +---++--+ ++--+ ||++| VM-+|||| ++ VR ++ /||\ qr-64.. -/ 0+ \- qg-16.. using Subnet-1 as LAN connection and Subnet-2 as external gateway connection, then Neutron swaps connected route to Subnet-1 with same route but through Subnet-2 interface (3rd entry in the following sequence): 14:45:18.043 Running command: ['ip', 'netns', 'exec', 'qrouter-UUID', 'ip', '-4', 'addr', 'add', '25.0.0.1/8', 'scope', 'global', 'dev', 'qr-64c53cf8-d9', 'brd', '25.255.255.255'] 14:45:19.815 Running command: ['ip', 'netns', 'exec', 'qrouter-UUID', 'ip', '-4', 'addr', 'add', '51.x.x.x/24', 'scope', 'global', 'dev', 'qg-16bdddb1-d5', 'brd', '51.x.x.255'] 14:45:20.283 Running command: ['ip', 'netns', 'exec', 'qrouter-UUID', 'ip', '-4', 'route', 'replace', '25.0.0.0/8', 'dev', 'qg-16bdddb1-d5', 'scope', 'link'] 14:45:20.919 Running command: ['ip', 'netns', 'exec', 'qrouter-UUID', 'ip', '-4', 'route', 'replace', 'default', 'via', '51.x.x.254', 'dev', 'qg-16bdddb1-d5'] which makes it impossible to communicate between VMs in Subnet-1 with the VR. Proposed solution: When creating VR, use "ip route add ... metric " for extra subnets of the interfaces. To achieve this: - function add_route() in ip_lib.py contain unconditional arg "replace" and add other args from function's parameters. If final "args" contains keywork "metric", then replace "replace" with "add". - when creating VR, add keyword "metric 20" (can be anything lower than connected metric) to all extra subnets. This will fix routing in case of conflict, will preserve routing model if there is no conflict and will preserve compatibility with other functions calling add_route (no keyword "metric" - no changes in behavior). Openstack: Pike Neutron: 11.0.2 Ubuntu: 16.04 Thank you. ** Affects: neutron Importance: Undecided Status: New ** Tags: neutron ** Description changed: Hi colleagues, The idea behind this design is to easily switch VM between different address scopes (e.g. "grey" addresses in Subnet-1 and "white" in Subnet-2), using same port/MAC (which always is in E-Network). If VR connected to subnets belonging to same network: - - E-Network + + E-Network +--+ - Subnet-1Subnet-2 + Subnet-1Subnet-2 +---++--+ ++--+ - ||++| - VM-+|||| - ++ VR ++ - /||\ -qr-64.. -/ 0+ \- qg-16.. - - using Subnet-1 as LAN connection and Subnet-2 as external gateway - connection, then Neutron swaps connected route to Subnet-1 with same - route but through Subnet-2 interface (3rd entry in the following - sequence): + ||++| + VM-+|||| + ++ VR ++ + /||\ + qr-64.. -/ 0+ \- qg-16.. + + using Subnet-1 as LAN connection and Subnet-2 as external gateway connection, then Neutron swaps connected route to Subnet-1 with same route but through Subnet-2 interface (3rd entry in the following sequence): 14:45:18.043 Running command: ['ip', 'netns', 'exec', 'qrouter-UUID', 'ip', '-4', 'addr', 'add', '25.0.0.1/8', 'scope', 'global', 'dev', 'qr-64c53cf8-d9', 'brd', '25.255.255.255'] 14:45:19.815 Running command: ['ip', 'netns', 'exec', 'qrouter-UUID', 'ip', '-4', 'addr', 'add', '51.x.x.x/24', 'scope', 'global', 'dev', 'qg-16bdddb1-d5', 'brd', '51.x.x.255'] 14:45:20.283 Running command: ['ip', 'netns', 'exec', 'qrouter-UUID', 'ip', '-4', 'route', 'replace', '25.0.0.0/8', 'dev', 'qg-16bdddb1-d5', 'scope', 'link'] 14:45:20.919 Running command: ['ip', 'netns', 'exec', 'qrouter-UUID', 'ip', '-4', 'route', 'replace', 'default', 'via', '51.x.x.254', 'dev', 'qg-16bdddb1-d5'] which makes it impossible to communicate between VMs in Subnet-1 with the VR. - Proposed solution: When creating VR, use "ip route add ... metric " for extra subnets of the interfaces. To achieve this: - function add_route() in ip_lib.py contain unconditional arg "replace" and add other args from function's parameters. If final "args" contains keywork "metric", then replace "replace" with "add". - when creating VR, add keyword
[Yahoo-eng-team] [Bug 1719261] [NEW] VM port state don't match Neutron's port admin state
Public bug reported: Dear colleagues, when I change port admin state to DOWN, this is not reflected accordingly on VM's side: $ openstack port set --disable n1-lan $ openstack port show n1-lan [ ... ] +---++ | Field | Value | +---++ | admin_state_up| DOWN | [ ... ] +---++ root@n1:~# ip a [ ... ] 3: eth0: mtu 1450 qdisc pfifo_fast state UP group default qlen 1000 BUT when using "virsh domif-setlink --domain --interface --state down" I'm getting correct "NO-CARRIER" signaling on the port: 3: eth0: mtu 1450 qdisc pfifo_fast state DOWN group default qlen 1000 Possibly, Nova misses messages from Neutron about port admin state change. Is it bug or feature and can this be fixed? My environment: Openstack version: Pike Host OS: Ubuntu 16.04.3 Nova: 16.0.0-0ubuntu1~cloud0 Neutron: 11.0.0-0ubuntu1~cloud0 Networking: Openvswitch 2.8.0-0ubuntu1~cloud0 Hypevisor: Libvirt+KVM Storage: CEPH 12.2.0-0ubuntu1~cloud0 Thank you. ** Affects: nova Importance: Undecided Status: New -- 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/1719261 Title: VM port state don't match Neutron's port admin state Status in OpenStack Compute (nova): New Bug description: Dear colleagues, when I change port admin state to DOWN, this is not reflected accordingly on VM's side: $ openstack port set --disable n1-lan $ openstack port show n1-lan [ ... ] +---++ | Field | Value | +---++ | admin_state_up| DOWN | [ ... ] +---++ root@n1:~# ip a [ ... ] 3: eth0: mtu 1450 qdisc pfifo_fast state UP group default qlen 1000 BUT when using "virsh domif-setlink --domain --interface --state down" I'm getting correct "NO-CARRIER" signaling on the port: 3: eth0: mtu 1450 qdisc pfifo_fast state DOWN group default qlen 1000 Possibly, Nova misses messages from Neutron about port admin state change. Is it bug or feature and can this be fixed? My environment: Openstack version: Pike Host OS: Ubuntu 16.04.3 Nova: 16.0.0-0ubuntu1~cloud0 Neutron: 11.0.0-0ubuntu1~cloud0 Networking: Openvswitch 2.8.0-0ubuntu1~cloud0 Hypevisor: Libvirt+KVM Storage: CEPH 12.2.0-0ubuntu1~cloud0 Thank you. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1719261/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1681784] [NEW] neutronclient: incorrect treatment of input parameters
Public bug reported:
Hi colleagues,
Neutron 10.0.0 (as part Ocata) on Ubuntu 16.04
Everything is ok when I use Neutron CLI to update port parameters, but
when I'm doing the same using Heat, it fails.
Heat's template for the object is:
e-secgroup:
type: OS::Neutron::SecurityGroup
properties:
name: SSH_ICMP
rules:
- direction: ingress
- protocol: tcp
remote_ip_prefix: 0.0.0.0/0
port_range_min: 22
port_range_max: 22
- protocol: icmp
remote_ip_prefix: 0.0.0.0/0
node1-wan:
type: OS::Neutron::Port
properties:
name: jadm-node1-wan
network: e-net
port_security_enabled: True
security_groups: [ default, { get_resource: e-secgroup } ]
Heat makes a call to Neutron using neutronclient and provides input
parameters in such way:
updating port with {'allowed_address_pairs': [], 'binding:vnic_type':
None, 'device_owner': None, 'mac_address': None, 'security_groups': [u
'53ede63e-b08f-4c95-b5fe-29cd21ed442a', u'0a48c45e-5a6d-
4b80-8226-08d2e8c5bb00'], 'device_id': None} handle_update
/usr/lib/python2.7/dist-
packages/heat/engine/resources/openstack/neutron/port.py:520
In return, I get the following error:
2017-04-11 09:51:31.809 14474 DEBUG neutronclient.v2_0.client [req-
54a51260-8701-4f94-9141-562443a3ad7e - bush - - -] Error message:
{"NeutronError": {"message": "Invalid input for device_owner. Reason:
'None' is not a valid string.", "type": "HTTPBadRequest", "detail": ""}}
_handle_fault_response /usr/lib/python2.7/dist-
packages/neutronclient/v2_0/client.py:266
If I explicitly set device_owner='' in Heat template, then neutronclient
accepts this key-value pair and returns error for the next parameter
(e.g. device_id):
2017-04-11 10:45:26.808 14474 DEBUG neutronclient.v2_0.client [req-
3f5c1c53-bec4-418f-bc0e-e04b23474c0e - bush - - -] Error message:
{"NeutronError": {"message": "Invalid input for device_id. Reason:
'None' is not a valid string.", "type": "HTTPBadRequest", "detail": ""}}
_handle_fault_response /usr/lib/python2.7/dist-
packages/neutronclient/v2_0/client.py:266
and this affects not only parameters of OS::Neutron::Port object, but
OS::Neutron::SecurityGroup's ones as well:
Resource UPDATE failed: BadRequest: resources.e-secgroup: Invalid input
for description. Reason: 'None' is not a valid string. Neutron server
returns request_ids: ['req-287db7f6-06be-4bc8-a11b-94be203c67da']
So, the problem is general and it seems that something wrong with
treatment of 'None' in input parameters: all clients should always treat
None values the same as not passing any value, while neutronclient
accepts '' and refuses None.
Severity: this bug blocks using Heat.
Thank you.
** Affects: neutron
Importance: Undecided
Status: New
** Tags: neutron neutronclient
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1681784
Title:
neutronclient: incorrect treatment of input parameters
Status in neutron:
New
Bug description:
Hi colleagues,
Neutron 10.0.0 (as part Ocata) on Ubuntu 16.04
Everything is ok when I use Neutron CLI to update port parameters, but
when I'm doing the same using Heat, it fails.
Heat's template for the object is:
e-secgroup:
type: OS::Neutron::SecurityGroup
properties:
name: SSH_ICMP
rules:
- direction: ingress
- protocol: tcp
remote_ip_prefix: 0.0.0.0/0
port_range_min: 22
port_range_max: 22
- protocol: icmp
remote_ip_prefix: 0.0.0.0/0
node1-wan:
type: OS::Neutron::Port
properties:
name: jadm-node1-wan
network: e-net
port_security_enabled: True
security_groups: [ default, { get_resource: e-secgroup } ]
Heat makes a call to Neutron using neutronclient and provides input
parameters in such way:
updating port with {'allowed_address_pairs': [], 'binding:vnic_type':
None, 'device_owner': None, 'mac_address': None, 'security_groups': [u
'53ede63e-b08f-4c95-b5fe-29cd21ed442a', u'0a48c45e-5a6d-
4b80-8226-08d2e8c5bb00'], 'device_id': None} handle_update
/usr/lib/python2.7/dist-
packages/heat/engine/resources/openstack/neutron/port.py:520
In return, I get the following error:
2017-04-11 09:51:31.809 14474 DEBUG neutronclient.v2_0.client [req-
54a51260-8701-4f94-9141-562443a3ad7e - bush - - -] Error message:
{"NeutronError": {"message": "Invalid input for device_owner. Reason:
'None' is not a valid string.", "type": "HTTPBadRequest", "detail":
""}} _handle_fault_response /usr/lib/python2.7/dist-
packages/neutronclient/v2_0/client.py:266
If I explicitly set device_owner='' in Heat template, then
neutronclient accepts this key-value pair and returns error for the
next parameter (e.g. device_id):
2017-04-11 10:45:26.808 14474 DEBUG neutronclient.v2_0.cl
[Yahoo-eng-team] [Bug 1657814] [NEW] Incorrect DNS assignment
Public bug reported:
Dear friends,
the problem is in the following: Neutron assign global "dns_domain"
value (specified in neutron.conf) to ports in project's network
regardless of network's "dns_domain" value specified in network
definition and incorrectly updates dnsmasq.
# cat /etc/neutron/neutron.conf |grep dns_domain
dns_domain = yo.
# cat /etc/neutron/plugins/ml2/ml2_conf.ini |grep dns
extension_drivers = port_security,dns
# openstack network show ctl-net
+---+--+
| Field | Value|
+---+--+
| admin_state_up| UP |
| availability_zone_hints | |
| availability_zones| nova |
| created_at| 2017-01-19T15:19:12Z |
| description | |
| dns_domain| ctl.ams. | <---
specific domain
| id| c1d688da-a92e-4fc0-bdc5-d9361a8e15b6 |
| ipv4_address_scope| None |
| ipv6_address_scope| None |
| mtu | 1450 |
| name | ctl-net |
| port_security_enabled | True |
| project_id| 1a69577c17884582861ec3904cd957cf |
| project_id| 1a69577c17884582861ec3904cd957cf |
| provider:network_type | vxlan|
| provider:physical_network | None |
| provider:segmentation_id | 101 |
| revision_number | 6|
| router:external | Internal |
| shared| False|
| status| ACTIVE |
| subnets | a9294448-9ebb-42be-8597-b206f3efc018 |
| tags | [] |
| updated_at| 2017-01-19T15:19:14Z |
+---+--+
# neutron port-create --name poi --dns-name poi ctl-net
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 | normal
|
| created_at| 2017-01-19T15:34:32Z
|
| description |
|
| device_id |
|
| device_owner |
|
| dns_assignment| {"hostname": "poi", "ip_address": "10.16.1.21",
"fqdn": "poi.yo."}|<- YO!
| dns_name | poi
|
| extra_dhcp_opts |
|
| fixed_ips | {"subnet_id": "a9294448-9ebb-42be-8597-b206f3efc018",
|
| | "ip_address": "10.16.1.21"}
|
| id| 5f002d62-267f-4470-a6af-c14119b1de61
|
| mac_address | fa:16:3e:e7:a5:f8
|
| name | poi
|
| network_id| c1d688da-a92e-4fc0-bdc5-d9361a8e15b6
|
| port_security_enabled | True
|
| project_id| 1a69577c17884582861ec3904cd957cf
|
| revision_number | 6
|
| security_groups
