[Yahoo-eng-team] [Bug 1950894] Re: live_migration_permit_post_copy mode does not work
** Project changed: nova => charm-nova-compute
** Summary changed:
- live_migration_permit_post_copy mode does not work
+ live-migration-permit-post-copy mode does not work
** Description changed:
Description
===
Some customers have noted that some VMs never complete a
live migration. The VM's memory copy keeps oscillating
- around 1-10% but never completes. After changing
- live_migration_permit_post_copy = True, we expected this to
+ around 1-10% but never completes. After changing
+ live-migration-permit-post-copy = True, we expected this to
converge and migrate successfully as this feature describes it
should.
Workaround 1: It's possible to complete the process if you log into the source
host and run the QMP command[1]:
virsh qemu-monitor-command instance-0026 '{"execute":"migrate-
start-postcopy"}'
-
- Workaround 2: The migration finishes if you run 'nova
live-migration-force-complete'
-
+ Workaround 2: The migration finishes if you run 'nova live-migration-
+ force-complete'
I believe this can also be a libvirt bug given that I don't see any
"migrate-start-postcopy"
coming from nova/libvirt logs[4], but only after I manually triggered it via
the execute
command above, at 2021-11-12 19:14:08.053+[4].
-
Steps to reproduce
==
* Set up an OpenStack deployment with live_migration_permit_post_copy=False
* Create a large VM (8+ CPUs) and install stress-ng
* Run stress-ng:
- nohup stress-ng --vm 4 --vm-bytes 10% --vm-method write64 --vm-addr-method
pwr2 -t 1h &
+ nohup stress-ng --vm 4 --vm-bytes 10% --vm-method write64 --vm-addr-method
pwr2 -t 1h &
* Migrate the VM, and check for the source host logs messages like:
- 'Migration running for \d+ secs, memory \d+% remaining'
- This should be oscillating like describing and migration not completing
+ 'Migration running for \d+ secs, memory \d+% remaining'
+ This should be oscillating like describing and migration not completing
* Complete or cancel the above migration, set
live_migration_permit_post_copy=True,
- restart nova services on the computes, and re-do the operation
-
+ restart nova services on the computes, and re-do the operation
Expected result
===
Migration should complete 100% of times
Actual result
=
The migration does not complete and VM's memory is never copied.
Environment
===
1. Exact version of OpenStack you are running[8]
21.2.1-0ubuntu1
-
2. Which hypervisor did you use[8]?
qemu-kvm: 4.2-3ubuntu6.18
libvirt-daemon: 6.0.0-0ubuntu8.14
-
2. Which storage type did you use?
Shared Ceph
-
3. Which networking type did you use?
OpenvSwitch L3HA
Logs & Configs
==
-
[1] QMP Commands:
https://gist.github.com/sombrafam/5e8e991058001c2b3843c0d08b4cd7d1
[2] Migration (completed manually with workaround 1) logs:
https://gist.github.com/sombrafam/b74497150ae4ae32494ac5735189e149
[3] nova-compute.log src:
https://gist.github.com/sombrafam/b74497150ae4ae32494ac5735189e149
[4] libvirt.log src:
https://gist.github.com/sombrafam/69f05404d7097265140e1578ea50c00c
[5] Migration list:
https://gist.github.com/sombrafam/39b72e242e27b6a3123603db1faa7b19
[6] Nova.conf dst host:
https://gist.github.com/sombrafam/ad43b268e7f4b69e7da513a0f7a0095f
[7] Nova.conf src host:
https://gist.github.com/sombrafam/ab27b40e577fbe56d741f01e811f3a18
[8] Package versions:
https://gist.github.com/sombrafam/0622792d82750b2141b45580b625b69f
[9] VM info:
https://gist.github.com/sombrafam/57eaa4c4ba4b141dec9659ee01f25b6d
--
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/1950894
Title:
live-migration-permit-post-copy mode does not work
Status in OpenStack Nova Compute Charm:
New
Bug description:
Description
===
Some customers have noted that some VMs never complete a
live migration. The VM's memory copy keeps oscillating
around 1-10% but never completes. After changing
live-migration-permit-post-copy = True, we expected this to
converge and migrate successfully as this feature describes it
should.
Workaround 1: It's possible to complete the process if you log into the source
host and run the QMP command[1]:
virsh qemu-monitor-command instance-0026 '{"execute":"migrate-
start-postcopy"}'
Workaround 2: The migration finishes if you run 'nova live-migration-
force-complete'
I believe this can also be a libvirt bug given that I don't see any
"migrate-start-postcopy"
coming from nova/libvirt logs[4], but only after I manually triggered it via
the execute
command above, at 2021-11-12 19:14:08.053+[4].
Steps to reproduce
==
* Set up an OpenStack deployment with live_migration_permit_post_copy=False
* Create a large VM (8+
[Yahoo-eng-team] [Bug 1950894] [NEW] live_migration_permit_post_copy mode does not work
Public bug reported:
Description
===
Some customers have noted that some VMs never complete a
live migration. The VM's memory copy keeps oscillating
around 1-10% but never completes. After changing
live_migration_permit_post_copy = True, we expected this to
converge and migrate successfully as this feature describes it
should.
Workaround 1: It's possible to complete the process if you log into the source
host and run the QMP command[1]:
virsh qemu-monitor-command instance-0026 '{"execute":"migrate-
start-postcopy"}'
Workaround 2: The migration finishes if you run 'nova
live-migration-force-complete'
I believe this can also be a libvirt bug given that I don't see any
"migrate-start-postcopy"
coming from nova/libvirt logs[4], but only after I manually triggered it via
the execute
command above, at 2021-11-12 19:14:08.053+[4].
Steps to reproduce
==
* Set up an OpenStack deployment with live_migration_permit_post_copy=False
* Create a large VM (8+ CPUs) and install stress-ng
* Run stress-ng:
nohup stress-ng --vm 4 --vm-bytes 10% --vm-method write64 --vm-addr-method
pwr2 -t 1h &
* Migrate the VM, and check for the source host logs messages like:
'Migration running for \d+ secs, memory \d+% remaining'
This should be oscillating like describing and migration not completing
* Complete or cancel the above migration, set
live_migration_permit_post_copy=True,
restart nova services on the computes, and re-do the operation
Expected result
===
Migration should complete 100% of times
Actual result
=
The migration does not complete and VM's memory is never copied.
Environment
===
1. Exact version of OpenStack you are running[8]
21.2.1-0ubuntu1
2. Which hypervisor did you use[8]?
qemu-kvm: 4.2-3ubuntu6.18
libvirt-daemon: 6.0.0-0ubuntu8.14
2. Which storage type did you use?
Shared Ceph
3. Which networking type did you use?
OpenvSwitch L3HA
Logs & Configs
==
[1] QMP Commands:
https://gist.github.com/sombrafam/5e8e991058001c2b3843c0d08b4cd7d1
[2] Migration (completed manually with workaround 1) logs:
https://gist.github.com/sombrafam/b74497150ae4ae32494ac5735189e149
[3] nova-compute.log src:
https://gist.github.com/sombrafam/b74497150ae4ae32494ac5735189e149
[4] libvirt.log src:
https://gist.github.com/sombrafam/69f05404d7097265140e1578ea50c00c
[5] Migration list:
https://gist.github.com/sombrafam/39b72e242e27b6a3123603db1faa7b19
[6] Nova.conf dst host:
https://gist.github.com/sombrafam/ad43b268e7f4b69e7da513a0f7a0095f
[7] Nova.conf src host:
https://gist.github.com/sombrafam/ab27b40e577fbe56d741f01e811f3a18
[8] Package versions:
https://gist.github.com/sombrafam/0622792d82750b2141b45580b625b69f
[9] VM info: https://gist.github.com/sombrafam/57eaa4c4ba4b141dec9659ee01f25b6d
** 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/1950894
Title:
live_migration_permit_post_copy mode does not work
Status in OpenStack Compute (nova):
New
Bug description:
Description
===
Some customers have noted that some VMs never complete a
live migration. The VM's memory copy keeps oscillating
around 1-10% but never completes. After changing
live_migration_permit_post_copy = True, we expected this to
converge and migrate successfully as this feature describes it
should.
Workaround 1: It's possible to complete the process if you log into the source
host and run the QMP command[1]:
virsh qemu-monitor-command instance-0026 '{"execute":"migrate-
start-postcopy"}'
Workaround 2: The migration finishes if you run 'nova
live-migration-force-complete'
I believe this can also be a libvirt bug given that I don't see any
"migrate-start-postcopy"
coming from nova/libvirt logs[4], but only after I manually triggered it via
the execute
command above, at 2021-11-12 19:14:08.053+[4].
Steps to reproduce
==
* Set up an OpenStack deployment with live_migration_permit_post_copy=False
* Create a large VM (8+ CPUs) and install stress-ng
* Run stress-ng:
nohup stress-ng --vm 4 --vm-bytes 10% --vm-method write64 --vm-addr-method
pwr2 -t 1h &
* Migrate the VM, and check for the source host logs messages like:
'Migration running for \d+ secs, memory \d+% remaining'
This should be oscillating like describing and migration not completing
* Complete or cancel the above migration, set
live_migration_permit_post_copy=True,
restart nova services on the computes, and re-do the operation
Expected result
===
Migration should complete 100% of times
Actual result
=
The migration does not complete and VM's memory is never copied.
Environment
===
1. Exact version of OpenStack you are running[8]
21.2.
[Yahoo-eng-team] [Bug 1943266] Re: Duplicated ARP responses from ovnmetadata namespaces
FYI, this bug was fixed in the upstream branch v21.06.0 this is the patch: https://github.com/ovn- org/ovn/commit/578238b36073256c524a4c2b6ed7521f73aa0019 ** Changed in: networking-ovn Status: New => Confirmed ** Changed in: networking-ovn Assignee: (unassigned) => Erlon R. Cruz (sombrafam) ** No longer affects: neutron -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1943266 Title: Duplicated ARP responses from ovnmetadata namespaces Status in networking-ovn: Confirmed Bug description: When OpenStack instances are connected to an external network, an ovn-etadata-namespace is created in each compute that has VMs attached to that network. Because the ovn-metadata namespace has interfaces with the same mac address in all computers, external switches might ARP query for the IP and receive multiple responses in different ports triggering network error alerts. [ubuntu@sombrafam-bastion(kvm):~/internal_git/stsstack-bundles/openstack]$ sudo arping -c 1 10.5.150.0 ARPING 10.5.150.0 42 bytes from fa:16:3e:d3:10:01 (10.5.150.0): index=0 time=1.678 msec 42 bytes from fa:16:3e:d3:10:01 (10.5.150.0): index=1 time=2.143 msec --- 10.5.150.0 statistics --- 1 packets transmitted, 2 packets received, 0% unanswered (1 extra) rtt min/avg/max/std-dev = 1.678/1.911/2.143/0.232 ms Reproducer: https://paste.ubuntu.com/p/nbnhvTM9d4/ To manage notifications about this bug go to: https://bugs.launchpad.net/networking-ovn/+bug/1943266/+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 1944619] [NEW] Instances with SRIOV ports loose access after failed live migrations
Public bug reported: If for some reason a live migration fails for an instance with an SRIOV port during the '_pre_live_migration' hook. The instance will lose access to the network and leave behind duplicated port bindings on the database. The instance re-gains connectivity on the source host after a reboot (don't know if there's another way to restore connectivity). As a side effect of this behavior, the pre-live migration cleanup hook also fails with: PCI device :3b:10.0 is in use by driver QEMU [How to reproduce] - Create an environment with SRIOV, (our case uses switchdev[1]) - Create 1 VM - Provoke a failure in the _pre_live_migration process (for example creating a directory /var/lib/nova/instances/) - Check the VM's connectivity - Check the logs for: libvirt.libvirtError: Requested operation is not valid: PCI device :03:04.1 is in use by driver QEMU, domain instance-0001 Full-stack trace[2] [Expected] VM connectivity is restored even if it gets a brief disconnection [Observed] VM loses connectivity which is only is restored after the VM status is set to ERROR and the VM is power recycled [1] https://paste.ubuntu.com/p/PzBM7y6Dbr/ [2] https://paste.ubuntu.com/p/ThQmDYtdSS/ ** Affects: neutron Importance: Undecided Status: New ** Description changed: - If for some reason a live migration fails for an instance with an SRIOV port - during the '_pre_live_migration' hook. The instance will lose access to the - network and leave behind duplicated port bindings on the database. + If for some reason a live migration fails for an instance with an SRIOV + port during the '_pre_live_migration' hook. The instance will lose + access to the network and leave behind duplicated port bindings on the + database. - The instance re-gains connectivity on the source host after a reboot (don't - know if there's another way to restore connectivity). As a side effect of this - behavior, the pre-live migration cleanup hook also fails with: + The instance re-gains connectivity on the source host after a reboot + (don't know if there's another way to restore connectivity). As a side + effect of this behavior, the pre-live migration cleanup hook also fails + with: PCI device :3b:10.0 is in use by driver QEMU [How to reproduce] - Create an environment with SRIOV, (our case uses switchdev[1]) - Create 1 VM - Provoke a failure in the _pre_live_migration process (for example creating a directory /var/lib/nova/instances/) - Check the VM's connectivity - Check the logs for: libvirt.libvirtError: Requested operation is not valid: PCI device :03:04.1 is in use by driver QEMU, domain instance-0001 + - Create an environment with SRIOV, (our case uses switchdev[1]) + - Create 1 VM + - Provoke a failure in the _pre_live_migration process (for example creating a directory /var/lib/nova/instances/) + - Check the VM's connectivity + - Check the logs for: libvirt.libvirtError: Requested operation is not valid: PCI device :03:04.1 is in use by driver QEMU, domain instance-0001 Full-stack trace[2] [Expected] VM connectivity is restored even if it gets a brief disconnection [Observed] VM loses connectivity which is only is restored after the VM status is set to ERROR and the VM is power recycled - - [1] https://paste.ubuntu.com/p/PzBM7y6Dbr/ [2] https://paste.ubuntu.com/p/ThQmDYtdSS/ -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1944619 Title: Instances with SRIOV ports loose access after failed live migrations Status in neutron: New Bug description: If for some reason a live migration fails for an instance with an SRIOV port during the '_pre_live_migration' hook. The instance will lose access to the network and leave behind duplicated port bindings on the database. The instance re-gains connectivity on the source host after a reboot (don't know if there's another way to restore connectivity). As a side effect of this behavior, the pre-live migration cleanup hook also fails with: PCI device :3b:10.0 is in use by driver QEMU [How to reproduce] - Create an environment with SRIOV, (our case uses switchdev[1]) - Create 1 VM - Provoke a failure in the _pre_live_migration process (for example creating a directory /var/lib/nova/instances/) - Check the VM's connectivity - Check the logs for: libvirt.libvirtError: Requested operation is not valid: PCI device :03:04.1 is in use by driver QEMU, domain instance-0001 Full-stack trace[2] [Expected] VM connectivity is restored even if it gets a brief disconnection [Observed] VM loses connectivity which is only is restored after the VM status is set to ERROR and the VM is power recycled [1] https://paste.ubuntu.com/p/PzBM7y6Dbr/ [2] https://paste.ubuntu.com/p/ThQmDYtdSS/ To manage notifications about this bug go to: http
[Yahoo-eng-team] [Bug 1943266] Re: Duplicated ARP responses from ovnmetadata namespaces
** Description changed: - When OpenStack instances are connected to an external network, an ovn-etadata-namespace is created in each compute that has VMs attached to that - network. Because the ovn-metadata namespace has interfaces with the same mac address in all computers, external switches might ARP query for the IP - and receive multiple responses in different ports triggering network error alerts. + When OpenStack instances are connected to an external network, an ovn-etadata-namespace is created in each compute that has VMs attached to that + network. Because the ovn-metadata namespace has interfaces with the same mac address in all computers, external switches might ARP query for the IP + and receive multiple responses in different ports triggering network error alerts. + + Reproducer: https://paste.ubuntu.com/p/nbnhvTM9d4/ ** Description changed: When OpenStack instances are connected to an external network, an ovn-etadata-namespace is created in each compute that has VMs attached to that network. Because the ovn-metadata namespace has interfaces with the same mac address in all computers, external switches might ARP query for the IP and receive multiple responses in different ports triggering network error alerts. + [ubuntu@sombrafam-bastion(kvm):~/internal_git/stsstack-bundles/openstack]$ sudo arping -c 1 10.5.150.0 + ARPING 10.5.150.0 + 42 bytes from fa:16:3e:d3:10:01 (10.5.150.0): index=0 time=1.678 msec + 42 bytes from fa:16:3e:d3:10:01 (10.5.150.0): index=1 time=2.143 msec + + --- 10.5.150.0 statistics --- + 1 packets transmitted, 2 packets received, 0% unanswered (1 extra) + rtt min/avg/max/std-dev = 1.678/1.911/2.143/0.232 ms + + Reproducer: https://paste.ubuntu.com/p/nbnhvTM9d4/ ** Also 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/1943266 Title: Duplicated ARP responses from ovnmetadata namespaces Status in networking-ovn: New Status in neutron: New Bug description: When OpenStack instances are connected to an external network, an ovn-etadata-namespace is created in each compute that has VMs attached to that network. Because the ovn-metadata namespace has interfaces with the same mac address in all computers, external switches might ARP query for the IP and receive multiple responses in different ports triggering network error alerts. [ubuntu@sombrafam-bastion(kvm):~/internal_git/stsstack-bundles/openstack]$ sudo arping -c 1 10.5.150.0 ARPING 10.5.150.0 42 bytes from fa:16:3e:d3:10:01 (10.5.150.0): index=0 time=1.678 msec 42 bytes from fa:16:3e:d3:10:01 (10.5.150.0): index=1 time=2.143 msec --- 10.5.150.0 statistics --- 1 packets transmitted, 2 packets received, 0% unanswered (1 extra) rtt min/avg/max/std-dev = 1.678/1.911/2.143/0.232 ms Reproducer: https://paste.ubuntu.com/p/nbnhvTM9d4/ To manage notifications about this bug go to: https://bugs.launchpad.net/networking-ovn/+bug/1943266/+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 1935810] [NEW] Failed to attach volume
Public bug reported: Fail operation invoked. Original error: WorkflowHeatOperationError: Stack operation error! Stack id: 9c0190fd-6c7c-4e7c-9986-8d7156fddcf3, expected status: COMPLETE, actual status: FAILED, reason: Resource CREATE failed: Error: resources.data_tele_static.resources[0].resources.group_of_volumes.resources[0].resources.volume_attachment: Failed to attach volume 646b66e8-b587-4b3e-bfbe-71e786e65fbb to server f40ec246-1c4b-448b-aa3e-d7d1b0fa2860 - Unexpected API Error. Please report this at http: //bugs.launchpad.net/nova/ and attach the Nova API log if possible. (HTTP 500) (Request-ID: req-0f5a73d0-2abb-4990-8d0c-35022b85c329) ** 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/1935810 Title: Failed to attach volume Status in OpenStack Compute (nova): New Bug description: Fail operation invoked. Original error: WorkflowHeatOperationError: Stack operation error! Stack id: 9c0190fd-6c7c-4e7c-9986-8d7156fddcf3, expected status: COMPLETE, actual status: FAILED, reason: Resource CREATE failed: Error: resources.data_tele_static.resources[0].resources.group_of_volumes.resources[0].resources.volume_attachment: Failed to attach volume 646b66e8-b587-4b3e-bfbe-71e786e65fbb to server f40ec246-1c4b-448b-aa3e-d7d1b0fa2860 - Unexpected API Error. Please report this at http: //bugs.launchpad.net/nova/ and attach the Nova API log if possible. (HTTP 500) (Request-ID: req-0f5a73d0-2abb-4990-8d0c-35022b85c329) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1935810/+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 1930281] [NEW] APT repo PGP keys not handled appropriately
Public bug reported: For further reference within this bug, I provide the example file https://pastebin.ubuntu.com/p/txzYWpY33j/ I am attempting to employ the apt tools provided within the cloud-init system to configure a new apt repository for installing docker during initial deployment. This is of course preferred to using shell commands as this would ideally allow better handling of issues of package installation and also hopefully be more secure. packages: ... - docker-ce - docker-ce-cli - containerd.io Are described within the user-data and apt: sources: docker: source: "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu focal stable" key: | -BEGIN PGP PUBLIC KEY BLOCK- ... -END PGP PUBLIC KEY BLOCK- Is provided as the corresponding key. This key is obtained by running the command : curl -fsSL https://download.docker.com/linux/ubuntu/gpg I am using the stock Ubuntu 20.04.2 cloud image as the guest platform. The expected/desired behavior of this would be to dearmor the GPG key provided into the /usr/share/keyrings directory with a filename (sourcename)-archive.gpg The actual behavior however is to install the GPG key within the /etc/trusted.gpg directory which appears to no longer be supported as apt-key is no longer supported (my reference for this information is https://www.linuxuprising.com/2021/01/apt-key-is-deprecated-how-to- add.html) As such, apt (update|upgrade|install) does not operate correctly and the following is seen in /var/log/cloud-init-output.log W: GPG error: https://download.docker.com/linux/ubuntu focal InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 7EA0A9C3F273FCD8 E: The repository 'https://download.docker.com/linux/ubuntu focal InRelease' is not signed. 2021-05-31 13:40:10,144 - util.py[WARNING]: Running module apt-configure () failed ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1930281 Title: APT repo PGP keys not handled appropriately Status in cloud-init: New Bug description: For further reference within this bug, I provide the example file https://pastebin.ubuntu.com/p/txzYWpY33j/ I am attempting to employ the apt tools provided within the cloud-init system to configure a new apt repository for installing docker during initial deployment. This is of course preferred to using shell commands as this would ideally allow better handling of issues of package installation and also hopefully be more secure. packages: ... - docker-ce - docker-ce-cli - containerd.io Are described within the user-data and apt: sources: docker: source: "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu focal stable" key: | -BEGIN PGP PUBLIC KEY BLOCK- ... -END PGP PUBLIC KEY BLOCK- Is provided as the corresponding key. This key is obtained by running the command : curl -fsSL https://download.docker.com/linux/ubuntu/gpg I am using the stock Ubuntu 20.04.2 cloud image as the guest platform. The expected/desired behavior of this would be to dearmor the GPG key provided into the /usr/share/keyrings directory with a filename (sourcename)-archive.gpg The actual behavior however is to install the GPG key within the /etc/trusted.gpg directory which appears to no longer be supported as apt-key is no longer supported (my reference for this information is https://www.linuxuprising.com/2021/01/apt-key-is-deprecated-how-to- add.html) As such, apt (update|upgrade|install) does not operate correctly and the following is seen in /var/log/cloud-init-output.log W: GPG error: https://download.docker.com/linux/ubuntu focal InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 7EA0A9C3F273FCD8 E: The repository 'https://download.docker.com/linux/ubuntu focal InRelease' is not signed. 2021-05-31 13:40:10,144 - util.py[WARNING]: Running module apt-configure () failed To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1930281/+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 1832021] Re: Checksum drop of metadata traffic on isolated networks with DPDK
** Description changed: + [Impact] + When an isolated network using provider networks for tenants (meaning without virtual routers: DVR or network node), metadata access occurs in the qdhcp ip netns rather than the qrouter netns. The following options are set in the dhcp_agent.ini file: force_metadata = True enable_isolated_metadata = True VMs on the provider tenant network are unable to access metadata as packets are dropped due to checksum. - When we added the following in the qdhcp netns, VMs regained access to - metadata: + [Test Plan] - iptables -t mangle -A OUTPUT -o ns-+ -p tcp --sport 80 -j CHECKSUM - --checksum-fill + 1. Create an OpenStack deployment with DPDK options enabled and 'enable- + local-dhcp-and-metadata: true' in neutron-openvswitch. A sample, simple + 3 node bundle can be found here[1]. - It seems this setting was recently removed from the qrouter netns [0] - but it never existed in the qdhcp to begin with. + 2. Create an external flat network and subnet: - [0] https://review.opendev.org/#/c/654645/ + openstack network show dpdk_net || \ + openstack network create --provider-network-type flat \ +--provider-physical-network physnet1 dpdk_net \ +--external - Related LP Bug #1831935 - See https://bugs.launchpad.net/charm-neutron-openvswitch/+bug/1831935/comments/10 + openstack subnet show dpdk_net || \ + openstack subnet create --allocation-pool start=10.230.58.100,end=10.230.58.200 \ + --subnet-range 10.230.56.0/21 --dhcp --gateway 10.230.56.1 \ + --dns-nameserver 10.230.56.2 \ + --ip-version 4 --network dpdk_net dpdk_subnet + + + 3. Create an instance attached to that network. The instance must have a flavor that uses huge pages. + + openstack flavor create --ram 8192 --disk 50 --vcpus 4 m1.dpdk + openstack flavor set m1.dpdk --property hw:mem_page_size=large + + openstack server create --wait --image xenial --flavor m1.dpdk --key- + name testkey --network dpdk_net i1 + + 4. Log into the instance host and check the instance console. The + instance will hang into the boot and show the following message: + + 2020-11-20 09:43:26,790 - openstack.py[DEBUG]: Failed reading optional + path http://169.254.169.254/openstack/2015-10-15/user_data due to: + HTTPConnectionPool(host='169.254.169.254', port=80): Read timed out. + (read timeout=10.0) + + 5. Apply the fix in all computes, restart the DHCP agents in all + computes and create the instance again. + + 6. No errors should be shown and the instance quickly boots. + + + [Where problems could occur] + + * This change is only touched if datapath_type and ovs_use_veth. Those settings are mostly used for DPDK environments. The core of the fix is + to toggle off checksum offload done by the DHCP namespace interfaces. + This will have the drawback of adding some overhead on the packet processing for DHCP traffic but given DHCP does not demand too much data, this should be a minor proble. + + * Future changes on the syntax of the ethtool command could cause + regressions + + + [Other Info] + + * None + + + [1] https://gist.github.com/sombrafam/e0741138773e444960eb4aeace6e3e79 ** Also affects: cloud-archive 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/1832021 Title: Checksum drop of metadata traffic on isolated networks with DPDK Status in OpenStack neutron-openvswitch charm: Fix Released Status in Ubuntu Cloud Archive: New Status in neutron: Fix Released Bug description: [Impact] When an isolated network using provider networks for tenants (meaning without virtual routers: DVR or network node), metadata access occurs in the qdhcp ip netns rather than the qrouter netns. The following options are set in the dhcp_agent.ini file: force_metadata = True enable_isolated_metadata = True VMs on the provider tenant network are unable to access metadata as packets are dropped due to checksum. [Test Plan] 1. Create an OpenStack deployment with DPDK options enabled and 'enable-local-dhcp-and-metadata: true' in neutron-openvswitch. A sample, simple 3 node bundle can be found here[1]. 2. Create an external flat network and subnet: openstack network show dpdk_net || \ openstack network create --provider-network-type flat \ --provider-physical-network physnet1 dpdk_net \ --external openstack subnet show dpdk_net || \ openstack subnet create --allocation-pool start=10.230.58.100,end=10.230.58.200 \ --subnet-range 10.230.56.0/21 --dhcp --gateway 10.230.56.1 \ --dns-nameserver 10.230.56.2 \ --ip-versi
[Yahoo-eng-team] [Bug 1856175] [NEW] Horizon domain managing member dropdown menu does not work
Public bug reported: - Create an additional domain in OpenStack, and add users to this domain - Configure horizon to display the domain selector in the login screem - Set the admin contex - Go to Identity > Domains (should list all the domains) - Click the dropdown of the default domain > Manage Members[1]: Users are shown[2] - Click the dropdown of a created domain > Manage Members[3]: Users are not shown![4] [1] https://imgbbb.com/image/Le4inv [2] https://imgbbb.com/image/Le44Br [3] https://imgbbb.com/image/Le4fLU [4] https://imgbbb.com/image/Le4S3W ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1856175 Title: Horizon domain managing member dropdown menu does not work Status in OpenStack Dashboard (Horizon): New Bug description: - Create an additional domain in OpenStack, and add users to this domain - Configure horizon to display the domain selector in the login screem - Set the admin contex - Go to Identity > Domains (should list all the domains) - Click the dropdown of the default domain > Manage Members[1]: Users are shown[2] - Click the dropdown of a created domain > Manage Members[3]: Users are not shown![4] [1] https://imgbbb.com/image/Le4inv [2] https://imgbbb.com/image/Le44Br [3] https://imgbbb.com/image/Le4fLU [4] https://imgbbb.com/image/Le4S3W To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1856175/+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 1837530] [NEW] cloud-config in vendordata overriden by user-data
Public bug reported:
This may be a bug or valid behaviour, but by reading little available
vendordata documentations, I think either documentation is invalid or
at-least lacking something.
I'm trying to boot instances using config-drive and openstack dialect.
There is no Nova or metadata service involved, just plain config-drive
which happens to have user-data, vendor-data, network-data and metadata
in following hierarchy:
─── openstack
├── content
│ └── hotplug-cpu-udev.rules
└── latest
├── meta_data.json
├── network_data.json
├── user_data
└── vendor_data.json
I'm using vendor_data to supply general instructions which is shared
between every machine. It is provided by me; as infrastructure provider
not user and contains instructions to make machines works with platform
that I provide. So I think it's valid to have these general instructions
in vendor_data and let users configure their machines as their wish by
providing user_data.
The problem is whenever user_data exists, vendor_data will be erased.
Actually logs says it's processed and there will be
/var/lib/cloud/instance/vendor-cloud-config.txt but If user_data and
vendor_data both have `runcmd` for example,
/var/lib/cloud/instance/scripts/runcmd will contain just user_data
scripts.
user_data cloud-config is like:
#cloud-config
hostname: ubuntu.default
manage_etc_hosts: localhost
growpart:
mode: auto
devices:
- /
ignore_growroot_disabled: false
runcmd:
- wget http://example/img -O /tmp/img
resize_rootfs: true
ssh_pwauth: false
So my understanding is, It should not prevent vendor-data to be ran. For
the reference vendor_data.json content is:
{"cloud-init": "#cloud-config\nruncmd:\n- touch /tmp/vendor"}
So, should I change user provided user_data to allow vendor data
execution? That would be a little weird since documentation said the
other way; user_data should contain instructions to disallow vendordata
executions. And if documentation is wrong, it's sill doesn't look nice
to ask users change their cloud-config to be run properly on my
platform.
** Affects: cloud-init
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1837530
Title:
cloud-config in vendordata overriden by user-data
Status in cloud-init:
New
Bug description:
This may be a bug or valid behaviour, but by reading little available
vendordata documentations, I think either documentation is invalid or
at-least lacking something.
I'm trying to boot instances using config-drive and openstack dialect.
There is no Nova or metadata service involved, just plain config-drive
which happens to have user-data, vendor-data, network-data and
metadata in following hierarchy:
─── openstack
├── content
│ └── hotplug-cpu-udev.rules
└── latest
├── meta_data.json
├── network_data.json
├── user_data
└── vendor_data.json
I'm using vendor_data to supply general instructions which is shared
between every machine. It is provided by me; as infrastructure
provider not user and contains instructions to make machines works
with platform that I provide. So I think it's valid to have these
general instructions in vendor_data and let users configure their
machines as their wish by providing user_data.
The problem is whenever user_data exists, vendor_data will be erased.
Actually logs says it's processed and there will be
/var/lib/cloud/instance/vendor-cloud-config.txt but If user_data and
vendor_data both have `runcmd` for example,
/var/lib/cloud/instance/scripts/runcmd will contain just user_data
scripts.
user_data cloud-config is like:
#cloud-config
hostname: ubuntu.default
manage_etc_hosts: localhost
growpart:
mode: auto
devices:
- /
ignore_growroot_disabled: false
runcmd:
- wget http://example/img -O /tmp/img
resize_rootfs: true
ssh_pwauth: false
So my understanding is, It should not prevent vendor-data to be ran.
For the reference vendor_data.json content is:
{"cloud-init": "#cloud-config\nruncmd:\n- touch /tmp/vendor"}
So, should I change user provided user_data to allow vendor data
execution? That would be a little weird since documentation said the
other way; user_data should contain instructions to disallow
vendordata executions. And if documentation is wrong, it's sill
doesn't look nice to ask users change their cloud-config to be run
properly on my platform.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1837530/+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 1818859] [NEW] neutron functional job intermittent failures with ovsdbapp.backend.ovs_idl.idlutils.RowNotFound
Public bug reported: It appears the neutron functional job started failing with errors related to: ovsdbapp.backend.ovs_idl.idlutils.RowNotFound For example [1][2]. Based on logstash [3] it looks like this issue may have cropped up around March 5th. [1] http://logs.openstack.org/34/639034/7/check/neutron-functional/d32644a/job-output.txt.gz [2] http://logs.openstack.org/04/637004/2/check/neutron-functional-python27/5dd04c3/job-output.txt.gz#_2019-03-06_13_27_21_193728 [3] http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22ovsdbapp.backend.ovs_idl.idlutils.RowNotFound%3A%20Cannot%20find%20Port%20with%20name%3D%5C%22 ** Affects: neutron Importance: Undecided Status: New ** Tags: gate-failure -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1818859 Title: neutron functional job intermittent failures with ovsdbapp.backend.ovs_idl.idlutils.RowNotFound Status in neutron: New Bug description: It appears the neutron functional job started failing with errors related to: ovsdbapp.backend.ovs_idl.idlutils.RowNotFound For example [1][2]. Based on logstash [3] it looks like this issue may have cropped up around March 5th. [1] http://logs.openstack.org/34/639034/7/check/neutron-functional/d32644a/job-output.txt.gz [2] http://logs.openstack.org/04/637004/2/check/neutron-functional-python27/5dd04c3/job-output.txt.gz#_2019-03-06_13_27_21_193728 [3] http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22ovsdbapp.backend.ovs_idl.idlutils.RowNotFound%3A%20Cannot%20find%20Port%20with%20name%3D%5C%22 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1818859/+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 1815827] [NEW] [RFE] neutron-lib: rehome neutron.object.base along with rbac db/objects
Public bug reported: This isn't a request for a new feature per say, but rather a placeholder for the neutron drivers team to take a look at [1]. Specifically I'm hoping for drivers team agreement that the modules/functionality being rehomed in [1] makes sense; no actual (deep) code review of [1] is necessary at this point. Assuming we can agree that the logic in [1] makes sense to rehome, I can proceed by chunking it up into smaller patches that will make the rehome/consume process easier. This work is part of [2] that's described in [3][4]. However as commented in [1], it's also necessary to rehome the rbac db/objects modules and their dependencies that weren't discussed previously. [1] https://review.openstack.org/#/c/621000 [2] https://blueprints.launchpad.net/neutron/+spec/neutron-lib-decouple-db [3] https://specs.openstack.org/openstack/neutron-specs/specs/rocky/neutronlib-decouple-db-apiutils.html [4] https://specs.openstack.org/openstack/neutron-specs/specs/rocky/neutronlib-decouple-models.html ** Affects: neutron Importance: Undecided Status: New ** Tags: rfe -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1815827 Title: [RFE] neutron-lib: rehome neutron.object.base along with rbac db/objects Status in neutron: New Bug description: This isn't a request for a new feature per say, but rather a placeholder for the neutron drivers team to take a look at [1]. Specifically I'm hoping for drivers team agreement that the modules/functionality being rehomed in [1] makes sense; no actual (deep) code review of [1] is necessary at this point. Assuming we can agree that the logic in [1] makes sense to rehome, I can proceed by chunking it up into smaller patches that will make the rehome/consume process easier. This work is part of [2] that's described in [3][4]. However as commented in [1], it's also necessary to rehome the rbac db/objects modules and their dependencies that weren't discussed previously. [1] https://review.openstack.org/#/c/621000 [2] https://blueprints.launchpad.net/neutron/+spec/neutron-lib-decouple-db [3] https://specs.openstack.org/openstack/neutron-specs/specs/rocky/neutronlib-decouple-db-apiutils.html [4] https://specs.openstack.org/openstack/neutron-specs/specs/rocky/neutronlib-decouple-models.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1815827/+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 1815142] [NEW] ovsdbapp.exceptions.TimeoutException in functional tests
Public bug reported: It appears that as of recent we've been getting some OVS timeouts in various functional jobs [1]. One example is [2] that has a exception message with: ovsdbapp.exceptions.TimeoutException: Commands [, , ] exceeded timeout 10 seconds Based on the logstash query [1] it appears this occasionally impacts functional jobs for neutron and networking-ovn. [1] http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%20%5C%22ovsdbapp.exceptions.TimeoutException%3A%20Commands%5C%22 [2] http://logs.openstack.org/83/633283/2/check/neutron-functional-python27/48c9c98/job-output.txt.gz#_2019-02-07_12_36_06_518870 ** Affects: neutron Importance: Undecided Status: New ** Tags: gate-failure -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1815142 Title: ovsdbapp.exceptions.TimeoutException in functional tests Status in neutron: New Bug description: It appears that as of recent we've been getting some OVS timeouts in various functional jobs [1]. One example is [2] that has a exception message with: ovsdbapp.exceptions.TimeoutException: Commands [, , ] exceeded timeout 10 seconds Based on the logstash query [1] it appears this occasionally impacts functional jobs for neutron and networking-ovn. [1] http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%20%5C%22ovsdbapp.exceptions.TimeoutException%3A%20Commands%5C%22 [2] http://logs.openstack.org/83/633283/2/check/neutron-functional-python27/48c9c98/job-output.txt.gz#_2019-02-07_12_36_06_518870 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1815142/+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 1811238] Re: Install and configure controller node in neutron (manual) - Prerequisites
Best I can tell the docs already all do use -u and -p option [1]. If there's something else that's needed please reopen/clarify. [1] http://codesearch.openstack.org/?q=mysql&i=nope&files=doc&repos=neutron ** Changed in: neutron Assignee: (unassigned) => Boden R (boden) ** Changed in: neutron Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1811238 Title: Install and configure controller node in neutron (manual) - Prerequisites Status in neutron: Invalid Bug description: - [X] This doc is inaccurate in this way: In section 1 the command: # mysql should be: # mysql -u root -p for reference check: https://docs.openstack.org/nova/rocky/install/controller-install-rdo.html --- Release: 13.0.3.dev26 on 2019-01-04 17:45 SHA: 025e767b94cf29e522a67e3c1ddd8aa3dba9140a Source: https://git.openstack.org/cgit/openstack/neutron/tree/doc/source/install/controller-install-rdo.rst URL: https://docs.openstack.org/neutron/rocky/install/controller-install-rdo.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1811238/+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 1811126] [NEW] DHCPAgentOVSTestCase.test_stale_metadata_proxy_killed fails with RuntimeError: Stale metadata proxy didn't get killed
Public bug reported: Functional gate test(s) have been failing intermittently with the following exception: RuntimeError: Stale metadata proxy didn't get killed The logstash query in [1] shows the frequency of the error. The log in [2] shows a sample neutron-functional failure with the error. [1] http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22Stale%20metadata%20proxy%20didn't%20get%20killed%5C%22 [2] http://logs.openstack.org/57/628057/2/gate/neutron-functional/a8cf0a4/job-output.txt.gz#_2019-01-09_15_55_25_562145 ** Affects: neutron Importance: Undecided Status: Triaged ** Tags: gate-failure ** Tags added: gate-failure ** Changed in: neutron Status: New => Triaged -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1811126 Title: DHCPAgentOVSTestCase.test_stale_metadata_proxy_killed fails with RuntimeError: Stale metadata proxy didn't get killed Status in neutron: Triaged Bug description: Functional gate test(s) have been failing intermittently with the following exception: RuntimeError: Stale metadata proxy didn't get killed The logstash query in [1] shows the frequency of the error. The log in [2] shows a sample neutron-functional failure with the error. [1] http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22Stale%20metadata%20proxy%20didn't%20get%20killed%5C%22 [2] http://logs.openstack.org/57/628057/2/gate/neutron-functional/a8cf0a4/job-output.txt.gz#_2019-01-09_15_55_25_562145 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1811126/+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 1810314] [NEW] neutron objects base get_values() fails with KeyError
Public bug reported: As of December 20 2018 the python unit test jobs for the tricircle project have been failing [1]. After going through the tricircle/neutron commits since that date, it seems some changes went into neutron that caused the breakage. If I run tricircle python 3.5 unit test with neutron commit 55c5139d79ef09869eea1201c736eee8de3ec651 (the last commit on neutron from Dec 19, 2018) the unit tests all pass. If I run the same UTs with neutron (latest) master they fail with the same errors found in the results of [2]. While this is just a guess, I suspect that maybe neutron changes that landed on Dec 20 related to "Convert Subnet to OVO in ipam_pluggable_backend.py" [3] introduced the breakage. In any case, something landed in neutron around Dec 20, 2018 that has broken tricircle. [1] http://zuul.openstack.org/builds?branch=master&project=openstack%2Ftricircle&job_name=openstack-tox-py35 [2] https://review.openstack.org/#/c/627888/ [3] https://review.openstack.org/#/c/610184/ ** Affects: neutron Importance: Undecided Status: New ** Affects: tricircle Importance: Undecided Status: New ** Also affects: tricircle 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/1810314 Title: neutron objects base get_values() fails with KeyError Status in neutron: New Status in Tricircle: New Bug description: As of December 20 2018 the python unit test jobs for the tricircle project have been failing [1]. After going through the tricircle/neutron commits since that date, it seems some changes went into neutron that caused the breakage. If I run tricircle python 3.5 unit test with neutron commit 55c5139d79ef09869eea1201c736eee8de3ec651 (the last commit on neutron from Dec 19, 2018) the unit tests all pass. If I run the same UTs with neutron (latest) master they fail with the same errors found in the results of [2]. While this is just a guess, I suspect that maybe neutron changes that landed on Dec 20 related to "Convert Subnet to OVO in ipam_pluggable_backend.py" [3] introduced the breakage. In any case, something landed in neutron around Dec 20, 2018 that has broken tricircle. [1] http://zuul.openstack.org/builds?branch=master&project=openstack%2Ftricircle&job_name=openstack-tox-py35 [2] https://review.openstack.org/#/c/627888/ [3] https://review.openstack.org/#/c/610184/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1810314/+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 1787420] [NEW] Floating ip association to router interface should be restricted
Public bug reported:
We found this bug using the vmware-nsx plugin, but should be applicable
to all plugins support L3.
Created devstack_master + vmware-nsx
Created router-interface and assigned fip's to router interface which is
allowed.
I dont find any usecase to assign ip to router port other than its LB vip port.
Main reason for restricted this:
-> To remove unwanted entries of fip from neutron db.
-> To reduce overhead of using floating ip pool (other pool may get exhausted).
REPO STEPS:
myuser@kvm-compute-node1:~/devstack$ neutron router-port-list rtr3
neutron CLI is deprecated and will be removed in the future. Use openstack CLI
instead.
+--+--+--+---++
| id | name | tenant_id
| mac_address | fixed_ips
|
+--+--+--+---++
| 3318efcd-fcd1-4dda-bdde-4c8a19fbee3a | |
| fa:16:3e:c1:00:fd | {"subnet_id": "afb2f79d-3c25-47de-a273-27bab2b78800",
"ip_address": "172.24.0.19"} |
| 8fcda443-dd4d-431f-ba3d-fbd5764830d9 | |
00b7a6f394e946688c83545da6a27804 | fa:16:3e:9a:a1:3e | {"subnet_id":
"7ff038d6-3b3c-4127-a45a-f135ac07f3bb", "ip_address": "3.0.100.1"} |
| f6d54233-a8aa-4304-bc16-20f0071dfc47 | |
00b7a6f394e946688c83545da6a27804 | fa:16:3e:99:35:61 | {"subnet_id":
"c16dce8d-899e-45f7-b615-557c2e231ce5", "ip_address": "3.3.100.1"} |
+--+--+--+---++
myuser@kvm-compute-node1:~/devstack$ neutron port-show
8fcda443-dd4d-431f-ba3d-fbd5764830d9
neutron CLI is deprecated and will be removed in the future. Use openstack CLI
instead.
+--+--+
| Field| Value
|
+--+--+
| admin_state_up | True
|
| allowed_address_pairs|
|
| binding:host_id |
|
| binding:vif_details | {"ovs_hybrid_plug": false,
"nsx-logical-switch-id": "c1a562e9-54bd-4ca6-9071-d622155e7ee6", "port_filter":
true} |
| binding:vif_type | ovs
|
| binding:vnic_type| normal
|
| created_at | 2018-08-13T16:19:11Z
|
| description |
|
| device_id| 0fa3bbcd-2a24-4c1d-ba56-d7e2c88a60ba
|
| device_owner | network:router_interface
|
| dns_assignment | {"hostname": "host-3-0-100-1", "ip_address":
"3.0.100.1", "fqdn": "host-3-0-100-1.somedom.org."} |
| dns_name |
|
| extra_dhcp_opts |
|
| fixed_ips| {"subnet_id":
"7ff038d6-3b3c-4127-a45a-f135ac07f3bb", "ip_address": "3.0.100.1"}
|
| id | 8fcda443-dd4d-431f-ba3d-fbd5764830d9
|
| mac_address | fa:16:3e:9a:a1:3e
|
| name |
[Yahoo-eng-team] [Bug 1780011] [NEW] OSA Queens: libvirtError: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory
Public bug reported: I have installed stable/queens 17.0.5 using openstack-ansible on Ubuntu with ODL. When i reboot compute node, instances go in shut off state. Log in /var/log/nova/nova-compute.log: 2018-07-04 10:00:58.496 5519 ERROR nova.virt.libvirt.host libvirtError: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory If power fluctuates compute will go down and i have to restart nova- compute on compute node and start all instances. Is there a fix for this issue? Status of services after reboot: root@home:~# service libvirtd status ● libvirtd.service - Virtualization daemon Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2018-07-04 10:02:56 IST; 25s ago Docs: man:libvirtd(8) https://libvirt.org Main PID: 5809 (libvirtd) Tasks: 17 (limit: 32768) Memory: 25.0M CPU: 385ms CGroup: /system.slice/libvirtd.service └─5809 /usr/sbin/libvirtd Jul 04 10:02:54 home systemd[1]: Starting Virtualization daemon... Jul 04 10:02:56 home systemd[1]: Started Virtualization daemon. root@home:~# service nova-compute status ● nova-compute.service - nova openstack service Loaded: loaded (/etc/systemd/system/nova-compute.service; enabled; vendor preset: enabled) Active: inactive (dead) since Wed 2018-07-04 10:00:58 IST; 2min 30s ago Process: 5519 ExecStart=/openstack/venvs/nova-17.0.5/bin/nova-compute --log-file=/var/log/nova/nova-compute.log (code=exited, status=0/SUCCESS) Main PID: 5519 (code=exited, status=0/SUCCESS) Jul 04 10:00:53 home systemd[1]: Started nova openstack service. Jul 04 10:00:56 home nova-compute[5519]: /openstack/venvs/nova-17.0.5/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py:332: NotSupport Jul 04 10:00:56 home nova-compute[5519]: exception.NotSupportedWarning ** Affects: nova Importance: Undecided Status: New ** Affects: openstack-ansible Importance: Undecided Status: New ** Tags: nova ** Also affects: nova Importance: Undecided Status: New ** Summary changed: - libvirtError: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory + OSA Queens: libvirtError: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory -- 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/1780011 Title: OSA Queens: libvirtError: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory Status in OpenStack Compute (nova): New Status in openstack-ansible: New Bug description: I have installed stable/queens 17.0.5 using openstack-ansible on Ubuntu with ODL. When i reboot compute node, instances go in shut off state. Log in /var/log/nova/nova-compute.log: 2018-07-04 10:00:58.496 5519 ERROR nova.virt.libvirt.host libvirtError: Failed to connect socket to '/var/run/libvirt/libvirt- sock': No such file or directory If power fluctuates compute will go down and i have to restart nova- compute on compute node and start all instances. Is there a fix for this issue? Status of services after reboot: root@home:~# service libvirtd status ● libvirtd.service - Virtualization daemon Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2018-07-04 10:02:56 IST; 25s ago Docs: man:libvirtd(8) https://libvirt.org Main PID: 5809 (libvirtd) Tasks: 17 (limit: 32768) Memory: 25.0M CPU: 385ms CGroup: /system.slice/libvirtd.service └─5809 /usr/sbin/libvirtd Jul 04 10:02:54 home systemd[1]: Starting Virtualization daemon... Jul 04 10:02:56 home systemd[1]: Started Virtualization daemon. root@home:~# service nova-compute status ● nova-compute.service - nova openstack service Loaded: loaded (/etc/systemd/system/nova-compute.service; enabled; vendor preset: enabled) Active: inactive (dead) since Wed 2018-07-04 10:00:58 IST; 2min 30s ago Process: 5519 ExecStart=/openstack/venvs/nova-17.0.5/bin/nova-compute --log-file=/var/log/nova/nova-compute.log (code=exited, status=0/SUCCESS) Main PID: 5519 (code=exited, status=0/SUCCESS) Jul 04 10:00:53 home systemd[1]: Started nova openstack service. Jul 04 10:00:56 home nova-compute[5519]: /openstack/venvs/nova-17.0.5/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py:332: NotSupport Jul 04 10:00:56 home nova-compute[5519]: exception.NotSupportedWarning To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1780011/+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 : ht
[Yahoo-eng-team] [Bug 1779334] [NEW] neutron-vpnaas doesn't support local tox targets
Public bug reported: Today it appears the neutron-vpnaas doesn't support proper env setup for running tox targets locally. For more details see [1]. [1] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131801.html ** Affects: neutron Importance: Undecided Status: New ** Tags: vpnaas -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1779334 Title: neutron-vpnaas doesn't support local tox targets Status in neutron: New Bug description: Today it appears the neutron-vpnaas doesn't support proper env setup for running tox targets locally. For more details see [1]. [1] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131801.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1779334/+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 1779335] [NEW] neutron-vpnaas doesn't support local tox targets
Public bug reported: Today it appears the neutron-vpnaas doesn't support proper env setup for running tox targets locally. For more details see [1]. [1] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131801.html ** Affects: neutron Importance: Undecided Assignee: Boden R (boden) Status: In Progress ** Tags: vpnaas -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1779335 Title: neutron-vpnaas doesn't support local tox targets Status in neutron: In Progress Bug description: Today it appears the neutron-vpnaas doesn't support proper env setup for running tox targets locally. For more details see [1]. [1] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131801.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1779335/+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 1778771] [NEW] Backups panel is visible even if enable_backup is False
Public bug reported:
Hi,
Volumes - Backup panel is visible even if OPENSTACK_CINDER_FEATURES =
{'enable_backup': False} in local_settings.py
Meanwhile setting enable_backup to false removes an option to create
backup of a volume in the volume drop-down options. But panel with
backups itself stays visible for both admins and users.
As a work-around I use the following customization script:
import horizon
from django.conf import settings
if not getattr(settings, 'OPENSTACK_CINDER_FEATURES', {}).get('enable_backup',
False):
project = horizon.get_dashboard("project")
backup = project.get_panel("backups")
project.unregister(backup.__class__)
And for permanent fix I see the following decision. In
openstack_dashboard/dashboards/project/backups/panel.py make the following
changes:
...
+L16: from django.conf import settings
...
+L21: if not getattr(settings, 'OPENSTACK_CINDER_FEATURES',
{}).get('enable_backup', False):
+L22: return False
...
** Affects: horizon
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1778771
Title:
Backups panel is visible even if enable_backup is False
Status in OpenStack Dashboard (Horizon):
New
Bug description:
Hi,
Volumes - Backup panel is visible even if OPENSTACK_CINDER_FEATURES =
{'enable_backup': False} in local_settings.py
Meanwhile setting enable_backup to false removes an option to create
backup of a volume in the volume drop-down options. But panel with
backups itself stays visible for both admins and users.
As a work-around I use the following customization script:
import horizon
from django.conf import settings
if not getattr(settings, 'OPENSTACK_CINDER_FEATURES',
{}).get('enable_backup', False):
project = horizon.get_dashboard("project")
backup = project.get_panel("backups")
project.unregister(backup.__class__)
And for permanent fix I see the following decision. In
openstack_dashboard/dashboards/project/backups/panel.py make the following
changes:
...
+L16: from django.conf import settings
...
+L21: if not getattr(settings, 'OPENSTACK_CINDER_FEATURES',
{}).get('enable_backup', False):
+L22: return False
...
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1778771/+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 1778714] [NEW] neutron-rally-neutron fails with `NeutronTrunks.create_and_list_trunk_subports` in in any platform
Public bug reported: It appears the neutron-rally-neutron job is failing intermittently with: 2018-06-25 21:27:31.654 4361 ERROR rally.task.engine [-] Invalid Task: PluginNotFound: There is no plugin `NeutronTrunks.create_and_list_trunk_subports` in in any platform. For example [1] (stable/queens). It appears to have started happening around 6/22/2018 as per [2]. [1] http://logs.openstack.org/13/577513/1/check/neutron-rally-neutron/beff1fe/job-output.txt.gz#_2018-06-25_21_27_31_744987 [2] http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22%60NeutronTrunks.create_and_list_trunk_subports%60%20in%20in%20any%20platform%5C%22 ** Affects: neutron Importance: Undecided Status: New ** Tags: gate-failure ** Description changed: It appears the neutron-rally-neutron job is failing intermittently with: 2018-06-25 21:27:31.654 4361 ERROR rally.task.engine [-] Invalid Task: PluginNotFound: There is no plugin `NeutronTrunks.create_and_list_trunk_subports` in in any platform. - For example [1] (stable/queens). It appears to have started happening around 6/22/2018 as per [2]. - - [1] http://logs.openstack.org/13/577513/1/check/neutron-rally-neutron/beff1fe/job-output.txt.gz + [1] http://logs.openstack.org/13/577513/1/check/neutron-rally-neutron/beff1fe/job-output.txt.gz#_2018-06-25_21_27_31_744987 [2] http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22%60NeutronTrunks.create_and_list_trunk_subports%60%20in%20in%20any%20platform%5C%22 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1778714 Title: neutron-rally-neutron fails with `NeutronTrunks.create_and_list_trunk_subports` in in any platform Status in neutron: New Bug description: It appears the neutron-rally-neutron job is failing intermittently with: 2018-06-25 21:27:31.654 4361 ERROR rally.task.engine [-] Invalid Task: PluginNotFound: There is no plugin `NeutronTrunks.create_and_list_trunk_subports` in in any platform. For example [1] (stable/queens). It appears to have started happening around 6/22/2018 as per [2]. [1] http://logs.openstack.org/13/577513/1/check/neutron-rally-neutron/beff1fe/job-output.txt.gz#_2018-06-25_21_27_31_744987 [2] http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22%60NeutronTrunks.create_and_list_trunk_subports%60%20in%20in%20any%20platform%5C%22 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1778714/+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 1750353] Re: _get_changed_synthetic_fields() does not guarantee returned fields to be updatable
** Changed in: neutron
Status: Fix Released => In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1750353
Title:
_get_changed_synthetic_fields() does not guarantee returned fields to
be updatable
Status in neutron:
In Progress
Bug description:
While revising [1], I discovered an issue of
_get_changed_synthetic_fields(): it does not guarantee returned fields
to be updatable.
How to reproduce:
Set a breakpoint in [2] and then run
neutron.tests.unit.objects.test_ports.DistributedPortBindingIfaceObjTestCase.test_update_updates_from_db_object,
the returned fields are
-> return fields
(Pdb) fields
{'host': u'c2753a12ec', 'port_id': 'ae5700cd-f872-4694-bf36-92b919b0d3bf'}
where 'host' and 'port_id' are not updatable.
[1] https://review.openstack.org/#/c/544206/
[2]
https://github.com/openstack/neutron/blob/master/neutron/objects/base.py#L696
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1750353/+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 1777908] [NEW] Ensure _get_changed_synthetic_fields() return updatable fields - breaks consumers
Public bug reported:
It appears the landing of [1] into stable/queens has broken some
consumers, at least vmware-nsx.
When running with [1] in neutron/queens, we now get:
security_group_rule is already registered
Loaded quota_driver: .
Loaded quota_driver: .
create failed: No details.: DetachedInstanceError: Parent instance
is not bound to a Session; lazy load
operation of attribute 'ext_properties' cannot proceed (Background on this
error at: http://sqlalche.me/e/bhk3)
Traceback (most recent call last):
File
"/home/boden/src/vmware-nsx/.tox/py27-dev/src/neutron/neutron/api/v2/resource.py",
line 98, in resource
result = method(request=request, **args)
File
"/home/boden/src/vmware-nsx/.tox/py27-dev/src/neutron/neutron/api/v2/base.py",
line 425, in create
return self._create(request, body, **kwargs)
File
"/home/boden/src/vmware-nsx/.tox/py27-dev/src/neutron/neutron/db/api.py", line
91, in wrapped
setattr(e, '_RETRY_EXCEEDED', True)
File
"/home/boden/src/vmware-nsx/.tox/py27-dev/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 220, in __exit__
self.force_reraise()
File
"/home/boden/src/vmware-nsx/.tox/py27-dev/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 196, in force_reraise
six.reraise(self.type_, self.value, self.tb)
File
"/home/boden/src/vmware-nsx/.tox/py27-dev/src/neutron/neutron/db/api.py", line
87, in wrapped
return f(*args, **kwargs)
File
"/home/boden/src/vmware-nsx/.tox/py27-dev/local/lib/python2.7/site-packages/oslo_db/api.py",
line 154, in wrapper
ectxt.value = e.inner_exc
File
"/home/boden/src/vmware-nsx/.tox/py27-dev/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 220, in __exit__
self.force_reraise()
File
"/home/boden/src/vmware-nsx/.tox/py27-dev/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 196, in force_reraise
six.reraise(self.type_, self.value, self.tb)
File
"/home/boden/src/vmware-nsx/.tox/py27-dev/local/lib/python2.7/site-packages/oslo_db/api.py",
line 142, in wrapper
return f(*args, **kwargs)
File
"/home/boden/src/vmware-nsx/.tox/py27-dev/src/neutron/neutron/db/api.py", line
126, in wrapped
LOG.debug("Retry wrapper got retriable exception: %s", e)
File
"/home/boden/src/vmware-nsx/.tox/py27-dev/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 220, in __exit__
self.force_reraise()
File
"/home/boden/src/vmware-nsx/.tox/py27-dev/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 196, in force_reraise
six.reraise(self.type_, self.value, self.tb)
File
"/home/boden/src/vmware-nsx/.tox/py27-dev/src/neutron/neutron/db/api.py", line
122, in wrapped
return f(*dup_args, **dup_kwargs)
File
"/home/boden/src/vmware-nsx/.tox/py27-dev/src/neutron/neutron/api/v2/base.py",
line 539, in _create
obj = do_create(body)
File
"/home/boden/src/vmware-nsx/.tox/py27-dev/src/neutron/neutron/api/v2/base.py",
line 521, in do_create
request.context, reservation.reservation_id)
File
"/home/boden/src/vmware-nsx/.tox/py27-dev/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 220, in __exit__
self.force_reraise()
File
"/home/boden/src/vmware-nsx/.tox/py27-dev/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 196, in force_reraise
six.reraise(self.type_, self.value, self.tb)
File
"/home/boden/src/vmware-nsx/.tox/py27-dev/src/neutron/neutron/api/v2/base.py",
line 514, in do_create
return obj_creator(request.context, **kwargs)
File "vmware_nsx/tests/unit/extensions/test_provider_security_groups.py",
line 53, in create_security_group
context, security_group)
File "vmware_nsx/db/extended_security_group.py", line 77, in
create_provider_security_group
context, security_group, False, True)
File "vmware_nsx/db/extended_security_group.py", line 107, in
create_security_group_without_rules
secgroup_dict = self._make_security_group_dict(sg)
File
"/home/boden/src/vmware-nsx/.tox/py27-dev/src/neutron/neutron/db/securitygroups_db.py",
line 280, in _make_security_group_dict
security_group.db_obj)
File
"/home/boden/src/vmware-nsx/.tox/py27-dev/src/neutron/neutron/db/_resource_extend.py",
line 75, in apply_funcs
resolved_func(response, db_object)
File "vmware_nsx/db/extended_security_group.py", line 348, in
_extend_security_group_with_properties
if sg_db.ext_properties:
File
"/home/boden/src/vmware-nsx/.tox/py27-dev/local/lib/python2.7/site-packages/sqlalchemy/orm/attributes.py",
line 242, in __get__
return self.impl.get(instance_state(instance), dict_)
File
"/home/boden/src/vmware-nsx/.tox/py27-dev/local/lib/python2.7/site-packages/sqlalchemy/orm/attributes.py",
line 599, in get
value = self.callable_(state, passive)
File
"/home/boden/src/vmware-nsx/.tox/py27-dev/local/lib/python2.7/site-packages/sqlalchemy/orm/strategies.py",
line 596, in _load_for_state
(orm_util.state_str(state), self.key)
[Yahoo-eng-team] [Bug 1777123] [NEW] Nova 17.04 fails to create ephemeral storage with rbd driver
Public bug reported: Description === Nova-compute is unable to create ephemeral storage due to type error, as it sends unicode object to rbd.Image() class as a storage name. Meanwhile, rbd.Image() accepts only string value. Steps to reproduce == Try to create an instance without cinder drive or with flavor which has a swap defined. Also, nova-compute should be configured to interact with ceph. Steps to fix the problem == in nova/virt/libvirt/storage/rbd_utils.py make the following changes: - L69: self.volume = tpool.Proxy(rbd.Image(ioctx, name, + L69: self.volume = tpool.Proxy(rbd.Image(ioctx, str(name), Expected result === Instance should be created with swap storage and/or with ephemeral drive in ceph. Actual result = Instance creation fails with: Exceeded maximum number of retries. Exhausted all hosts available for retrying build failures for instance bdd019bd-4127-4186-a1ee-f4b1891e1730. File "/openstack/venvs/nova-17.0.5/lib/python2.7/site-packages/nova/conductor/manager.py", line 580, in build_instances raise exception.MaxRetriesExceeded(reason=msg) Environment === 1. I've installed openstack with OSA (OpenStack-Ansible) version 17.0.5. So it would be openstack queens version (nova-17.0.5) root@uacloud-nova01:~# pip freeze | grep nova nova==17.0.4 nova-lxd==17.0.0 nova-powervm==6.0.2.dev3 python-novaclient==9.1.1 (nova-17.0.5) root@uacloud-nova01:~# 2. KVM hypervisor 3. CEPH storage 4. Neutron networking Logs & Configs == In logs I see the following error: 2018-06-15 14:38:56.904 13411 INFO nova.compute.claims [req-b7277d7c-14b6-4f0c-97fb-bb29a6c379a5 cf35f21e050d462db0e0ecf20da2a9de d605898aeb654bfea6e18c3c0321d8a8 - 309afdf3dd6242338cd5eb4cda07f1d9 309afdf3dd6242338cd5eb4cda07f1d9] [instance: bdd019bd-4127-4186-a1ee-f4b1891e1730] vcpu limit: 320.00 VCPU, free: 311.00 VCPU 2018-06-15 14:38:56.909 13411 INFO nova.compute.claims [req-b7277d7c-14b6-4f0c-97fb-bb29a6c379a5 cf35f21e050d462db0e0ecf20da2a9de d605898aeb654bfea6e18c3c0321d8a8 - 309afdf3dd6242338cd5eb4cda07f1d9 309afdf3dd6242338cd5eb4cda07f1d9] [instance: bdd019bd-4127-4186-a1ee-f4b1891e1730] Claim successful on node uacloud-nova01.twinservers.net 2018-06-15 14:38:57.837 13411 INFO nova.virt.libvirt.driver [req-b7277d7c-14b6-4f0c-97fb-bb29a6c379a5 cf35f21e050d462db0e0ecf20da2a9de d605898aeb654bfea6e18c3c0321d8a8 - 309afdf3dd6242338cd5eb4cda07f1d9 309afdf3dd6242338cd5eb4cda07f1d9] [instance: bdd019bd-4127-4186-a1ee-f4b1891e1730] Creating image 2018-06-15 14:38:57.899 13411 ERROR nova.compute.manager [req-b7277d7c-14b6-4f0c-97fb-bb29a6c379a5 cf35f21e050d462db0e0ecf20da2a9de d605898aeb654bfea6e18c3c0321d8a8 - 309afdf3dd6242338cd5eb4cda07f1d9 309afdf3dd6242338cd5eb4cda07f1d9] [instance: bdd019bd-4127-4186-a1ee-f4b1891e1730] Instance failed to spawn: TypeError: name must be a string 2018-06-15 14:38:57.899 13411 ERROR nova.compute.manager [instance: bdd019bd-4127-4186-a1ee-f4b1891e1730] Traceback (most recent call last): 2018-06-15 14:38:57.899 13411 ERROR nova.compute.manager [instance: bdd019bd-4127-4186-a1ee-f4b1891e1730] File "/openstack/venvs/nova-17.0.5/lib/python2.7/site-packages/nova/compute/manager.py", line 2248, in _build_resources 2018-06-15 14:38:57.899 13411 ERROR nova.compute.manager [instance: bdd019bd-4127-4186-a1ee-f4b1891e1730] yield resources 2018-06-15 14:38:57.899 13411 ERROR nova.compute.manager [instance: bdd019bd-4127-4186-a1ee-f4b1891e1730] File "/openstack/venvs/nova-17.0.5/lib/python2.7/site-packages/nova/compute/manager.py", line 2031, in _build_and_run_instance 2018-06-15 14:38:57.899 13411 ERROR nova.compute.manager [instance: bdd019bd-4127-4186-a1ee-f4b1891e1730] block_device_info=block_device_info) 2018-06-15 14:38:57.899 13411 ERROR nova.compute.manager [instance: bdd019bd-4127-4186-a1ee-f4b1891e1730] File "/openstack/venvs/nova-17.0.5/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 3072, in spawn 2018-06-15 14:38:57.899 13411 ERROR nova.compute.manager [instance: bdd019bd-4127-4186-a1ee-f4b1891e1730] block_device_info=block_device_info) 2018-06-15 14:38:57.899 13411 ERROR nova.compute.manager [instance: bdd019bd-4127-4186-a1ee-f4b1891e1730] File "/openstack/venvs/nova-17.0.5/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 3450, in _create_image 2018-06-15 14:38:57.899 13411 ERROR nova.compute.manager [instance: bdd019bd-4127-4186-a1ee-f4b1891e1730] fallback_from_host) 2018-06-15 14:38:57.899 13411 ERROR nova.compute.manager [instance: bdd019bd-4127-4186-a1ee-f4b1891e1730] File "/openstack/venvs/nova-17.0.5/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 3541, in _create_and_inject_local_root 2018-06-15 14:38:57.899 13411 ERROR nova.compute.manager [instance: bdd019bd-4127-4186-a1ee-f4b1891e1730] instance, size, fallback_from_host) 2018-06-15 14:38:57.899 13411 ERROR nova.compute.manager [instance:
[Yahoo-eng-team] [Bug 1405057] Re: Filter port-list based on security_groups associated not working
Reopening. It appears this work was never completed; the api def never
made it into neutron-lib and was consumed, so I'll do that.
** Changed in: neutron
Status: Fix Released => In Progress
** Changed in: neutron
Assignee: Ahmed Zaid (ahmedzaid10) => Boden R (boden)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1405057
Title:
Filter port-list based on security_groups associated not working
Status in neutron:
In Progress
Bug description:
Sample Usecases:
1. neutron port-list --security_groups=6f3d9d9d-e84d-437c-ac40-82ce3196230c
Invalid input for operation: '6' is not an integer or uuid.
2.neutron port-list --security_groups list=true
6f3d9d9d-e84d-437c-ac40-82ce3196230c
Invalid input for operation: '6' is not an integer or uuid.
Since, security_groups associated to a port are referenced from
securitygroups db table, we cant just filter ports
based on security_groups directly as it works for other paramters.
Example:
neutron port-list --mac_address list=true fa:16:3e:40:2b:cc fa:16:3e:8e:32:3e
+--+--+---+---+
| id | name | mac_address | fixed_ips
|
+--+--+---+---+
| 1cecec78-226f-4379-b5ad-c145e2e14048 | | fa:16:3e:40:2b:cc |
{"subnet_id": "af938c1c-e2d7-47a0-954a-ec8524677486", "ip_address":
"50.10.10.2"} |
| eec24494-09a8-4fa8-885d-e3fda37fe756 | | fa:16:3e:8e:32:3e |
{"subnet_id": "af938c1c-e2d7-47a0-954a-ec8524677486", "ip_address":
"50.10.10.3"} |
+--+--+---+---+
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1405057/+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 1771088] [NEW] Admin user is not able to update the shared access for a network.
Public bug reported: Admin user is not able to update the shared access for a network. Steps to reproduce: a) Create a network test from demo user. b) As an admin user, create a subnet for that network. c) Now, make the network shared using command “neutron net-update test –shared”. d) Now, try to make the shared as false for the same network by using the command “neutron net-update test –shared false”. Here it throws an error saying "unable to reconfigure sharing settings for network test. Multiple tenants are using it." ** 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/1771088 Title: Admin user is not able to update the shared access for a network. Status in neutron: New Bug description: Admin user is not able to update the shared access for a network. Steps to reproduce: a) Create a network test from demo user. b) As an admin user, create a subnet for that network. c) Now, make the network shared using command “neutron net-update test –shared”. d) Now, try to make the shared as false for the same network by using the command “neutron net-update test –shared false”. Here it throws an error saying "unable to reconfigure sharing settings for network test. Multiple tenants are using it." To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1771088/+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 1765024] [NEW] requires_keypair does not affect NG interface
Public bug reported: Hi, Setting "'requires_keypair': True" in OPENSTACK_HYPERVISOR_FEATURES does not affect new server creation form (angular one). So it is impossible to make key_pair as a required field now with this setting. Meanwhile this approach still works in the legacy form. It is reproduced in environments with horizon versions 13.0.0 and 12.0.2 ** Affects: horizon Importance: Undecided Status: New ** Tags: angularjs pike queens -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1765024 Title: requires_keypair does not affect NG interface Status in OpenStack Dashboard (Horizon): New Bug description: Hi, Setting "'requires_keypair': True" in OPENSTACK_HYPERVISOR_FEATURES does not affect new server creation form (angular one). So it is impossible to make key_pair as a required field now with this setting. Meanwhile this approach still works in the legacy form. It is reproduced in environments with horizon versions 13.0.0 and 12.0.2 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1765024/+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 1762732] [NEW] l3agentscheduler doesn't return a response body with POST /v2.0/agents/{agent_id}/l3-routers
Public bug reported:
As discussed in [1], the
POST /v2.0/agents/{agent_id}/l3-routers
does not return a response body. This seems inconsistent with our other
APIs as POSTs typically return the created resource. This is even true
with other APIs that 'add' something to a resource.
It seems we should consider returning the resource here; I suspect it's
just a few LOC changes in the API.
[1] https://review.openstack.org/#/c/543408/6/api-ref/source/v2/l3
-agent-scheduler.inc@76
** Affects: neutron
Importance: Undecided
Status: New
** Tags: api
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1762732
Title:
l3agentscheduler doesn't return a response body with POST
/v2.0/agents/{agent_id}/l3-routers
Status in neutron:
New
Bug description:
As discussed in [1], the
POST /v2.0/agents/{agent_id}/l3-routers
does not return a response body. This seems inconsistent with our
other APIs as POSTs typically return the created resource. This is
even true with other APIs that 'add' something to a resource.
It seems we should consider returning the resource here; I suspect
it's just a few LOC changes in the API.
[1] https://review.openstack.org/#/c/543408/6/api-ref/source/v2/l3
-agent-scheduler.inc@76
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1762732/+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 1762733] [NEW] l3agentscheduler doesn't return a response body with POST /v2.0/agents/{agent_id}/l3-routers
Public bug reported:
As discussed in [1], the
POST /v2.0/agents/{agent_id}/l3-routers
does not return a response body. This seems inconsistent with our other
APIs as POSTs typically return the created resource. This is even true
with other APIs that 'add' something to a resource.
It seems we should consider returning the resource here; I suspect it's
just a few LOC changes in the API.
[1] https://review.openstack.org/#/c/543408/6/api-ref/source/v2/l3
-agent-scheduler.inc@76
** Affects: neutron
Importance: Undecided
Status: New
** Tags: api
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1762733
Title:
l3agentscheduler doesn't return a response body with POST
/v2.0/agents/{agent_id}/l3-routers
Status in neutron:
New
Bug description:
As discussed in [1], the
POST /v2.0/agents/{agent_id}/l3-routers
does not return a response body. This seems inconsistent with our
other APIs as POSTs typically return the created resource. This is
even true with other APIs that 'add' something to a resource.
It seems we should consider returning the resource here; I suspect
it's just a few LOC changes in the API.
[1] https://review.openstack.org/#/c/543408/6/api-ref/source/v2/l3
-agent-scheduler.inc@76
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1762733/+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 1760832] [NEW] Shows external networks even if they are not shared
Public bug reported: Hi, I think, that this case might be somehow related to the one, described here: https://bugs.launchpad.net/horizon/+bug/1384975 Steps to reproduce are the same: Login as tenant "A", create couple of networks: - Network 1, external network shared. - Network 2, external network (not-shared). Now Login as tenant "B", go to project and network listing page: - We see as well as shared external networks, as not shared ones. - Not shared networks are displayed without subnets, and they are not available for instance/port creation I was able to hide not shared external networks (while shared ones are still present) with setting include_external=False here https://github.com/openstack/horizon/blob/9ca9b5cd81db29bddf6dbcc5fc535009a9ec63b0/openstack_dashboard/dashboards/project/networks/views.py#L55 So this setting makes expected changes and behaviour. Probably, there is a reason, why this was hardcoded, and current behaviour is required for some features. But probably it's worth to consider to move this to the settings section? ** Affects: horizon Importance: Undecided Status: New ** Tags: pike -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1760832 Title: Shows external networks even if they are not shared Status in OpenStack Dashboard (Horizon): New Bug description: Hi, I think, that this case might be somehow related to the one, described here: https://bugs.launchpad.net/horizon/+bug/1384975 Steps to reproduce are the same: Login as tenant "A", create couple of networks: - Network 1, external network shared. - Network 2, external network (not-shared). Now Login as tenant "B", go to project and network listing page: - We see as well as shared external networks, as not shared ones. - Not shared networks are displayed without subnets, and they are not available for instance/port creation I was able to hide not shared external networks (while shared ones are still present) with setting include_external=False here https://github.com/openstack/horizon/blob/9ca9b5cd81db29bddf6dbcc5fc535009a9ec63b0/openstack_dashboard/dashboards/project/networks/views.py#L55 So this setting makes expected changes and behaviour. Probably, there is a reason, why this was hardcoded, and current behaviour is required for some features. But probably it's worth to consider to move this to the settings section? To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1760832/+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 1757513] [NEW] standardattrdescription clobbers existing description API attr
Public bug reported: The commit [1] to use neutron-lib's segment API def surfaced an issue [2] whereupon the standardattrdescription's update of the 'description' attribute clobbers existing defs. For example the segment API def has a 'description' [3] allowing it to be set to 'None'. However the standardattrdescription overwrites that with its own description attribute [4] thereby causing [2]. This is the same reason for the hack in [5]. To me this behavior is odd in general; given an extension may already define its own description attr. A few fixes come to mind: - The standardattrdescription ext can filter out those that already define the 'description' in their API def. This isn't much code. - Extensions wanting to define a 'description' can remove themselves from the HasStandardAttributes (probably less than ideal) and just get it for free from standardattrdescription. I could probably do the work here, just looking for a consensus on direction. [1] https://review.openstack.org/#/c/552140 [2] http://logs.openstack.org/74/553374/2/check/osc-functional-devstack/6321b58/job-output.txt.gz#_2018-03-21_14_43_24_047175 [3] https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/segment.py#L97 [4] https://github.com/openstack/neutron/blob/master/neutron/extensions/standardattrdescription.py#L22 [5] https://review.openstack.org/#/c/552140/4/neutron/tests/unit/extensions/test_segment.py@83 ** Affects: neutron Importance: Undecided Status: New ** Tags: api -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1757513 Title: standardattrdescription clobbers existing description API attr Status in neutron: New Bug description: The commit [1] to use neutron-lib's segment API def surfaced an issue [2] whereupon the standardattrdescription's update of the 'description' attribute clobbers existing defs. For example the segment API def has a 'description' [3] allowing it to be set to 'None'. However the standardattrdescription overwrites that with its own description attribute [4] thereby causing [2]. This is the same reason for the hack in [5]. To me this behavior is odd in general; given an extension may already define its own description attr. A few fixes come to mind: - The standardattrdescription ext can filter out those that already define the 'description' in their API def. This isn't much code. - Extensions wanting to define a 'description' can remove themselves from the HasStandardAttributes (probably less than ideal) and just get it for free from standardattrdescription. I could probably do the work here, just looking for a consensus on direction. [1] https://review.openstack.org/#/c/552140 [2] http://logs.openstack.org/74/553374/2/check/osc-functional-devstack/6321b58/job-output.txt.gz#_2018-03-21_14_43_24_047175 [3] https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/segment.py#L97 [4] https://github.com/openstack/neutron/blob/master/neutron/extensions/standardattrdescription.py#L22 [5] https://review.openstack.org/#/c/552140/4/neutron/tests/unit/extensions/test_segment.py@83 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1757513/+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 1745412] [NEW] test_l3_agent_scheduler intermittent failures when running locally
Public bug reported: As part of my dev process, I run the py27 target frequently on my local workspace dev env to verify changes/fixes. Over the past few months I've begun to get intermittent failures in the test_l3_agent_scheduler module. I've collected the failures from the past week and posted them on pastebin [1]. Note that some of these failures are not test_l3_agent_scheduler, so disregard them for this particular bug report. To try and eliminate the possibility these failures could be related to left over artifacts from previous py27 in my workspace, I've tried deleting .tox/, .stestr/, etc. in my workspace before running py27. It doesn't seem to help. Therefore it seems there maybe a race/timing issue in these tests. Interestingly enough I don't find any hits with logstash, so it's not clear why I'm getting them locally (say 1 of every 4-5 runs of py27). [1] http://paste.openstack.org/show/653447/ ** 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/1745412 Title: test_l3_agent_scheduler intermittent failures when running locally Status in neutron: New Bug description: As part of my dev process, I run the py27 target frequently on my local workspace dev env to verify changes/fixes. Over the past few months I've begun to get intermittent failures in the test_l3_agent_scheduler module. I've collected the failures from the past week and posted them on pastebin [1]. Note that some of these failures are not test_l3_agent_scheduler, so disregard them for this particular bug report. To try and eliminate the possibility these failures could be related to left over artifacts from previous py27 in my workspace, I've tried deleting .tox/, .stestr/, etc. in my workspace before running py27. It doesn't seem to help. Therefore it seems there maybe a race/timing issue in these tests. Interestingly enough I don't find any hits with logstash, so it's not clear why I'm getting them locally (say 1 of every 4-5 runs of py27). [1] http://paste.openstack.org/show/653447/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1745412/+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 1745380] [NEW] Cleanup unused params in parameters.yaml of api-ref
Public bug reported: Today the neutron-lib/api-ref/source/v2/parameters.yaml has a bunch of unused params. For example: name_39 name_41 etc.. Any params in parameters.yaml that's not used in any .inc, is not needed and should be removed from parameters.yaml (it's dead code per say). ** Affects: neutron Importance: Undecided Status: New ** Tags: api-ref -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1745380 Title: Cleanup unused params in parameters.yaml of api-ref Status in neutron: New Bug description: Today the neutron-lib/api-ref/source/v2/parameters.yaml has a bunch of unused params. For example: name_39 name_41 etc.. Any params in parameters.yaml that's not used in any .inc, is not needed and should be removed from parameters.yaml (it's dead code per say). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1745380/+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 1738475] [NEW] test_notify_port_ready_after_enable_dhcp fails with RuntimeError: 'dhcp_ready_on_ports' not be called
Public bug reported: As of recent there appears to be an intermittent failure in neutron.tests.functional.agent.test_dhcp_agent.DHCPAgentOVSTestCase.test_notify_port_ready_after_enable_dhcp; it fails with: RuntimeError: 'dhcp_ready_on_ports' not be called For example [1]. As of right now I only see 2 patches that have failed with this [2], but it also appears to only have recently started occurring. Additional debug is required. [1] http://logs.openstack.org/82/423382/18/check/legacy-neutron-dsvm-functional/9fef974/job-output.txt.gz#_2017-12-15_15_09_15_599225 [2] http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22RuntimeError%3A%20'dhcp_ready_on_ports'%20not%20be%20called%5C%22 ** Affects: neutron Importance: Undecided Status: New ** Tags: gate-failure -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1738475 Title: test_notify_port_ready_after_enable_dhcp fails with RuntimeError: 'dhcp_ready_on_ports' not be called Status in neutron: New Bug description: As of recent there appears to be an intermittent failure in neutron.tests.functional.agent.test_dhcp_agent.DHCPAgentOVSTestCase.test_notify_port_ready_after_enable_dhcp; it fails with: RuntimeError: 'dhcp_ready_on_ports' not be called For example [1]. As of right now I only see 2 patches that have failed with this [2], but it also appears to only have recently started occurring. Additional debug is required. [1] http://logs.openstack.org/82/423382/18/check/legacy-neutron-dsvm-functional/9fef974/job-output.txt.gz#_2017-12-15_15_09_15_599225 [2] http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22RuntimeError%3A%20'dhcp_ready_on_ports'%20not%20be%20called%5C%22 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1738475/+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 1733395] [NEW] subnetallocation extension not doc'd in api-ref
Public bug reported: The subnetallocation extension appears to be a shim extension that doesn't add any attrs/resources. However we should still document this extension in a subsection to describe what it does. ** Affects: neutron Importance: Undecided Status: Confirmed ** Tags: api-ref -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1733395 Title: subnetallocation extension not doc'd in api-ref Status in neutron: Confirmed Bug description: The subnetallocation extension appears to be a shim extension that doesn't add any attrs/resources. However we should still document this extension in a subsection to describe what it does. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1733395/+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 1733396] [NEW] subnet_service_types extension is not documented in api-ref
Public bug reported: The subnet_service_types extension is not documented in our api-ref: - The subnet api-ref needs a subsection atop it describing the extn. - Any attrs added by the extn need to be doc'd as params on the subnet api-ref. ** Affects: neutron Importance: Undecided Status: Confirmed ** Tags: api-ref -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1733396 Title: subnet_service_types extension is not documented in api-ref Status in neutron: Confirmed Bug description: The subnet_service_types extension is not documented in our api-ref: - The subnet api-ref needs a subsection atop it describing the extn. - Any attrs added by the extn need to be doc'd as params on the subnet api-ref. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1733396/+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 1733389] [NEW] router_availability_zone not properly documented in api-ref
Public bug reported: While the params added by router_availability_zone extension do appear to be documented in the routers api-ref, the extension needs a subsection atop the routers api-ref describing the extn itself. See other api-refs for examples. ** Affects: neutron Importance: Undecided Status: Confirmed ** Tags: api-ref -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1733389 Title: router_availability_zone not properly documented in api-ref Status in neutron: Confirmed Bug description: While the params added by router_availability_zone extension do appear to be documented in the routers api-ref, the extension needs a subsection atop the routers api-ref describing the extn itself. See other api-refs for examples. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1733389/+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 1733390] [NEW] routerservicetype extension not documented in api-ref
Public bug reported: The routerservicetype extension is not doc'd in our api-ref: - The routerservicetype extension needs a subsection atop the router api-ref describing the extn itself. - Any params added by the extn need to be doc'd. ** Affects: neutron Importance: Undecided Status: Confirmed ** Tags: api-ref ** Changed in: neutron Status: New => Confirmed ** Tags added: api-ref -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1733390 Title: routerservicetype extension not documented in api-ref Status in neutron: Confirmed Bug description: The routerservicetype extension is not doc'd in our api-ref: - The routerservicetype extension needs a subsection atop the router api-ref describing the extn itself. - Any params added by the extn need to be doc'd. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1733390/+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 1733386] [NEW] qos_default extension not doc'd in api-ref
Public bug reported: The qos_default extension is not documented in our api-ref: - The qos policy api-ref needs a subsection atop it describing the extn. - Any params added by the extn need to be doc'd therein as well. ** Affects: neutron Importance: Undecided Status: Confirmed ** Tags: api-ref -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1733386 Title: qos_default extension not doc'd in api-ref Status in neutron: Confirmed Bug description: The qos_default extension is not documented in our api-ref: - The qos policy api-ref needs a subsection atop it describing the extn. - Any params added by the extn need to be doc'd therein as well. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1733386/+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 1733383] [NEW] qos_bw_limit_direction extension not properly documented in api-ref
Public bug reported: While the qos_bw_limit_direction extension params are documented in the qos api-ref, the extension needs a subsection atop the bw limit rule section describing the extension itself. See other api-refs for examples. ** Affects: neutron Importance: Undecided Status: Confirmed ** Tags: api-ref -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1733383 Title: qos_bw_limit_direction extension not properly documented in api-ref Status in neutron: Confirmed Bug description: While the qos_bw_limit_direction extension params are documented in the qos api-ref, the extension needs a subsection atop the bw limit rule section describing the extension itself. See other api-refs for examples. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1733383/+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 1733387] [NEW] qos_rule_type_details not properly doc'd in api-ref
Public bug reported: While the qos_rule_type_details extension's params appear to be doc'd in the qos rule types api-ref, the rule types api-ref needs a subsection atop it describing the extension itself. See other api-refs for examples. ** Affects: neutron Importance: Undecided Status: Confirmed ** Tags: api-ref -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1733387 Title: qos_rule_type_details not properly doc'd in api-ref Status in neutron: Confirmed Bug description: While the qos_rule_type_details extension's params appear to be doc'd in the qos rule types api-ref, the rule types api-ref needs a subsection atop it describing the extension itself. See other api-refs for examples. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1733387/+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 1733378] [NEW] l3_flavors extension is not documented in api-ref
Public bug reported: The l3_flavors extension is not doc'd in our api-ref: - The routers api-ref needs a subsection atop it doc'ing the extn. - Any params added by the extn also needed to be doc'd therein. ** Affects: neutron Importance: Undecided Status: Confirmed ** Tags: api-ref -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1733378 Title: l3_flavors extension is not documented in api-ref Status in neutron: Confirmed Bug description: The l3_flavors extension is not doc'd in our api-ref: - The routers api-ref needs a subsection atop it doc'ing the extn. - Any params added by the extn also needed to be doc'd therein. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1733378/+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 1733377] [NEW] l3_ext_ha_mode extension is not documented in api-ref
Public bug reported: The l3_ext_ha_mode extension is not documented in our api-ref: - The routers api-ref needs a subsection atop it describing the extension. - Any params added by the extension also need to be doc'd therein. ** Affects: neutron Importance: Undecided Status: Confirmed ** Tags: api-ref -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1733377 Title: l3_ext_ha_mode extension is not documented in api-ref Status in neutron: Confirmed Bug description: The l3_ext_ha_mode extension is not documented in our api-ref: - The routers api-ref needs a subsection atop it describing the extension. - Any params added by the extension also need to be doc'd therein. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1733377/+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 1733376] [NEW] l3_ext_gw_mode is not documented in api-ref
Public bug reported: The l3_ext_gw_mode extension is not documented in our api-ref: - The routers api-ref needs a subsection atop it describing the extension. - The routers api-ref needs to doc any params added by the extension. ** Affects: neutron Importance: Undecided Status: Confirmed ** Tags: api-ref -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1733376 Title: l3_ext_gw_mode is not documented in api-ref Status in neutron: Confirmed Bug description: The l3_ext_gw_mode extension is not documented in our api-ref: - The routers api-ref needs a subsection atop it describing the extension. - The routers api-ref needs to doc any params added by the extension. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1733376/+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 1733380] [NEW] network_availability_zone not documented in api-ref
Public bug reported: The network_availability_zone is not documented in our api-ref: - The networks api-ref needs a subsection atop it doc'ing the extension. - Any params added by the extension need to included in the network api-ref. ** Affects: neutron Importance: Undecided Status: Confirmed ** Tags: api-ref -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1733380 Title: network_availability_zone not documented in api-ref Status in neutron: Confirmed Bug description: The network_availability_zone is not documented in our api-ref: - The networks api-ref needs a subsection atop it doc'ing the extension. - Any params added by the extension need to included in the network api-ref. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1733380/+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 1733374] [NEW] l3agentscheduler not documented in api-ref
Public bug reported: The l3agentscheduler extension is not documented in our api-ref: - The agents api-ref needs a subsection atop it describing the extension. Any params added by the extension also need to be doc'd therein. - The routers api-ref needs a subsection atop it describing the extension. Any params added by the extension also need to be doc'd therein. ** Affects: neutron Importance: Undecided Status: Confirmed ** Tags: api-ref -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1733374 Title: l3agentscheduler not documented in api-ref Status in neutron: Confirmed Bug description: The l3agentscheduler extension is not documented in our api-ref: - The agents api-ref needs a subsection atop it describing the extension. Any params added by the extension also need to be doc'd therein. - The routers api-ref needs a subsection atop it describing the extension. Any params added by the extension also need to be doc'd therein. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1733374/+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 1733368] [NEW] extra_dhcp_opt extension not properly documented in api-ref
Public bug reported: The extra_dhcp_opt is not properly doc'd in our api-ref. While the ports api-ref does doc the extra_dhcp_opts request/response param, the extra_dhcp_opt extension needs to be described in a subnsection atop to the ports api-ref like others do. ** Affects: neutron Importance: Undecided Status: Confirmed ** Tags: api-ref -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1733368 Title: extra_dhcp_opt extension not properly documented in api-ref Status in neutron: Confirmed Bug description: The extra_dhcp_opt is not properly doc'd in our api-ref. While the ports api-ref does doc the extra_dhcp_opts request/response param, the extra_dhcp_opt extension needs to be described in a subnsection atop to the ports api-ref like others do. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1733368/+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 1733367] [NEW] external_net extension not properly documented in api-ref
Public bug reported: The external_net extension is not completely documented yet. While it appears the networks api-ref does doc the router:external params, the external_net extension needs to be described in a subsection atop the networks api-ref (see others for examples). ** Affects: neutron Importance: Undecided Status: Confirmed ** Tags: api-ref ** Changed in: neutron Status: New => Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1733367 Title: external_net extension not properly documented in api-ref Status in neutron: Confirmed Bug description: The external_net extension is not completely documented yet. While it appears the networks api-ref does doc the router:external params, the external_net extension needs to be described in a subsection atop the networks api-ref (see others for examples). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1733367/+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 1733370] [NEW] ip_allocation extension not documented in api-ref
Public bug reported: The ip_allocation extension is not documented in our api-ref: - The port api-ref needs a subsection describing the extn. - The params added by the extn need to be documented in the port api-ref. ** Affects: neutron Importance: Undecided Status: Confirmed ** Tags: api-ref -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1733370 Title: ip_allocation extension not documented in api-ref Status in neutron: Confirmed Bug description: The ip_allocation extension is not documented in our api-ref: - The port api-ref needs a subsection describing the extn. - The params added by the extn need to be documented in the port api-ref. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1733370/+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 1733373] [NEW] l2_adjacency extension not documented in api-ref
Public bug reported: The l2_adjacency extension is not documented in our api-ref: - The networks api-ref needs a subsection atop it describing the extension. - Any params added by the extension need to be included in the network api-ref. ** Affects: neutron Importance: Undecided Status: Confirmed ** Tags: api-ref -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1733373 Title: l2_adjacency extension not documented in api-ref Status in neutron: Confirmed Bug description: The l2_adjacency extension is not documented in our api-ref: - The networks api-ref needs a subsection atop it describing the extension. - Any params added by the extension need to be included in the network api-ref. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1733373/+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 1733364] [NEW] dhcpagentscheduler extension not documented in api-ref
Public bug reported: The dhcpagentscheduler extension is not documented in our api-ref: - The extension needs to be documented on the agents resource as well as the attr(s) it adds. - The extension needs to be documented on the networks resource as well as the attr(s) it adds. ** Affects: neutron Importance: Undecided Status: Confirmed ** Tags: api-ref ** Changed in: neutron Status: New => Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1733364 Title: dhcpagentscheduler extension not documented in api-ref Status in neutron: Confirmed Bug description: The dhcpagentscheduler extension is not documented in our api-ref: - The extension needs to be documented on the agents resource as well as the attr(s) it adds. - The extension needs to be documented on the networks resource as well as the attr(s) it adds. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1733364/+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 1733365] [NEW] dvr extension not documented in api-ref
Public bug reported: The dvr extension is not documented in our API-ref: - The routers api-ref needs to have a subsection for the extension as well as included the param(s) the extension adds. ** Affects: neutron Importance: Undecided Status: Confirmed ** Tags: api-ref ** Changed in: neutron Status: New => Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1733365 Title: dvr extension not documented in api-ref Status in neutron: Confirmed Bug description: The dvr extension is not documented in our API-ref: - The routers api-ref needs to have a subsection for the extension as well as included the param(s) the extension adds. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1733365/+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 1471032] Re: [api-ref]Support Basic Address Scope CRUD as extensions
Reviving this bug. The address scopes extension doesn't appear to be documented in the API ref. - The address scopes resource itself isn't in the api-ref. - The networks and subnetpools resources need to note the extension and include in their params. ** Changed in: neutron Status: Invalid => Confirmed ** Tags removed: neutron -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1471032 Title: [api-ref]Support Basic Address Scope CRUD as extensions Status in neutron: Confirmed Bug description: https://review.openstack.org/189741 commit cbd95318ad6c44e72a3aa163f7a399353c8b4458 Author: vikram.choudhary Date: Tue Jun 9 19:55:59 2015 +0530 Support Basic Address Scope CRUD as extensions This patch adds the support for basic address scope CRUD. Subsequent patches will be added to use this address scope on subnet pools. DocImpact APIImpact Co-Authored-By: Ryan Tidwell Co-Authored-By: Numan Siddique Change-Id: Icabdd22577cfda0e1fbf6042e4b05b8080e54fdb Partially-implements: blueprint address-scopes To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1471032/+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 1733360] [NEW] auto-allocated-topology extension missing from API ref
Public bug reported: The auto-allocated-topology extension is not documented in our current api-ref: - The auto_allocated_topologies resource is not documented. - The extension is not explained for the network resource nor is the is_default option for networks. ** Affects: neutron Importance: Undecided Status: Confirmed ** Tags: api-ref ** Changed in: neutron Status: New => Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1733360 Title: auto-allocated-topology extension missing from API ref Status in neutron: Confirmed Bug description: The auto-allocated-topology extension is not documented in our current api-ref: - The auto_allocated_topologies resource is not documented. - The extension is not explained for the network resource nor is the is_default option for networks. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1733360/+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 1733362] [NEW] availability_zone extension missing from API ref
Public bug reported: The availability_zone extension is not documented in the API ref: - The availability_zones resource is not documented. - The az extension is not documented on the agent api-ref nor is the availability_zone attribute added to agents. ** Affects: neutron Importance: Undecided Status: Confirmed ** Tags: api-ref ** Changed in: neutron Status: New => Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1733362 Title: availability_zone extension missing from API ref Status in neutron: Confirmed Bug description: The availability_zone extension is not documented in the API ref: - The availability_zones resource is not documented. - The az extension is not documented on the agent api-ref nor is the availability_zone attribute added to agents. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1733362/+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 1726462] [NEW] legacy-tempest-dsvm-neutron-full times out waiting for vol available
Public bug reported: I've started noticing the following error in our legacy-tempest-dsvm- neutron-full jobs: -- volume 3c34fd82-8d3d-4d87-8290-f3c119587b94 failed to reach ['available'] status (current detaching) within the required time (196 s). -- Based on [2] this does not appear to be neutron specific and has started occurring as of 10/17/2017. However additional debug is needed to determine where the issue lies and where/what needs to be addressed. [1] http://logs.openstack.org/00/487600/7/gate/legacy-tempest-dsvm-neutron-full/90a4660/job-output.txt.gz#_2017-10-22_22_25_11_236303 [2] http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22failed%20to%20reach%20%5B'available'%5D%20status%20(current%20detaching)%20within%20the%20required%20time%5C%22 ** Affects: neutron Importance: Undecided Status: New ** Tags: gate-failure -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1726462 Title: legacy-tempest-dsvm-neutron-full times out waiting for vol available Status in neutron: New Bug description: I've started noticing the following error in our legacy-tempest-dsvm- neutron-full jobs: -- volume 3c34fd82-8d3d-4d87-8290-f3c119587b94 failed to reach ['available'] status (current detaching) within the required time (196 s). -- Based on [2] this does not appear to be neutron specific and has started occurring as of 10/17/2017. However additional debug is needed to determine where the issue lies and where/what needs to be addressed. [1] http://logs.openstack.org/00/487600/7/gate/legacy-tempest-dsvm-neutron-full/90a4660/job-output.txt.gz#_2017-10-22_22_25_11_236303 [2] http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22failed%20to%20reach%20%5B'available'%5D%20status%20(current%20detaching)%20within%20the%20required%20time%5C%22 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1726462/+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 1527008] Re: neutron-ml2_ofa.rst lacks some options
Best I can tell from comment #6 and the current neutron/docs/source tree, this is no longer valid and doc'd in neutron. If it is, please reopen and reference the openstack docs site URL that has the doc needing updating. thanks ** Changed in: neutron Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1527008 Title: neutron-ml2_ofa.rst lacks some options Status in neutron: Invalid Status in openstack-manuals: Won't Fix Bug description: neutron-ml2_ofa.rst[1] should contain get_datapath_retry_times and physical_interface_mappings options. These are defined as follows: http://git.openstack.org/cgit/openstack/networking- ofagent/tree/networking_ofagent/plugins/ofagent/common/config.py A third party repository seems not to be refered when the rst file are generated. neutron-ml2_brocade.rst seems to be the same, too. And openstack-manuals does not contain rst table files for other third party. I'm not sure if openstack-manuals should have rst table files for these third party drivers in this point. [1] http://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/config-ref-rst/source/tables/neutron-ml2_ofa.rst To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1527008/+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 1718954] Re: network_data.json contains default routes for 2 interfaces
Best I can tell, from a neutron perspective this is now being driven under the referenced RFE [1]. Under that assumption I'm getting this one off the bug queue. If [1] doesn't cover this defect, please feel free to open and provide some details on how this differs from [1]. Thanks [1] https://bugs.launchpad.net/neutron/+bug/1717560 ** Changed in: neutron Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1718954 Title: network_data.json contains default routes for 2 interfaces Status in neutron: Invalid Status in OpenStack Compute (nova): Opinion Bug description: On an OpenStack Ocata install a guest with two network interfaces attached is provided with network_data.json that describes 2 default routes. See attached network_data.json and (pretty formatted network_data-pretty.json). Also note that the reporter ran 'dhclient -v' which created the attached dhclient.leases file. Only one of the dhcp servers returns a 'routers' option. That would seem to indicate that the platform has some distinction. Cloud-init renders the networking in /etc/network/interfaces and ends up with 2 default routes, which doesn't do what the user wanted. This issue was originally raised in freenode #cloud-init. There is discussion surrounding it with the original reporter at: https://irclogs.ubuntu.com/2017/09/22/%23cloud-init.html Related bugs: * bug 1717560: allow to have no default route in DHCP host routes To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1718954/+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 1720091] Re: delete running vms, but ovs flow table is still residual
Moving this back to fix released. It's not clear why it was moved back to "New" on 10-03. If there's still an issue, please update with additional information as to why its re-opened and the original fix isn't sufficient. Thanks ** Changed in: neutron Status: New => 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/1720091 Title: delete running vms, but ovs flow table is still residual Status in neutron: Fix Released Bug description: in Pike version, if I delete running vms, the ovs flow table will be still residual. for examples: the first, create vm, named pc1 [root@bogon ~]# nova list +--+--+++-+--+ | ID | Name | Status | Task State | Power State | Networks | +--+--+++-+--+ | 2f91523c-6a4f-434a-a228-0d07ca735e6a | pc1 | ACTIVE | - | Running | net=5.5.5.13 | +--+--+++-+--+ the second,I directly delete the running virtual machine, [root@bogon ~]# nova list ++--+++-+--+ | ID | Name | Status | Task State | Power State | Networks | ++--+++-+--+ ++--+++-+--+ then the relevant flow table will be left. [root@bogon ~]# ovs-ofctl dump-flows br-int | grep 5.5.5.13 cookie=0x8231b3d9ff6eecde, duration=189.590s, table=82, n_packets=0, n_bytes=0, idle_age=189, priority=70,ct_state=+est-rel-rpl,ip,reg6=0x1,nw_src=5.5.5.13 actions=conjunction(2,1/2) cookie=0x8231b3d9ff6eecde, duration=189.589s, table=82, n_packets=0, n_bytes=0, idle_age=189, priority=70,ct_state=+new-est,ip,reg6=0x1,nw_src=5.5.5.13 actions=conjunction(3,1/2) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1720091/+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 1694349] Re: VXLAN multicast groups in linuxbridge
Not sure there's anything to doc here. The agent config guide [1] refs over to the linuxbridge agent config opts [2] that documents the multicast_ranges option. [1] https://docs.openstack.org/neutron/latest/admin/config-ml2.html#l2-agent [2] https://docs.openstack.org/neutron/latest/configuration/linuxbridge-agent.html ** Changed in: neutron Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1694349 Title: VXLAN multicast groups in linuxbridge Status in neutron: Invalid Status in openstack-manuals: Won't Fix Bug description: https://review.openstack.org/79 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit 8a596f35bb70a2c8ab48f68327662310141bb518 Author: Jiri Kotlin Date: Thu Jun 23 14:04:07 2016 + VXLAN multicast groups in linuxbridge Enable creation of VXLANs with different multicast addresses allocated by VNI-address mappings. Dictionary of multicast addresses and corresponding VXLAN VNI IDs should be loaded from settings. Usable to not flood whole network when managing routers between more datacenters and can not use L2population because VXLAN points to external device. Co-Authored-By: Kevin Benton DocImpact: VXLAN addresses used by linux bridge can be specified per VNI Closes-Bug: #1579068 Change-Id: I24f272ccd6d61d9fa7ea3b6f256fabd381f5434a To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1694349/+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 1719516] Re: Networking Option 1: Provider networks in neutron
** Changed in: neutron Status: Incomplete => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1719516 Title: Networking Option 1: Provider networks in neutron Status in neutron: Invalid Bug description: this service_plugins = router no roouter This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [ ] This doc is inaccurate in this way: __ - [ ] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - Ask OpenStack: http://ask.openstack.org - The mailing list: http://lists.openstack.org - IRC: 'openstack' channel on Freenode --- Release: 11.0.1.dev84 on 2017-09-23 19:36 SHA: 5b0191f5241b0ce70ed63952d01aaa1255c60b08 Source: https://git.openstack.org/cgit/openstack/neutron/tree/doc/source/install/controller-install-option1-ubuntu.rst URL: https://docs.openstack.org/neutron/pike/install/controller-install-option1-ubuntu.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1719516/+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 1716043] [NEW] no CLI for quota details
Public bug reported: Patch [1] added the quota detail API. However to the best of my knowledge this support didn't make it into the CLI (neutron neutronclient or OSC). This bug is to track the integration of quota details into the CLI. [1] https://review.openstack.org/#/c/383673/ ** 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/1716043 Title: no CLI for quota details Status in neutron: New Bug description: Patch [1] added the quota detail API. However to the best of my knowledge this support didn't make it into the CLI (neutron neutronclient or OSC). This bug is to track the integration of quota details into the CLI. [1] https://review.openstack.org/#/c/383673/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1716043/+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 1689300] Re: [DOC] Document subport/parent MAC address relationship
Based on Armando's comment #2 moving this to invalid. Given comment#2, if folks still feel doc tweaking is necessary, please reopen. ** Changed in: neutron Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1689300 Title: [DOC] Document subport/parent MAC address relationship Status in neutron: Invalid Bug description: Description of problem: We need to documents that while create sub-port it should be created with --mac-address PARENT_PORT_MAC_ADDERSS. This is the correct networking config- on VM subIF and IF should have the same mac and it is the default option. We need to match neutron port creation with same concept- parent and subport should have same mac address. Openstack Ocata To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1689300/+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 1683107] Re: Add support for Keepalived VRRP health check
After looking through our current docs, I don't see any place we specifically talk in depth about l3 agent HA. Therefore if we want to spend the time with a new agent HA guide (or something) I think that should come in as a stand alone request. The config option added as part of this change is well documented including info about ICMP ECHO_REQUEST [1]. That said I don't see any other work necessary here. [1] https://docs.openstack.org/neutron/pike/configuration/l3-agent.html#DEFAULT.ha_vrrp_health_check_interval ** Changed in: neutron Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1683107 Title: Add support for Keepalived VRRP health check Status in neutron: Invalid Bug description: https://review.openstack.org/454657 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit 01b3733975402525b67906928c069d468ca275d9 Author: Lubosz Kosnik Date: Thu Jan 28 14:44:00 2016 +0100 Add support for Keepalived VRRP health check Adds functionality to generate bash script which verifies health of current keepalived instance by pinging all available and configured GW addresses. This functionality supports IPv4 and IPv6 by detecting needed ping version using netaddr. DocImpact: Added a new parameter to 'l3_agent.ini' named 'ha_vrrp_health_check_interval' which is by default set to 0 (disabled). Values > 0 designate health check functionality should be enabled. Requires allowed ICMP ECHO_REQUEST because that is disabled by default. Conflicts: neutron/conf/agent/l3/ha.py neutron/agent/l3/ha.py neutron/agent/linux/keepalived.py Co-Authored-By: Artur Korzeniewski Change-Id: Ib4d0691f432830357ea3f113036719645bc59a62 Closes-Bug: #1365461 (cherry picked from commit 185d6cbc648fd041402a5034b04b818da5c7136e) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1683107/+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 1687392] Re: Add QoS bandwidth limit for instance ingress traffic
Best I can tell this one is already accounted for and there's nothing left to do. The API ref already includes 'direction' for applicable API operations [1]. In addition the qos config guide also includes direction [2]. If there's other doc hits that are unaccounted for, please reopen. [1] https://developer.openstack.org/api-ref/network/v2/index.html#quality-of-service [2] https://docs.openstack.org/neutron/pike/admin/config-qos.html ** 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/1687392 Title: Add QoS bandwidth limit for instance ingress traffic Status in neutron: Fix Released Status in openstack-manuals: Fix Released Bug description: https://review.openstack.org/449831 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit c29f3aaa7c20c89cb1eac818d2981c16fd484ace Author: Sławek Kapłoński Date: Fri Mar 24 22:04:53 2017 + Add QoS bandwidth limit for instance ingress traffic This patch introduces the new parameter "direction" to the QoS bandwidth limit rule. It will allow the creation of bandwidth limit rules for either ingress or egress traffic. For backwards compatibility the default direction will be egress. DocImpact: Ingress bandwidth limit available for QoS APIImpact: New type of parameter for QoS rule in neutron API Change-Id: Ia13568879c2b6f80fb190ccafe7e19ca05b0c6a8 Partial-Bug: #1560961 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1687392/+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 1716005] [NEW] validate doc links in the gate
Public bug reported: Today we have no validation of links (internal, relative or static) as part of our doc build. As a result we can end up with dead links over time that are typically noticed by our users... Less than optimal. As part of the comments in [1], it was suggested we try to validate links in the gate. While sounding simple it actually becomes more complex [2] given eventlet usage, considerations for periodic job, etc.. This bug is to track the work to add some sort of validation during our build, perhaps as a periodic job. [1] https://review.openstack.org/#/c/500095/ [2] http://lists.openstack.org/pipermail/openstack-dev/2017-September/121833.html ** Affects: neutron Importance: Undecided Status: New ** Tags: doc -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1716005 Title: validate doc links in the gate Status in neutron: New Bug description: Today we have no validation of links (internal, relative or static) as part of our doc build. As a result we can end up with dead links over time that are typically noticed by our users... Less than optimal. As part of the comments in [1], it was suggested we try to validate links in the gate. While sounding simple it actually becomes more complex [2] given eventlet usage, considerations for periodic job, etc.. This bug is to track the work to add some sort of validation during our build, perhaps as a periodic job. [1] https://review.openstack.org/#/c/500095/ [2] http://lists.openstack.org/pipermail/openstack-dev/2017-September/121833.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1716005/+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 1669626] Re: When using openvswitch as the firewall driver, nf_conntrack_ipv4 and nf_conntrack_ipv6 kernel modules are needed
This bug has been idle for a long time. Moving to invalid. If comment #1 doesn't address this issue, please reopen with additional details. Thanks ** Changed in: neutron Status: Incomplete => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1669626 Title: When using openvswitch as the firewall driver, nf_conntrack_ipv4 and nf_conntrack_ipv6 kernel modules are needed Status in neutron: Invalid Bug description: VM's suddenly stopped being able to communicate out. Openstack version: Mitaka OVS version: 2.5.0 We use the Openvswitch firewall driver, and it had been working great. Then, randomly, all VM's running on our stack ceased to be able to communicate with anything. After looking into the flow construct on br-int, it was clear OVS was sending the traffic to a drop flow like this: cookie=0xa2b1b8107c6edcef, duration=8973.001s, table=72, n_packets=176, n_bytes=17248, idle_age=8797, priority=50,ct_state=+inv+trk actions=drop We checked logs on the Neutron server and others, but couldn't find any indication of why this was happening. Eventually we got some invaluable help that I would have never found on my own, which was, somehow we didn't have these modules loaded: nf_conntrack_ipv4 and nf_conntrack_ipv6 The second we loaded those modules, everything worked great. It was requested of me to report this as a bug per there being no mention of those kernel module requirements in relevant documentation. Such documentation would have saved us days of time. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1669626/+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 1538695] Re: sriov-mech: Introduce a new VIF type for PF vnic type
Based on what I see the change introduced the vif type of 'hostdev_physical'. This is already documented as a vif type for ports in our API ref, for example [1]. The response parameters show: --- binding:vif_type The type of which mechanism is used for the port. An API consumer like nova can use this to determine an appropriate way to attach a device (for example an interface of a virtual server) to the port. Available values currently defined includes ovs, bridge, macvtap, hw_veb, hostdev_physical, vhostuser, distributed and other. There are also special values: unbound and binding_failed. unbound means the port is not bound to a networking back-end. binding_failed means an error that the port failed to be bound to a networking back-end. --- As seen above, the parameter documentation includes hostdev_physical so we should be all set for this one. [1] https://developer.openstack.org/api-ref/network/v2/index.html#show- port-details ** Changed in: neutron Status: Incomplete => 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/1538695 Title: sriov-mech: Introduce a new VIF type for PF vnic type Status in neutron: Fix Released Status in openstack-api-site: Fix Released Bug description: https://review.openstack.org/262604 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit 4a431f75a01fbdd0b802c86e27a93a6daaf70399 Author: Nikola Dipanov Date: Wed Dec 30 19:48:33 2015 + sriov-mech: Introduce a new VIF type for PF vnic type We need to tell Nova to use a specific VIF type for full PF passthrough (this is the recently added VNIC_DIRECT_PHYSICAL vnic type). Make sure that when binding ports with this vnic type, we set the appropriate vif type for Nova to be able to provision those ports correctly. Nova change that adds a vif driver for this vif type: https://review.openstack.org/#/c/262583/ DocImpact: Exposes a new vif type for PF passtrhough vnic type Change-Id: I895dab98e5e5a9369771539e51ba5c500bfe0045 Related-blueprint: sriov-pf-passthrough-neutron-port To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1538695/+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 1714528] [NEW] l2pop config opts not documented
Public bug reported: In ocata we had config reference for l2pop config opts [1]. However these seem to be missing in pike [2] and are referenced in the config-ml2.rst doc. [1] https://docs.openstack.org/ocata/config-reference/networking/networking_options_reference.html#modular-layer-2-ml2-l2-population-mechanism-configuration-options [2] https://docs.openstack.org/neutron/pike/configuration/ml2-conf.html ** Affects: neutron Importance: Undecided Status: New ** Tags: doc -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1714528 Title: l2pop config opts not documented Status in neutron: New Bug description: In ocata we had config reference for l2pop config opts [1]. However these seem to be missing in pike [2] and are referenced in the config-ml2.rst doc. [1] https://docs.openstack.org/ocata/config-reference/networking/networking_options_reference.html#modular-layer-2-ml2-l2-population-mechanism-configuration-options [2] https://docs.openstack.org/neutron/pike/configuration/ml2-conf.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1714528/+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 1703413] Re: Allow to set UDP ports for VXLAN in Linuxbridge agent
After scanning our docs, I'm not seeing any updates that need to be made
here.
We touch on linuxbridge agent config in [1], but without much depth and
just refer to the config reference. Given the config options added as
part of this feature are well documented, IMO the config reference is
sufficient rather than adding new docs to address this.
However we need to fix [2], so the latest config options show up in our
public docs.
[1] https://docs.openstack.org/neutron/latest/admin/config-ml2.html#l2-agent
[2] https://bugs.launchpad.net/neutron/+bug/1714516
** Changed in: neutron
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1703413
Title:
Allow to set UDP ports for VXLAN in Linuxbridge agent
Status in neutron:
Invalid
Bug description:
https://review.openstack.org/468911
Dear bug triager. This bug was created since a commit was marked with
DOCIMPACT.
Your project "openstack/neutron" is set up so that we directly report the
documentation bugs against it. If this needs changing, the docimpact-group
option needs to be added for the project. You can ask the OpenStack infra team
(#openstack-infra on freenode) for help if you need to.
commit d7c4428525dac6cbde005f51bcd44b12ebc3bc0a
Author: Gyorgy Szombathelyi
Date: Mon May 29 16:21:15 2017 +0200
Allow to set UDP ports for VXLAN in Linuxbridge agent
Introduce vxlan.{udp_srcport_min, udp_srcport_max and udp_dstport}
for setting the port range used for VXLAN communication.
Change-Id: I9788090eee7aee9b533ac1dad2de95b29cbe
Closes-Bug: #1483853
DocImpact: vxlan.{udp_srcport_min, udp_srcport_max and udp_dstport}
can be used to set UDP port numbers used for VXLAN in LinuxBridge
agent.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1703413/+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 1714516] [NEW] doc refs to ocata based URLs
Public bug reported: Today we have a number of static links to ocata based pages in our docs [1]. For example a number of our config guides have static links to ocata config-reference pages. While these links are not dead, they are outdated and thus don't contain the latest content for our pike release. [1] http://codesearch.openstack.org/?q=ocata&i=nope&files=&repos=neutron ** Affects: neutron Importance: Medium Assignee: Boden R (boden) Status: New ** Tags: doc -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1714516 Title: doc refs to ocata based URLs Status in neutron: New Bug description: Today we have a number of static links to ocata based pages in our docs [1]. For example a number of our config guides have static links to ocata config-reference pages. While these links are not dead, they are outdated and thus don't contain the latest content for our pike release. [1] http://codesearch.openstack.org/?q=ocata&i=nope&files=&repos=neutron To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1714516/+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 1682244] Re: API Docs do not mention dns_name in port resource
This doc work was completed with
Ia5630ceb97d833b85d88cef323bcd2d6c9780c81 under bug
https://bugs.launchpad.net/neutron/+bug/1711992
** Changed in: neutron
Status: Confirmed => 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/1682244
Title:
API Docs do not mention dns_name in port resource
Status in neutron:
Fix Released
Bug description:
I did a port list on citycloud and got this:
{u'admin_state_up': True,
u'allowed_address_pairs': [],
u'binding:vnic_type': u'normal',
u'created_at': u'2017-02-06T20:59:45',
u'description': u'',
u'device_id': u'f80e3ad0-e13e-41d4-8e9c-be79bccdb8f7',
u'device_owner': u'compute:None',
u'dns_name': None,
u'extra_dhcp_opts': [],
u'fixed_ips': [{u'ip_address': u'10.4.0.16',
u'subnet_id': u'f0ad1df5-53ee-473f-b86b-3604ea5591e9'}],
u'id': u'a767944e-057a-47d1-a669-824a21b8fb7b',
u'mac_address': u'fa:16:3e:e8:7f:03',
u'name': u'',
u'network_id': u'2c9adcb5-c123-4c5a-a2ba-1ad4c4e1481f',
u'security_groups': [u'9fb5ba44-5c46-4357-8e60-8b55526cab54'],
u'status': u'ACTIVE',
u'tenant_id': u'65222a4d09ea4c68934fa1028c77f394',
u'updated_at': u'2017-02-06T20:59:49'}
which, as you can see, has a field called "dns_name". Sadly, that
field is not listed here:
https://developer.openstack.org/api-ref/networking/v2/?expanded=show-
port-details-detail
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1682244/+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 1678475] Re: Apply QoS policy on network:router_gateway
Based on the latest contents of the config qos guide [1], this has already been fixed. [1] https://github.com/openstack/neutron/blob/master/doc/source/admin /config-qos.rst ** Changed in: neutron Status: Confirmed => 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/1678475 Title: Apply QoS policy on network:router_gateway Status in neutron: Fix Released Status in openstack-manuals: Fix Released Bug description: https://review.openstack.org/425218 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit 2d1ee7add7c08ebbf8de7f9a0dc2aeb5344a4052 Author: Maxime Guyot Date: Wed Mar 8 15:14:32 2017 +0100 Apply QoS policy on network:router_gateway All router ports (internal and external) used to be excluded from QoS policies applied on network. This patch excludes only internal router ports from network QoS policies. This allows cloud administrators to set an egress QoS policy to a public/external network and have the QoS policy applied on all external router ports (DVR or not). To the tenant this is also egress traffic so no confusion compared to QoS policies applied to VM ports. DocImpact Update networking-guide/config-qos, User workflow section: - Replace "Network owned ports" with "Internal network owned ports" Change-Id: I2428c2466f41a022196576f4b14526752543da7a Closes-Bug: #1659265 Related-Bug: #1486039 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1678475/+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 1669191] Re: Deprecate gateway_external_network_id option
Today I don't see gateway_external_network_id documented other than a blank use of it in sample CLI output [1]. That said I don't see any reason to leave this open as I'm not sure what needs to be documented. When the deprecated option is removed, that should be marked with a doc impact tag and we can removed [1] at that point. [1] http://codesearch.openstack.org/?q=gateway_external_network_id&i=nope&files=doc%2Fsource%2F.*&repos= ** Changed in: neutron Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1669191 Title: Deprecate gateway_external_network_id option Status in neutron: Invalid Bug description: https://review.openstack.org/438669 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit 391ac43bf3862d67cee3ea0f628bd7958e585c7f Author: Ihar Hrachyshka Date: Thu Feb 23 10:21:12 2017 + Deprecate gateway_external_network_id option This option is used only when external_network_bridge is set to non-empty value, and that other option is already marked for removal. DocImpact The gateway_external_network_id option is deprecated and will be removed in next releases. Change-Id: Ie6ea9b8977a0e06d69d735532082e9e094c26534 Related-Bug: #1511578 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1669191/+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 1683102] Re: Port data plane status extension implementation
** 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/1683102 Title: Port data plane status extension implementation Status in neutron: Fix Released Bug description: https://review.openstack.org/424340 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit 89de63de05e296af583032cb17a3d76b4b4d6a40 Author: Carlos Goncalves Date: Mon Jan 23 19:53:04 2017 + Port data plane status extension implementation Implements the port data plane status extension. Third parties can report via Neutron API issues in the underlying data plane affecting connectivity from/to Neutron ports. Supported statuses: - None: no status being reported; default value - ACTIVE: all is up and running - DOWN: no traffic can flow from/to the Neutron port Setting attribute available to admin or any user with specific role (default role: data_plane_integrator). ML2 extension driver loaded on request via configuration: [ml2] extension_drivers = data_plane_status Related-Bug: #1598081 Related-Bug: #1575146 DocImpact: users can get status of the underlying port data plane; attribute writable by admin users and users granted the 'data-plane-integrator' role. APIImpact: port now has data_plane_status attr, set on port update Implements: blueprint port-data-plane-status Depends-On: I04eef902b3310f799b1ce7ea44ed7cf77c74da04 Change-Id: Ic9e1e3ed9e3d4b88a4292114f4cb4192ac4b3502 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1683102/+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 1688215] Re: Change list of available qos rules
This implementation was reverted in I88a216951d8996ac8bc90078b4239f0d25392e58 and therefore no doc changes are necessary here. ** Changed in: neutron Status: In Progress => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1688215 Title: Change list of available qos rules Status in neutron: Invalid Bug description: https://review.openstack.org/461257 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit 3299cdffae5cd7196a1676da103da5e2e413ec21 Author: Sławek Kapłoński Date: Sun Apr 30 08:17:29 2017 + Change list of available qos rules This patch changes way how neutron calculates which QoS rules are available to use. It now returns all rule types which are supported by at least one loaded QoS driver. If user will want to apply policy with rule unsupported by driver used by port then it will be catched on port/network update event. This validation mechanism was introduced in I75bd18b3a1875daa5639dd141fb7bbd6e1c54118 DocImpact: list of returned available QoS rule types is changed Change-Id: Ia00d349625db358ab486802fc0ff2e69eaa3895e Closes-Bug: #1686898 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1688215/+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 1712907] [NEW] contributor internals index incomplete
Public bug reported: The doc/source/contributor/internals/index.rst doesn't reference all the .rst files under doc/source/contributor/internals/. As a result the index page is incomplete [1] and a number of the contributor internal rsts aren't even published/accessible. [1] https://docs.openstack.org/neutron/latest/contributor/internals/index.html ** Affects: neutron Importance: Undecided Assignee: Boden R (boden) Status: New ** Tags: doc -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1712907 Title: contributor internals index incomplete Status in neutron: New Bug description: The doc/source/contributor/internals/index.rst doesn't reference all the .rst files under doc/source/contributor/internals/. As a result the index page is incomplete [1] and a number of the contributor internal rsts aren't even published/accessible. [1] https://docs.openstack.org/neutron/latest/contributor/internals/index.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1712907/+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 1710083] Re: Allow to set/modify network mtu
We still need to document this extension and its updatable nature in the api-ref ** Changed in: neutron Status: New => Fix Released ** Changed in: neutron Status: Fix Released => Confirmed ** Changed in: neutron Importance: Undecided => Medium ** Tags added: api-ref lib ** Summary changed: - Allow to set/modify network mtu + [api-ref] Allow to set/modify network mtu -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1710083 Title: [api-ref] Allow to set/modify network mtu Status in neutron: Confirmed Bug description: https://review.openstack.org/483518 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit f21c7e2851bc99b424bdc5322dcd0e3dee7ee5a3 Author: Ihar Hrachyshka Date: Mon Aug 7 10:18:11 2017 -0700 Allow to set/modify network mtu This patch adds ``net-mtu-writable`` API extension that allows to write to network ``mtu`` attribute. The patch also adds support for the extension to ml2, as well as covers the feature with unit and tempest tests. Agent side implementation of the feature is moved into a separate patch to ease review. DocImpact: neutron controller now supports ``net-mtu-writable`` API extension. APIImpact: new ``net-mtu-writable`` API extension was added. Related-Bug: #1671634 Change-Id: Ib232796562edd8fa69ec06b0cc5cb752c1467add To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1710083/+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 1705755] Re: [RFE] Plugin support for API resource attribute extensions
** Also 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/1705755
Title:
[RFE] Plugin support for API resource attribute extensions
Status in neutron:
New
Status in python-openstackclient:
New
Status in OpenStack SDK:
New
Bug description:
FORWARD
---
The purpose of this bug is to facilitate a discussion. While I'm willing to
do all the work to implement the feature request herein, I'd first like some
agreement that:
- We want to solve this problem.
- Core(s) on the respective projects (python-openstackclient and
python-openstacksdk) are willing to provide some guidance on the best
high-level approach.
BACKGROUND
--
Some OpenStack REST APIs such as neutron and nova support API extensions.
While the implementation details for API extensions may differ from project
to project, the basic extension support across all projects includes the
ability for pluggable extensions to augment the REST API in the following ways:
(a) Introducing new RESTful resources (APIs). These may be new top-level
resources (e.g. /v1/theapi/{extension_resource}) or sub-resources (e.g.
/v1/theapi/existing_resource/{extension_subresource}).
(b) Adding new attributes (fields) to existing RESTful resources. For example
neutron's net-mtu extension adds a 'mtu' attribute to networks [1] and nova's
extended status adds attributes to servers [2].
While some API extensions may exist in-tree (e.g. right in neutron or
nova), they can also live in out-of-tree projects that implement
plugins/drivers/etc..
Hopefully we can all agree that a CLI should encompass the means to
support both #a and #b above in some form or another in order to
obtain the pluggability our consumers expect with OpenStack.
PROBLEM DESCRIPTION
For sake of argument lets consider #a and #b as use cases from an OpenStack
CLI (python-openstackclient and python-openstacksdk) perspective. Albeit we are
talking from a contributor perspective here; but the ability to contribute
drive features users can consume.
(a) This case should already be supported via the existing OSC plugin
model. For example [3].
(b) This case is covered for stadium projects; they can add logic
right into python-openstackclient[sdk] as needed. However for non-
stadium projects, this case is not covered; today there's no easy way
to extend existing OSC resources/actions/options/etc. in a reusable
manner. For example, suppose a non-stadium neutron (plugin) project
implements the network API, extends the network resource with
additional attribute(s) and wants to provide CLI support for these
attributes. Ideally they should be able to reuse the existing neutron
network OSC logic in a pluggable manner such that they need not
reimplement the OSC "actions" and associated logic.
From a technical perspective, case #b roughly requires the ability for
non-stadium projects (with such attribute extensions) to:
(1) Add attributes to python-openstacksdk resource(s). This allows the
extension attributes to be "collected" from an API response body.
(2) Extend existing python-openstackclient commands by;
a) Adding parser options if needed to support the attribute extension(s).
b) Adding custom "take action" logic enabling the extension to process
attribute extension options if needed.
c) Displaying the attribute extension(s).
In neutron alone, the following out-of-tree projects implement extensions
falling under case #b:
- vmware-nsx
- gbpservice
- quark
- networking-cisco
- networking-bigswitch
- networking-h3c
This support was provided in an ad-hoc fashion with the classic python
clients (e.g. python-neutronclient) via it's ability to
pass/handle/display arbitrary key/values. For example an API extension
that adds a 'meta' boolean attribute to networks can be handled with
the neutron client without any changes. The sample output snippets
below show GET and POST (notice the 'meta' attribute that's added by
the sample extension).
-->
stack@bvm2:~/devstack$ neutron --debug net-show my-meta-net
...
RESP BODY:
{"network":{"provider:physical_network":null,"ipv6_address_scope":null,"meta":true,
...
+---+--+
| Field | Value|
+---+--+
| admin_state_up| True |
| availability_zone_hints | |
| availability_zones| nova |
| created_at| 2017-07-21T17:31:23Z |
| description |
[Yahoo-eng-team] [Bug 1670770] Re: Warnings found when importing API Definitions from neutron-lib
Unable to reproduce. Tried running py27 with fwaas and a few others, but didn't see the WARNING called out in this bug. If I'm missing some details to reproduce, please provide them and reopen. ** Changed in: neutron Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1670770 Title: Warnings found when importing API Definitions from neutron-lib Status in neutron: Invalid Bug description: Issue: While executing tox -v e py27 on a patch set, I found the following issue: http://paste.openstack.org/show/601800/ Expected Result: No warning logs should be generated when loading only definitions from neutron-lib as they do not have Class name which an extension expects To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1670770/+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 1698907] [NEW] [RFE] Add 'api_status' attribute to API extensions
Public bug reported:
This is a feature request for API extensions.
Based on the discussion in [1], it seems there maybe some use in
introducing a 'api_status' attribute on all API extensions. This
attribute would be defined in the API's definition
(neutron_lib.api.defintions.) and would be returned in the
extension body(s) for GETs (/v2.0/extensions, /v2.0/extensions/{alias}).
The api_status should be a static set of values. For example:
- EXPERIMENTAL --> The API is in "beta mode" and not fully hardened.
- SUPPORTED --> Current supported API.
- DEPRECATED --> The API is not actively supported any maybe removed in a
future release.
[1] https://review.openstack.org/#/c/415817/
** Affects: neutron
Importance: Undecided
Status: New
** Tags: rfe
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1698907
Title:
[RFE] Add 'api_status' attribute to API extensions
Status in neutron:
New
Bug description:
This is a feature request for API extensions.
Based on the discussion in [1], it seems there maybe some use in
introducing a 'api_status' attribute on all API extensions. This
attribute would be defined in the API's definition
(neutron_lib.api.defintions.) and would be returned in the
extension body(s) for GETs (/v2.0/extensions,
/v2.0/extensions/{alias}).
The api_status should be a static set of values. For example:
- EXPERIMENTAL --> The API is in "beta mode" and not fully hardened.
- SUPPORTED --> Current supported API.
- DEPRECATED --> The API is not actively supported any maybe removed in a
future release.
[1] https://review.openstack.org/#/c/415817/
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1698907/+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 1698364] [NEW] Intermittent gate failures due to host != standby
Public bug reported: A number of gate tests appear to be intermittently failing with:: testtools.matchers._impl.MismatchError: u'host0' != u'standby' For example [1][2]. 50 hits found in the last 7 days [3]. [1] http://logs.openstack.org/34/466434/5/check/gate-neutron-dsvm-functional-ubuntu-xenial/fec6b2d/console.html [2] http://logs.openstack.org/24/470024/3/gate/gate-neutron-dsvm-functional-ubuntu-xenial/b0e3747/testr_results.html.gz [3] http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22!%3D%20u'standby'%5C%22 ** Affects: neutron Importance: Undecided Status: New ** Tags: gate-failure -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1698364 Title: Intermittent gate failures due to host != standby Status in neutron: New Bug description: A number of gate tests appear to be intermittently failing with:: testtools.matchers._impl.MismatchError: u'host0' != u'standby' For example [1][2]. 50 hits found in the last 7 days [3]. [1] http://logs.openstack.org/34/466434/5/check/gate-neutron-dsvm-functional-ubuntu-xenial/fec6b2d/console.html [2] http://logs.openstack.org/24/470024/3/gate/gate-neutron-dsvm-functional-ubuntu-xenial/b0e3747/testr_results.html.gz [3] http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22!%3D%20u'standby'%5C%22 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1698364/+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 1693059] [NEW] Error: Systemd start for openstack-nova-scheduler failed!
Public bug reported:
following is the logs seeing on nova-scheduler.log:
2017-05-23 20:47:25.208 21042 WARNING oslo_reports.guru_meditation_report [-]
Guru meditation now registers SIGUSR1 and SIGUSR2 by default for backward
compatibility. SIGUSR1 will no longer be registered in a future release, so
please use SIGUSR2 to generate reports.
2017-05-23 20:47:25.210 21042 INFO oslo_service.periodic_task [-] Skipping
periodic task _discover_hosts_in_cells because its interval is negative
2017-05-23 20:47:25.394 21042 CRITICAL nova
[req-a14bbad7-1070-4595-b762-7fef5f394465 - - - - -] ProgrammingError:
(pymysql.err.ProgrammingError) (1146, u"Table 'nova.aggregates' doesn't exist")
[SQL: u'SELECT aggregates.created_at AS aggregates_created_at,
aggregates.updated_at AS aggregates_updated_at, aggregates.deleted_at AS
aggregates_deleted_at, aggregates.deleted AS aggregates_deleted, aggregates.id
AS aggregates_id, aggregates.uuid AS aggregates_uuid, aggregates.name AS
aggregates_name, aggregate_hosts_1.created_at AS aggregate_hosts_1_created_at,
aggregate_hosts_1.updated_at AS aggregate_hosts_1_updated_at,
aggregate_hosts_1.deleted_at AS aggregate_hosts_1_deleted_at,
aggregate_hosts_1.deleted AS aggregate_hosts_1_deleted, aggregate_hosts_1.id AS
aggregate_hosts_1_id, aggregate_hosts_1.host AS aggregate_hosts_1_host,
aggregate_hosts_1.aggregate_id AS aggregate_hosts_1_aggregate_id,
aggregate_metadata_1.created_at AS aggregate_metadata_1_created_at,
aggregate_metadata_1.updat
ed_at AS aggregate_metadata_1_updated_at, aggregate_metadata_1.deleted_at AS
aggregate_metadata_1_deleted_at, aggregate_metadata_1.deleted AS
aggregate_metadata_1_deleted, aggregate_metadata_1.id AS
aggregate_metadata_1_id, aggregate_metadata_1.`key` AS
aggregate_metadata_1_key, aggregate_metadata_1.value AS
aggregate_metadata_1_value, aggregate_metadata_1.aggregate_id AS
aggregate_metadata_1_aggregate_id \nFROM aggregates LEFT OUTER JOIN
aggregate_hosts AS aggregate_hosts_1 ON aggregates.id =
aggregate_hosts_1.aggregate_id AND aggregate_hosts_1.deleted = %(deleted_1)s
AND aggregates.deleted = %(deleted_2)s LEFT OUTER JOIN aggregate_metadata AS
aggregate_metadata_1 ON aggregates.id = aggregate_metadata_1.aggregate_id AND
aggregate_metadata_1.deleted = %(deleted_3)s AND aggregates.deleted =
%(deleted_4)s \nWHERE aggregates.deleted = %(deleted_5)s'] [parameters:
{u'deleted_5': 0, u'deleted_4': 0, u'deleted_3': 0, u'deleted_2': 0,
u'deleted_1': 0}]
2017-05-23 20:47:25.394 21042 ERROR nova Traceback (most recent call last):
2017-05-23 20:47:25.394 21042 ERROR nova File "/usr/bin/nova-scheduler", line
10, in
2017-05-23 20:47:25.394 21042 ERROR nova sys.exit(main())
2017-05-23 20:47:25.394 21042 ERROR nova File
"/usr/lib/python2.7/site-packages/nova/cmd/scheduler.py", line 44, in main
2017-05-23 20:47:25.394 21042 ERROR nova topic=CONF.scheduler_topic)
2017-05-23 20:47:25.394 21042 ERROR nova File
"/usr/lib/python2.7/site-packages/nova/service.py", line 241, in create
2017-05-23 20:47:25.394 21042 ERROR nova
periodic_interval_max=periodic_interval_max)
2017-05-23 20:47:25.394 21042 ERROR nova File
"/usr/lib/python2.7/site-packages/nova/service.py", line 117, in __init__
2017-05-23 20:47:25.394 21042 ERROR nova self.manager =
manager_class(host=self.host, *args, **kwargs)
2017-05-23 20:47:25.394 21042 ERROR nova File
"/usr/lib/python2.7/site-packages/nova/scheduler/manager.py", line 57, in
__init__
"nova-scheduler-stackpack.log" 32650L, 4774686C
2017-05-23 21:08:36.300 39408 ERROR nova File
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/query.py", line 2751, in
_execute_and_instances
2017-05-23 21:08:36.300 39408 ERROR nova result =
conn.execute(querycontext.statement, self._params)
2017-05-23 21:08:36.300 39408 ERROR nova File
"/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 914, in
execute
2017-05-23 21:08:36.300 39408 ERROR nova return meth(self, multiparams,
params)
2017-05-23 21:08:36.300 39408 ERROR nova File
"/usr/lib64/python2.7/site-packages/sqlalchemy/sql/elements.py", line 323, in
_execute_on_connection
2017-05-23 21:08:36.300 39408 ERROR nova return
connection._execute_clauseelement(self, multiparams, params)
2017-05-23 21:08:36.300 39408 ERROR nova File
"/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 1010, in
_execute_clauseelement
2017-05-23 21:08:36.300 39408 ERROR nova compiled_sql, distilled_params
2017-05-23 21:08:36.300 39408 ERROR nova File
"/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 1146, in
_execute_context
2017-05-23 21:08:36.300 39408 ERROR nova context)
2017-05-23 21:08:36.300 39408 ERROR nova File
"/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 1337, in
_handle_dbapi_exception
2017-05-23 21:08:36.300 39408 ERROR nova util.raise_from_cause(newraise,
exc_info)
2017-05-23 21:08:36.300 39408 ERROR nova File
"/usr/lib64/pyt
[Yahoo-eng-team] [Bug 1642426] Re: attributes.PLURALS is never used
** Changed in: neutron Status: Fix Committed => 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/1642426 Title: attributes.PLURALS is never used Status in neutron: Fix Released Bug description: PLURALS in neutron/api/v2/attributes.py is written to but never read from. Let's remove it. This change must be co-ordinated across subprojects that consume neutron. Bug tagged with 'lib' because the entire neutron/api/v2/attributes.py will be rehomed to neutron-lib once PLURALS is removed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1642426/+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 1669528] [NEW] portbinding update fails with ObjectDeletedError
Public bug reported: The gate-tempest-dsvm-neutron-linuxbridge-ubuntu-xenial gate failed in a recent neutron change [1]. Digging into the logs [2] it appears to be DB related:: -- 2017-03-01 15:47:17.800 1412 ERROR oslo_messaging.rpc.server ObjectDeletedError: Instance '' has been deleted, or its row is otherwise not present. -- Based on logstash [3], this appears to be a frequent error. It's not clear to me if neutron is really the issue here, or if something else is happening and causing the neutron error. [1] https://review.openstack.org/#/c/422210/ [2] http://logs.openstack.org/10/422210/9/check/gate-tempest-dsvm-neutron-linuxbridge-ubuntu-xenial/f639199/logs/screen-q-svc.txt.gz? [3] http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22ObjectDeletedError%5C%22 ** Affects: neutron Importance: Undecided Status: New ** Tags: gate-failure -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1669528 Title: portbinding update fails with ObjectDeletedError Status in neutron: New Bug description: The gate-tempest-dsvm-neutron-linuxbridge-ubuntu-xenial gate failed in a recent neutron change [1]. Digging into the logs [2] it appears to be DB related:: -- 2017-03-01 15:47:17.800 1412 ERROR oslo_messaging.rpc.server ObjectDeletedError: Instance '' has been deleted, or its row is otherwise not present. -- Based on logstash [3], this appears to be a frequent error. It's not clear to me if neutron is really the issue here, or if something else is happening and causing the neutron error. [1] https://review.openstack.org/#/c/422210/ [2] http://logs.openstack.org/10/422210/9/check/gate-tempest-dsvm-neutron-linuxbridge-ubuntu-xenial/f639199/logs/screen-q-svc.txt.gz? [3] http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22ObjectDeletedError%5C%22 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1669528/+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 1664534] [NEW] [RFE] Auto allocated topology with no SNAT
Public bug reported: Today the neutron auto-allocated-topology (aka "get me a network") plugin/service allocates a router using the default enable_snat value for routers (True); so the resulting topology always has SNAT enabled. Some deployments would benefit from the ability to provision auto-allocated topologies that disable SNAT routing directly into the address space of the external network. One such way to support this ability would be to provide a simple configuration option such as `auto_topology_enable_snat` that's used by the service plugin when provisioning the router (for `enable_snat`). This would allow deployers the ability to configure the default SNAT behavior for auto-allocated topologies. ** Affects: neutron Importance: Undecided Status: New ** Tags: auto-allocated-topology rfe -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1664534 Title: [RFE] Auto allocated topology with no SNAT Status in neutron: New Bug description: Today the neutron auto-allocated-topology (aka "get me a network") plugin/service allocates a router using the default enable_snat value for routers (True); so the resulting topology always has SNAT enabled. Some deployments would benefit from the ability to provision auto-allocated topologies that disable SNAT routing directly into the address space of the external network. One such way to support this ability would be to provide a simple configuration option such as `auto_topology_enable_snat` that's used by the service plugin when provisioning the router (for `enable_snat`). This would allow deployers the ability to configure the default SNAT behavior for auto-allocated topologies. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1664534/+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 1656355] Re: The py-modindex for networking-bgpvpn docs is a broken link
Nothing to do in the neutron project; closing that side of the bug. ** Changed in: neutron Status: In Progress => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1656355 Title: The py-modindex for networking-bgpvpn docs is a broken link Status in networking-bgpvpn: Fix Released Status in neutron: Invalid Bug description: The Module Index link on this page: http://docs.openstack.org/developer/networking-bgpvpn/ Is giving a 404 error. To manage notifications about this bug go to: https://bugs.launchpad.net/bgpvpn/+bug/1656355/+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 1251224] Re: ICMP security group rules should have a type and code params instead of using "--port-range-min" and "--port-range-max"
Moving to invalid/unassigned and will timeout in 60 days as-is. If additional work is needed and in scope please reassign. ** Changed in: neutron Status: Confirmed => Invalid ** Changed in: neutron Importance: Medium => Undecided ** Changed in: neutron Assignee: Anthony Chow (vcloudernbeer) => (unassigned) ** Changed in: neutron Status: Invalid => Incomplete -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1251224 Title: ICMP security group rules should have a type and code params instead of using "--port-range-min" and "--port-range-max" Status in neutron: Incomplete Bug description: Version == Havana on rhel Description = I couldn't find a doc specifying whether icmp security group rules ignore the "--port-range-min" and "--port-range-max" params or use then as code and type as we know from nova security group rules. I think that it should be: i. Well documented. ii. prohibited for use of "--port-range-min" and "--port-range-max" in icmp rules context, new switches should be created for code and type. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1251224/+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 1537315] Re: Make advertisement intervals for radvd configurable
OpenStack manual's config reference already includes these [1]. The neutron patch contained a release note. Best I can tell no neutron or other work is needed here. [1] http://docs.openstack.org/newton/config-reference/networking/networking_options_reference.html ** Changed in: neutron Status: Fix Committed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1537315 Title: Make advertisement intervals for radvd configurable Status in neutron: Invalid Bug description: https://review.openstack.org/265451 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit d9e4d20da86f29f7ebdb3c6b07086924888edd39 Author: Sean M. Collins Date: Fri Jan 8 13:32:14 2016 -0800 Make advertisement intervals for radvd configurable Currently a global setting that is applied for all managed radvd processes. Per-process setting could be done in the future. For large clouds, it may be useful to increase the intervals, to reduce multicast storms. Co-Authored-By: Brian Haley DocImpact Router advertisement intervals for radvd are now configurable Related-Bug: #1532338 Change-Id: I6cc313599f0ee12f7d51d073a22321221fca263f To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1537315/+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 1551368] Re: L7 capability extension implementation for lbaas v2
Marking this as incomplete with the following reasoning: - The openstack-manuals team marked it as invalid and thus don't plan to update the docs/manuals. - Unless we have someone willing to create/drive the change into the openstack-manuals, I don't see how this will get done. If we have someone to work on it, please feel free to restore out of invalid state. ** Changed in: neutron Status: Confirmed => Incomplete ** Changed in: neutron Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1551368 Title: L7 capability extension implementation for lbaas v2 Status in neutron: Won't Fix Status in openstack-api-site: Invalid Status in openstack-manuals: Invalid Bug description: https://review.openstack.org/148232 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. commit 254190b3051453f823dbdf1826f1a6b984c57164 Author: Evgeny Fedoruk Date: Mon Jan 19 03:47:39 2015 -0800 L7 capability extension implementation for lbaas v2 Including extension modifications Including db model modifications Including alembic migration Including new driver managers for l7 rules and policies Inclufing logging_noop driver implementation Including unit testing Including Octavia driver updates DocImpact APIImpact Change-Id: I8f9535ebf28155adf43ebe046d2dbdfa86c4d81b Implements: blueprint lbaas-l7-rules Co-Authored-By: Evgeny Fedoruk Co-Authored-By: Stephen Balukoff To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1551368/+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 1552077] Re: [api-ref]Use network RBAC feature for external access
The original patch included a release note. The networking guide is already updated to include documentation on access_as_external [1]. That said I don't see any work left here. Closing out as invalid. [1] http://docs.openstack.org/newton/networking-guide/config-rbac.html#allowing-a-network-to-be-used-as-an-external-network ** Changed in: neutron Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1552077 Title: [api-ref]Use network RBAC feature for external access Status in neutron: Invalid Status in openstack-api-site: Invalid Bug description: https://review.openstack.org/282295 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit 49b4dd3478d782aee4260033825aa6b47eaf644a Author: Kevin Benton Date: Fri Feb 19 03:34:27 2016 -0800 Use network RBAC feature for external access This allows access to external networks to be controlled via the RBAC framework added during Liberty with a new 'access_as_external' action. A migration adds all current external networks to the RBAC policies table with a wildcard indicating that all tenants can access the network as RBAC. Unlike the conversion of shared networks to RBAC, the external table is left in the DB to avoid invasive changes throughout the codebase to calculate the flag relative to the caller. So the current 'external' flag is used throughout the code base as it previously was for wiring up floating IPs, router gateway ports, etc. Then the RBAC entries are only referenced when determining what networks to show the tenants. API Behavior: * Marking a network as 'external' will automatically create a wildcard entry that allows that network to be accessed by all tenants. * An external network may have all of its RBAC entries deleted and then only an admin will be able to attach to it. * An RBAC 'access_as_external' entry cannot be deleted if it is required for a tenant that currently has a router attached to that network. * Creating an 'access_as_external' RBAC entry will automatically convert the network into an external network. (This is to enable a workflow where a private external network is never visible to everyone.) * The default policy.json will prevent a non-admin from creating wildcard 'access_as_external' RBAC entries to align with the current default policy we have on setting the 'external' field on the network to prevent poluting everyone else's network lists. * The default policy.json will allow a tenant to create an 'access_as_external' RBAC entry to allow specific tenants (including itself) the ability to use its network as an external network. Closes-Bug: #1547985 DocImpact: External networks can now have access restricted to small subsets of tenants APIImpact: 'access_as_external' will be allowed as an action in the RBAC API for networks Change-Id: I4d8ee78a9763c58884e4fd3d7b40133da659cd61 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1552077/+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 1553451] Re: Add timestamp for neutron core resources
Based on [1] this has already been fixed in the api-ref. Nothing else to do from a neutron perspective, so closing out. [1] https://developer.openstack.org/api-ref/networking/v2/?expanded=show-network-details-provider-network-detail,show-network-details-detail,show-port-details-detail ** Changed in: neutron Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1553451 Title: Add timestamp for neutron core resources Status in neutron: Invalid Status in openstack-api-site: Fix Released Bug description: https://review.openstack.org/213586 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit 4c2c983618ddb7a528c9005b0d7aaf5322bd198d Author: ZhaoBo Date: Thu Feb 18 13:28:58 2016 +0800 Add timestamp for neutron core resources Currently, neutron core resources (like net, subnet, port and subnetpool) do not save time-stamps upon their creation and updation. This information can be critical for debugging purposes. This patch introduces a new extension called "timestamp" extending existing the neutron core resources to allow their creation and modification times to be record. Now this patch add this resource schema and the functions which listen db events to add timestamp fields. APIImpact DocImpact: Neutron core resources now contain 'timestamp' fields like 'created_at' and 'updated_at' Change-Id: I24114b464403435d9c1e1e123d2bc2f37c8fc6ea Partially-Implements: blueprint add-port-timestamp To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1553451/+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 1570026] Re: Add an option for WSGI pool size
The manual's config reference is already updated [1]. The original patch already included a release note [2]. Marking as invalid as I don't see any work left here. [1] http://docs.openstack.org/newton/config-reference/networking/networking_options_reference.html#api [2] https://review.openstack.org/#/c/278007/ ** Changed in: neutron Status: Fix Committed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1570026 Title: Add an option for WSGI pool size Status in neutron: Invalid Bug description: https://review.openstack.org/278007 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit 9d573387f1e33ce85269d3ed9be501717eed4807 Author: Mike Bayer Date: Tue Feb 9 13:10:57 2016 -0500 Add an option for WSGI pool size Neutron currently hardcodes the number of greenlets used to process requests in a process to 1000. As detailed in http://lists.openstack.org/pipermail/openstack-dev/2015-December/082717.html this can cause requests to wait within one process for available database connection while other processes remain available. By adding a wsgi_default_pool_size option functionally identical to that of Nova, we can lower the number of greenlets per process to be more in line with a typical max database connection pool size. DocImpact: a previously unused configuration value wsgi_default_pool_size is now used to affect the number of greenlets used by the server. The default number of greenlets also changes from 1000 to 100. Change-Id: I94cd2f9262e0f330cf006b40bb3c0071086e5d71 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1570026/+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 1570892] Re: [api-ref]Openswan/Libreswan: support sha256 for auth algorithm
sha256 has already been added to the API ref [1]. Marking as invalid. [1] https://developer.openstack.org/api-ref/networking/v2/?expanded =show-ipsec-policy-detail ** Changed in: neutron Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1570892 Title: [api-ref]Openswan/Libreswan: support sha256 for auth algorithm Status in neutron: Invalid Bug description: https://review.openstack.org/303684 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. commit b73e1002555cfa70ccfea8ffe685672c0b679212 Author: nick.zhuyj Date: Fri Apr 8 23:48:33 2016 -0500 Openswan/Libreswan: support sha256 for auth algorithm Add support for sha256 as it is requirement from customer. Currently, there is no ike/esp fields in strongswan ipsec.conf template, so by default. sha256 is used. But for openswan auth algorithm is get from configuration, so only sha1 is supported. This patch enable Openswan/Libreswan to support sha256. Note: this change is DocImpact and APIImpact Change-Id: I02c80ec3494eb0edef2fdaa5d21ca0c3bbcacac2 Closes-Bug: #1567846 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1570892/+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 1577289] Re: Ensure floating IPs only use IPv4 addresses
>From a neutron perspective I'm not seeing anything needed. However from an openstack-manuals POV it seems like we should note the IPv4 requirement for floating IPs (e.g. can't create floating IPs on net with no IPv4 subnets, etc. see commit message for more details). When searching the openstack docs I didn't find anything current talking about floating IPs, other than [1] (I think [1] is older). Moving this over to openstack-manuals in hopes we can find somewhere to mention this requirement for floating IPs. [1] http://docs.openstack.org/admin-guide/cli-admin-manage-ip-addresses.html ** Changed in: neutron Status: Triaged => New ** Changed in: neutron Importance: Low => Undecided ** Changed in: neutron Assignee: Dustin Lundquist (dlundquist) => (unassigned) ** Project changed: neutron => openstack-manuals -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1577289 Title: Ensure floating IPs only use IPv4 addresses Status in openstack-manuals: New Bug description: https://review.openstack.org/267891 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit 4858cd7cb97354ae54f8e7d47aeaaddad714c9dd Author: Dustin Lundquist Date: Mon Jul 6 13:53:46 2015 -0700 Ensure floating IPs only use IPv4 addresses Description: Presently Neutron doesn't validate the address family of floating IP addresses or the internal addresses they are associated with. It merely associates the first IP of the floating IP's port with the first IP of the internal port, unless a specified fixed IP is specified. This can lead to incorrect or poorly defined behavior when IPv6 is present. The existing L3 agent implementation only manages IPv4 NAT rules. While IPv6 NAT and NAT protocol translation are possible, the existing implementation does not support these configurations. Presently a floating IP can be created on an IPv6 only external network or associated with an IPv6 fixed IP, but the L3 agent is unable to bind these configurations. Implementation: When creating and updating a floating IP, only consider IPv4 addresses on both the floating IPs port and the internal port he floating IP is associated with. Additionally disallow creating floating IPs on networks without any IPv4 subnets, since these floating IPs could not be allocated an IPv4 address. DocImpact APIImpact Co-Authored-By: Bradley Jones Change-Id: I79b28a304b38ecdafc17eddc41213df1c24ec202 Related-Bug: #1437855 Closes-Bug: #1323766 Closes-Bug: #1469322 (cherry picked from commit 4cdc71e7d0e5220a5f12ee2dfea1ff3db045c041) To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-manuals/+bug/1577289/+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 1595706] Re: Remove the deprecated config 'router_id'
As per comment #2, a docs change already landed. I also confirmed in the newton L3 agent config docs; the opt is not there. Nothing left to do from a neutron POV so closing out. ** Changed in: neutron Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1595706 Title: Remove the deprecated config 'router_id' Status in neutron: Invalid Status in openstack-manuals: Fix Released Bug description: https://review.openstack.org/332018 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit 448bc8e5220d3633f9c9ee804de0a38c2d829d78 Author: Hong Hui Xiao Date: Tue Jun 21 08:49:42 2016 + Remove the deprecated config 'router_id' It was deprecated at [1]. Remove the deprecated config 'router_id' and its related tests. [1] https://review.openstack.org/#/c/248498 DocImpact: All references of 'router_id' configuration option and its description should be removed from the docs. UpgradeImpact: Remove 'router_id' configuration option from the l3_agent.ini. Change-Id: Ic9420191e8c1a333e4dcc0b70411591b8573ec7c Closes-Bug: #1594711 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1595706/+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 1600405] Re: Remove the deprecated config "quota_items"
quota_items was removed from the manuals with [1] and I couldn't find any other refs to it in the newton docs (to confirm). >From a neutron POV I don't see anything left to do. [1] https://review.openstack.org/#/c/344325/ ** Changed in: neutron Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1600405 Title: Remove the deprecated config "quota_items" Status in neutron: Invalid Bug description: https://review.openstack.org/331591 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit ff73054e8637f29737cc65dc84ef0f9aea9d5abd Author: Hong Hui Xiao Date: Mon Jun 20 09:46:21 2016 + Remove the deprecated config "quota_items" It was deprecated at [1], and quota of resource will be registered at initialization of APIRouter. So, no need to use the config now. [1] https://review.openstack.org/#/c/181593 DocImpact: All references of 'quota_items' configuration option and its description should be removed from the docs. UpgradeImpact: Remove 'quota_items' configuration option from neutron.conf file. Change-Id: I0698772a49f51d7c65f1f4cf1ea7660cd07113a0 Closes-Bug: #1593772 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1600405/+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 1605793] Re: Calculate MTU on every network fetch instead of on create
Manuals have already been updated (see comment #2). >From a neutron POV, the initial patch [1] already contained a release note. Marking as invalid from a neutron perspective since nothing else appears to be needed. [1] https://review.openstack.org/#/c/336805/ ** Changed in: neutron Status: Incomplete => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1605793 Title: Calculate MTU on every network fetch instead of on create Status in neutron: Invalid Status in openstack-manuals: Fix Released Bug description: https://review.openstack.org/336805 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit a984f9554cdcbe93c840a1d8f5c04302e9331e79 Author: Ihar Hrachyshka Date: Sat Jul 2 17:30:21 2016 +0200 Calculate MTU on every network fetch instead of on create Today, existing networks may not reflect MTU configured for neutron-server, if they were created when neutron-server was using different MTU setup for its infrastructure, or when it was using bad default values for network MTUs (specifically, before Mitaka, all networks were getting MTU = 0 by default, disabling both advertisement and data path MTU size enforcement). This patch stops persisting MTU in the database on network create and instead calculate it on every network resource fetch. DocImpact Now changes to MTU configuration options immediately affect existing network MTUs, not just new networks. UpgradeImpact Existing networks with invalid MTU persisted in database may change their MTU values to reflect configuration. Change-Id: Iee4f5037bf10b73ba98464143b183aacb59c22f2 Closes-Bug: #1556182 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1605793/+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 1607724] Re: OVS Mech: Set hybrid plug based on agent config
While a networking guide change did go out for this (see comment #3), after looking at what we have in this regard I still feel the docs are confusing. As a result I generated another openstack-manuals defect [1]. >From a neutron perspective I'm not seeing other docs needed; if a devref was required it should'be been with the implementation patch unless otherwise noted so I'm closing out the neutron side. [1] https://bugs.launchpad.net/openstack-manuals/+bug/1660687 ** Changed in: neutron Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1607724 Title: OVS Mech: Set hybrid plug based on agent config Status in neutron: Invalid Status in openstack-manuals: Fix Released Bug description: https://review.openstack.org/327996 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit 7a969d4b0a5ae902695b3204a858305b5122c5ff Author: Kevin Benton Date: Fri Apr 29 18:01:51 2016 -0700 OVS Mech: Set hybrid plug based on agent config This adjusts the logic in the OVS mechanism driver to determine what the ovs_hybrid_plug value should be set to in the VIF details. Previously it was based purely on the firewall driver configured on the server side. This prevented a mixed environment where some agents might be running a native OVS firewall driver while others are still based on the IPTables hybrid driver. This patch has the OVS agents report back whether they want hybrid plugging in their configuration dictionary sent during report_state. The OVS agent sets this based on an explicit attribute on the firewall driver requesting OVS hybrid plugging. To maintain backward compat, if an agent doesn't report this, the old logic of basing it off of the server-side config is applied. DocImpact: The server no longer needs to be configured with a firewall driver for OVS. It will read config from agent state reports. Closes-Bug: #1560957 Change-Id: Ie554c2d37ce036e7b51818048153b466eee02913 (cherry picked from commit 2f17a30ba04082889f3a703aca1884b031767942) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1607724/+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
