[Yahoo-eng-team] [Bug 1862374] Re: Neutron incorrectly selects subnet
[Expired for neutron because there has been no activity for 60 days.] ** Changed in: neutron Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1862374 Title: Neutron incorrectly selects subnet Status in neutron: Expired Bug description: Distro bionic Openstack version: openstack testing cloud When using the command openstack server add floating ip --fixed-ip-address 10.66.0.18 juju- 53a7bc-north-0 10.245.163.125 for the following machine ubuntu@dmzoneill-bastion:~$ openstack server list -c ID -c Name -c Networks +--+--+-+ | ID | Name | Networks | +--+--+-+ | 063c2e8e-4d57-4267-a506-4c7b336e71b6 | juju-53a7bc-north-0 | north=10.66.0.18; south=10.55.0.9 | | 670bd827-f570-439f-b17f-91710849 | juju-6de968-south-0 | south=10.55.0.4 | | 0cd3c498-2826-4868-9384-e12e0799f903 | juju-855490-default-0| dmzoneill_admin_net=10.5.0.6| | 0b72ccd8-b694-45c7-86be-870511426140 | juju-370447-controller-0 | north=10.66.0.14; south=10.55.0.3; dmzoneill_admin_net=10.5.0.8 | | 40c68cb2-4e20-4d15-a82c-4c4252b8a0da | dmzoneill-bastion| dmzoneill_admin_net=10.5.0.7, 10.245.162.200| +--+--+-+ Neutron returns the error GET call to network for http://10.245.161.159:9696/v2.0/ports?device_id=063c2e8e-4d57-4267-a506-4c7b336e71b6 used request id req-d915168a-32c6-4c74-9a83-1ef090b376d8 Manager serverstack ran task network.GET.ports in 0.122786998749s Manager serverstack running task network.PUT.floatingips REQ: curl -g -i -X PUT http://10.245.161.159:9696/v2.0/floatingips/0c771099-ca95-4447-8a60-5f64a590d943 -H "User-Agent: osc-lib/1.9.0 keystoneauth1/3.4.0 python-requests/2.18.4 CPython/2.7.15+" -H "Content-Type: application/json" -H "X-Auth-Token: {SHA1}9cf2688baf3b5c3e5dea7e2f7faa6554ee1b6bfb" -d '{"floatingip": {"fixed_ip_address": "10.66.0.18", "port_id": "6f8626ba-ae8c-492a-93ad-3f349c600a3b"}}' http://10.245.161.159:9696 "PUT /v2.0/floatingips/0c771099-ca95-4447-8a60-5f64a590d943 HTTP/1.1" 400 169 RESP: [400] Content-Type: application/json Content-Length: 169 X-Openstack-Request-Id: req-1a8be2ec-456e-483d-a4e0-5ab204c55c2d Date: Fri, 07 Feb 2020 14:45:13 GMT Connection: keep-alive RESP BODY: {"NeutronError": {"message": "Bad floatingip request: Port 6f8626ba-ae8c-492a-93ad-3f349c600a3b does not have fixed ip 10.66.0.18.", "type": "BadRequest", "detail": ""}} Neutron seems to look at the list of networks associated with server and pops the last network (south) from the list. Enutron selects the port south 6f8626ba-ae8c-492a-93ad-3f349c600a3b which is not in that subnet and errors ubuntu@dmzoneill-bastion:~$ openstack port list -c ID -c "Fixed IP Addresses" +--+---+ | ID | Fixed IP Addresses | +--+---+ | 1ad11c89-8574-49fc-9efe-b4a0b73b01eb | ip_address='10.55.0.2', subnet_id='eec9530d-df77-41eb-8e85-9ef6e45931a7' | | 36b16756-01fe-49c7-9e14-41abaf0059f9 | ip_address='10.5.0.8', subnet_id='7edee502-ab23-46af-b446-17c233d11a94' | | 3e20a885-6421-4acd-b936-56b3bcb4930f | ip_address='10.5.0.6', subnet_id='7edee502-ab23-46af-b446-17c233d11a94' | | 410beab6-c2ed-4d31-bc3d-4457a3c28b5f | ip_address='10.55.0.4', subnet_id='eec9530d-df77-41eb-8e85-9ef6e45931a7' | | 4e1defd4-1185-4f54-bb93-768dbf8d6436 | ip_address='10.66.0.14', subnet_id='fe280e59-e8e0-4cdc-923a-1b15e45b95ce' | | 56d6a38d-0698-491b-9996-b239a7d95d5b | ip_address='10.55.0.3', subnet_id='eec9530d-df77-41eb-8e85-9ef6e45931a7' | | 67558707-ed0b-47b6-be0e-0da0bf2871b5 | ip_address='10.66.0.2', subnet_id='fe280e59-e8e0-4cdc-923a-1b15e45b95ce' | | 6d3c6101-75c3-47d0-a496-83cc62092f2d | ip_address='10.5.0.7', subnet_id='7edee502-ab23-46af-b446-17c233d11a94' | | 6f8626ba-ae8c-492a-93ad-3f349c600a3b | ip_address='10.55.0.9', subnet_id='eec9530d-df77-41eb-8e85-9ef6e45931a7' | | 778899dd-7c15-47a9-8968-261088aa14bf | ip_address='10.66.0.18', subnet_id='fe280e59-e8e0-4cdc-923a-1b15e45b95c
[Yahoo-eng-team] [Bug 1778563] Re: Resize/Cold-migrate doesn't recreate vGPUs
Reviewed: https://review.opendev.org/712741 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=d2e0afc1f72db5cb56ed987e2873798fc1e89545 Submitter: Zuul Branch:master commit d2e0afc1f72db5cb56ed987e2873798fc1e89545 Author: Sylvain Bauza Date: Thu Mar 12 18:06:36 2020 +0100 Allocate mdevs when resizing or reverting resize Now that allocations are passed to the methods, we can ask whether we need to use mediated devices for the instance. Adding a large functional test for verifying it works. Change-Id: I018762335b19c98045ad42147080203092b51c27 Closes-Bug: #1778563 ** Changed in: nova Status: In Progress => Fix Released -- 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/1778563 Title: Resize/Cold-migrate doesn't recreate vGPUs Status in OpenStack Compute (nova): Fix Released Bug description: When resizing an instance having vGPUs, the resized instance will miss them even if the related allocations have VGPU resources. The main problem is that we're not passing allocations down to the virt drivers when finish_migration(). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1778563/+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 1869306] Re: Users module errors for users of same SSH key type with existing user
Actually I think that may have been a red herring, I think "- name:trent" was the actual problem: that's parsed as ["name:trent"], not {"name": "trent"}. Which then means that the parser expects the following line to be a list item, and it's a mapping item, hence the blow up. Regardless, glad you got this sorted! ** Changed in: cloud-init Status: Incomplete => Invalid -- 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/1869306 Title: Users module errors for users of same SSH key type with existing user Status in cloud-init: Invalid Bug description: I'm starting an instance (tried both centos and ubuntu) in AWS with user_data similar to the following: users: - name: bob sudo: ALL=(ALL) NOPASSWD:ALL groups: users lock_passwd: true ssh_authorized_keys: - ssh-rsa some-ssh-pubkey-x - name: alice sudo: ALL=(ALL) NOPASSWD:ALL groups: users lock_passwd: true ssh_authorized_keys: - ssh-rsa some-ssh-pubkey-x - name: mallory sudo: ALL=(ALL) NOPASSWD:ALL groups: users lock_passwd: true ssh_authorized_keys: - ssh-rsa some-ssh-pubkey-x - name: trent sudo: ALL=(ALL) NOPASSWD:ALL groups: users lock_passwd: true ssh_authorized_keys: - ssh-ed25519 some-ssh-pubkey-x Two things are special in this case. Mallory made herself a user account on the box before baking the original image, and Trent has an ECC key (the rest are using RSA). Upon running this in AWS, only Trent gets created. The only discernible error I have seen is: File "/usr/lib/python2.7/site-packages/cloudinit/ssh_util.py", line 208, in us ers_ssh_info pw_ent = pwd.getpwnam(username) KeyError: 'getpwnam(): name not found: alice' Trent can log in and see that his key has been created, but literally every other user who is using an RSA SSH key hasn't had their user created. Compounding it, Mallory doesn't have a login but still retains her home directory. The fix for this entails making a user "mallory2" and leaving mallory alone. When this happens, all users get created (though mallory's original account is missing other than /home). I've also tried making a mallory user with a custom homedir of /home/mallorytoo, but the same error happens. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1869306/+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 1848342] Re: Duplicated entries in users API
Reviewed: https://review.opendev.org/687990 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=7597ecc1350eb6918c09585e4116911102acb54a Submitter: Zuul Branch:master commit 7597ecc1350eb6918c09585e4116911102acb54a Author: Pedro Martins Date: Thu Oct 10 08:51:32 2019 -0300 Stop adding entry in local_user while updating ephemerals Problem description === Today we have a consistency problem when updating federated users via OpenStack. When I update a ephemeral user via OpenStack, a registry in the local_user table is created, making this user having entries in user, local_user and federated_user tables in the database. Furthermore, if I try to do some operations using this user (that has entries in all three tables), I get a "More than one user exists with the name ..." error from the OpenStack Keystone API. It happens because the user has an entry in both local_user and federated_user tables. I fix the persistence in the local_user table for ephemeral users when doing updates. Proposal I fix the problem with creating an entry in the local_user table while updating an ephemeral user Closes-Bug: #1848342 Change-Id: I2ac6e90f24b94dc5c0d9c0758f008a388597036c ** Changed in: keystone Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1848342 Title: Duplicated entries in users API Status in OpenStack Identity (keystone): Fix Released Bug description: System version == Keystone: 14.0.1 (Rocky) The error happens when I try to show a federated user via the user name as the key instead of using the ID Reproducing the error: == First of all, I created a user in my Identity Provider (Idp) that is configured my KeyStone instance. We use OpenID Connect protocol to create the federated environment. In this test, the user created is named as 'use_case'. At this moment, the user is not in the OpenStack database, just in the Idp (ephemeral user type). Authenticating with the ephemeral federated user: Let's see the database tables before the login process. Users already created in the Idp (before the login): select * from user; +--+---+-++-++---+ | id | extra | enabled | default_project_id | created_at | last_active_at | domain_id | +--+---+-++-++---+ | 1b0ed400ec974420a3574a8788acc795 | {}| 1 | NULL | 2019-09-16 20:06:39 | NULL | default | +--+---+-++-++---+ select * from local_user; +-+--+---+---+---++ | id | user_id | domain_id | name | failed_auth_count | failed_auth_at | +-+--+---+---+---++ | 1 | 1b0ed400ec974420a3574a8788acc795 | default | admin | 0 | NULL | +-+--+---+---+---++ select * from federated_user; Empty set (0.00 sec) So far, we have only the local user admin Then, we execute the login using the ephemeral user that we created in the IdP. Let's the database state after the first login: select * from user; +--+-+-++-++--+ | id | extra | enabled | default_project_id | created_at | last_active_at | domain_id| +--+-+-++-++--+ | 1b0ed400ec974420a3574a8788acc795 | {} | 1 | NULL | 2019-09-16 20:06:39 | NULL | default | | f0327d98278f4b1881aec9c051b027d3 | {"email": "use_c...@gmail.com"} | 1 | NULL | 2019-10-15 18:08:17 | NULL | d28c2423e9b546deb37a034bb2134f4d | +--+-+-++-
[Yahoo-eng-team] [Bug 1834659] Re: Volume not removed on instance deletion
Reviewed: https://review.opendev.org/669674 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=01c334cbdd859f4e486ac2c369a4bdb3ec7709cc Submitter: Zuul Branch:master commit 01c334cbdd859f4e486ac2c369a4bdb3ec7709cc Author: Francois Palin Date: Mon Jul 8 10:12:25 2019 -0400 Add retry to cinder API calls related to volume detach When shutting down an instance for which volume needs to be deleted, if cinder RPC timeout expires before cinder volume driver terminates connection, then an unknown cinder exception is received and the volume is not removed. This fix adds a retry mechanism directly in cinder API calls attachment_delete, terminate_connection, and detach. Change-Id: I3c9ae47d0ceb64fa3082a01cb7df27faa4f5a00d Closes-Bug: #1834659 ** Changed in: nova Status: In Progress => Fix Released -- 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/1834659 Title: Volume not removed on instance deletion Status in OpenStack Compute (nova): Fix Released Bug description: Description === When we deploy a non-ephemeral instance (i.e. Creating a new volume), and indicate "YES" in "Delete Volume on Instance delete",then delete the instance, and volume driver terminate connection in cinder takes too long to return, the volume is not removed. The volume status remains as "In-use" and "Attached to None on /dev/vda". For example: abcfa1db-1748-4f04-9a29-128cf22efcc5 - 130GiB In-use - Attached to None on /dev/vda Steps to reproduce == Please refer to this bug comment #2 below Expected result === Volume gets removed Actual result = Volume remains attached Environment === Issue was initially reported downstream against Newton release (see comment #1 below). Customer was using hitachi volume driver: volume_driver = cinder.volume.drivers.hitachi.hbsd.hbsd_fc.HBSDFCDriver As a note, the hitachi drivers are unsupported as of Pike (see cinder commit 595c8d3f8523a9612ccc64ff4147eab993493892 Issue was reproduced in a devstack environment runnning the Stein release. Volume driver used was lvm (devstack default) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1834659/+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 1863852] Re: [OVN]Could not support more than one qos rule in one policy
Reviewed: https://review.opendev.org/711317 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=b098239d72d79469677bdc1e45daf7454b2eeb47 Submitter: Zuul Branch:master commit b098239d72d79469677bdc1e45daf7454b2eeb47 Author: Rodolfo Alonso Hernandez Date: Wed Mar 4 16:39:35 2020 + Refactor OVN client QoS extension The QoS OVN client extension is moved to the ML2 driver. This extension is called from the OVN driver in the events of: - create port - update port - delete port - update network The QoS OVN client extension now can accept several rules per policy as documented in the SUPPORTED_RULES. The QoS OVN client extension can write one OVN QoS rule per flow direction and each OVN QoS rule register can hold both a bandwidth limit rule and a DSCP marking rule. The "update_policy" method is called from the OVN QoS driver, when a QoS policy or its rules are updated. The QoS OVN client extension updates the QoS OVN registers exclusively, based on the related events. Closes-Bug: #1863852 Change-Id: I4833ed0c9a2741bdd007d4ebb3e8c1cb4c30d4c7 ** 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/1863852 Title: [OVN]Could not support more than one qos rule in one policy Status in neutron: Fix Released Bug description: Currently,the networking-ovn doesn't consider such qos policy, which has both ingress and egress rule. So when we apply such policy to port or network, only one of them will works. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1863852/+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 1873910] [NEW] Nightly CI builds are failing because due to missing get_interfaces_by_mac mocking
Public bug reported: get_interfaces_by_mac is currently errorring on the system that runs cloud-init's nightly CI. This indicates missing mocking in the following tests: FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_context_devname FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_field FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_field_emptycontext FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_field_nonecontext FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_field_withdefaultvalue FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_field_withdefaultvalue_emptycontext FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_gateway FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_gateway6 FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip6 FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip6_dual FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip6_prefix FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip6_prefix_emptystring FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip6_ula FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip_emptystring FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_mask FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_mask_emptystring FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_mtu FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_nameservers FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_network FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_network_emptystring FAILED cloudinit/sources/tests/test_oracle.py::TestDataSourceOracle::test_network_cmdline FAILED cloudinit/sources/tests/test_oracle.py::TestDataSourceOracle::test_network_fallback (Sourced from https://jenkins.ubuntu.com/server/job/cloud-init-ci- nightly/712/.) ** Affects: cloud-init Importance: Undecided Assignee: Dan Watkins (daniel-thewatkins) Status: New ** Changed in: cloud-init Assignee: (unassigned) => Dan Watkins (daniel-thewatkins) -- 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/1873910 Title: Nightly CI builds are failing because due to missing get_interfaces_by_mac mocking Status in cloud-init: New Bug description: get_interfaces_by_mac is currently errorring on the system that runs cloud-init's nightly CI. This indicates missing mocking in the following tests: FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_context_devname FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_field FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_field_emptycontext FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_field_nonecontext FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_field_withdefaultvalue FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_field_withdefaultvalue_emptycontext FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_gateway FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_gateway6 FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip6 FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip6_dual FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip6_prefix FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip6_prefix_emptystring FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip6_ula FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip_emptystring FAILED tests/unittests/test_datasource/test_opennebula.py::TestOp
[Yahoo-eng-team] [Bug 1873776] Re: [stable/stein] Neutron-tempest-plugin jobs are failing due to wrong python version
** Changed in: neutron Status: Confirmed => Won't Fix ** Changed in: neutron Status: Won't Fix => In Progress ** Changed in: neutron Assignee: (unassigned) => Bernard Cafarelli (bcafarel) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1873776 Title: [stable/stein] Neutron-tempest-plugin jobs are failing due to wrong python version Status in neutron: In Progress Bug description: Issue like in https://b5dda6b7d9fe09cc6972-899ca8db232a7bf5fd9d6d869408b0bd.ssl.cf1.rackcdn.com/720051/1/check /neutron-tempest-plugin-api- stein/5a092fb/controller/logs/devstacklog.txt happens in all neutron- tempest-plugin jobs in stable/stein branch. Error: 2020-04-20 00:19:32.058 | Ignoring typed-ast: markers 'python_version == "3.6"' don't match your environment 2020-04-20 00:19:32.120 | Obtaining file:///opt/stack/neutron-tempest-plugin 2020-04-20 00:19:32.987 | neutron-tempest-plugin requires Python '>=3.6' but the running Python is 2.7.17 2020-04-20 00:19:33.080 | You are using pip version 9.0.3, however version 20.0.2 is available. 2020-04-20 00:19:33.080 | You should consider upgrading via the 'pip install --upgrade pip' command. I think it should be run with python 3.6 or we should use tag 0.9.0 which is last version with support for python 2.7 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1873776/+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 1873798] [NEW] test_multicast_between_vms_on_same_network failures
Public bug reported: There's at least two failures happening in the test_multicast_between_vms_on_same_network test #1. 2020-04-10 15:07:03.425451 | controller | {0} neutron_tempest_plugin.scenario.test_multicast.MulticastTestIPv4.test_multicast_between_vms_on_same_network ... SKIPPED: neutron_tempest_plugin.scenario.test_multicast.MulticastTestIPv4.test_multicast_between_vms_on_same_network [id-113486fc-24c9-4be4-8361-03b1c9892867] was marked as unstable because of bug 1850288, failure was: 'IPAddress' object has no attribute 'startswith' #2. neutron_tempest_plugin.scenario.test_multicast.MulticastTestIPv4.test_multicast_between_vms_on_same_network[id-113486fc-24c9-4be4-8361-03b1c9892867] was marked as unstable because of bug 1850288, failure was: Command 'sudo sh -eux' failed, exit status: 127, host: '10.0.0.247' script: bash ~/unregistered_traffic_receiver.sh stderr: + bash /root/unregistered_traffic_receiver.sh bash: /root/unregistered_traffic_receiver.sh: No such file or directory ** Affects: neutron Importance: Medium Assignee: Lucas Alvares Gomes (lucasagomes) Status: Confirmed ** Changed in: neutron Importance: Undecided => Medium ** Changed in: neutron Assignee: (unassigned) => Lucas Alvares Gomes (lucasagomes) ** 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/1873798 Title: test_multicast_between_vms_on_same_network failures Status in neutron: Confirmed Bug description: There's at least two failures happening in the test_multicast_between_vms_on_same_network test #1. 2020-04-10 15:07:03.425451 | controller | {0} neutron_tempest_plugin.scenario.test_multicast.MulticastTestIPv4.test_multicast_between_vms_on_same_network ... SKIPPED: neutron_tempest_plugin.scenario.test_multicast.MulticastTestIPv4.test_multicast_between_vms_on_same_network [id-113486fc-24c9-4be4-8361-03b1c9892867] was marked as unstable because of bug 1850288, failure was: 'IPAddress' object has no attribute 'startswith' #2. neutron_tempest_plugin.scenario.test_multicast.MulticastTestIPv4.test_multicast_between_vms_on_same_network[id-113486fc-24c9-4be4-8361-03b1c9892867] was marked as unstable because of bug 1850288, failure was: Command 'sudo sh -eux' failed, exit status: 127, host: '10.0.0.247' script: bash ~/unregistered_traffic_receiver.sh stderr: + bash /root/unregistered_traffic_receiver.sh bash: /root/unregistered_traffic_receiver.sh: No such file or directory To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1873798/+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 1873774] [NEW] clout-init does not apply network settings
Public bug reported: clout-init does not apply network settings however rest of the settings are applied. This is not in cloud but a VM on ESXi network: version: 2 ethernets: ens192: dhcp4: false dhcp6: false addresses: - 10.0.0.2 gateway4: 10.0.0.1 nameservers: search: [xyz.com] addresses: [10.0.0.1] ** 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/1873774 Title: clout-init does not apply network settings Status in cloud-init: New Bug description: clout-init does not apply network settings however rest of the settings are applied. This is not in cloud but a VM on ESXi network: version: 2 ethernets: ens192: dhcp4: false dhcp6: false addresses: - 10.0.0.2 gateway4: 10.0.0.1 nameservers: search: [xyz.com] addresses: [10.0.0.1] To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1873774/+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 1873776] [NEW] [stable/stein] Neutron-tempest-plugin jobs are failing due to wrong python version
Public bug reported: Issue like in https://b5dda6b7d9fe09cc6972-899ca8db232a7bf5fd9d6d869408b0bd.ssl.cf1.rackcdn.com/720051/1/check /neutron-tempest-plugin-api- stein/5a092fb/controller/logs/devstacklog.txt happens in all neutron- tempest-plugin jobs in stable/stein branch. Error: 2020-04-20 00:19:32.058 | Ignoring typed-ast: markers 'python_version == "3.6"' don't match your environment 2020-04-20 00:19:32.120 | Obtaining file:///opt/stack/neutron-tempest-plugin 2020-04-20 00:19:32.987 | neutron-tempest-plugin requires Python '>=3.6' but the running Python is 2.7.17 2020-04-20 00:19:33.080 | You are using pip version 9.0.3, however version 20.0.2 is available. 2020-04-20 00:19:33.080 | You should consider upgrading via the 'pip install --upgrade pip' command. I think it should be run with python 3.6 or we should use tag 0.9.0 which is last version with support for python 2.7 ** Affects: neutron Importance: Critical Status: Confirmed ** Tags: gate-failure tempest -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1873776 Title: [stable/stein] Neutron-tempest-plugin jobs are failing due to wrong python version Status in neutron: Confirmed Bug description: Issue like in https://b5dda6b7d9fe09cc6972-899ca8db232a7bf5fd9d6d869408b0bd.ssl.cf1.rackcdn.com/720051/1/check /neutron-tempest-plugin-api- stein/5a092fb/controller/logs/devstacklog.txt happens in all neutron- tempest-plugin jobs in stable/stein branch. Error: 2020-04-20 00:19:32.058 | Ignoring typed-ast: markers 'python_version == "3.6"' don't match your environment 2020-04-20 00:19:32.120 | Obtaining file:///opt/stack/neutron-tempest-plugin 2020-04-20 00:19:32.987 | neutron-tempest-plugin requires Python '>=3.6' but the running Python is 2.7.17 2020-04-20 00:19:33.080 | You are using pip version 9.0.3, however version 20.0.2 is available. 2020-04-20 00:19:33.080 | You should consider upgrading via the 'pip install --upgrade pip' command. I think it should be run with python 3.6 or we should use tag 0.9.0 which is last version with support for python 2.7 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1873776/+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 1873761] [NEW] Internal IP leak to physical interface from qrouter in DVR mode
Public bug reported: Setup: Openstack-Ansible cluster(Rocky - 18.1.8) with computes nodes using DVR. OS version Ubuntu 16.04.6 LTS with kernel 4.15.0-34-generic. Problem: We can see internal IP leaked without NAT on our physical interface. This happens in TCP communication where client stopped abruptly before the server. Steps to reproduce: TCP Client(192.168.100.24, 10.96.48.159) TCP Server(192.168.100.20, 10.96.48.207) Server sends RST packets on connection termination. Step1: Start the server and client. Setp2: Stop the client(KeyboardInterrupt) while the server is still in the connection. tcpdump on the bond interface of the compute node in which the tcp client is running 07:50:35.658208 IP 10.96.48.159.36394 > 10.96.48.207.5005: Flags [S], seq 3764020836, win 64240, options [mss 1460,sackOK,TS val 2823050719 ecr 0,nop,wscale 7], length 0 07:50:35.658539 IP 10.96.48.207.5005 > 10.96.48.159.36394: Flags [S.], seq 1750463809, ack 3764020837, win 65160, options [mss 1460,sackOK,TS val 2874529221 ecr 2823050719,nop,wscale 7], length 0 07:50:35.658717 IP 10.96.48.159.36394 > 10.96.48.207.5005: Flags [.], ack 1, win 502, options [nop,nop,TS val 2823050720 ecr 2874529221], length 0 07:50:35.658746 IP 10.96.48.159.36394 > 10.96.48.207.5005: Flags [P.], seq 1:14, ack 1, win 502, options [nop,nop,TS val 2823050720 ecr 2874529221], length 13 07:50:35.658949 IP 10.96.48.207.5005 > 10.96.48.159.36394: Flags [.], ack 14, win 509, options [nop,nop,TS val 2874529221 ecr 2823050720], length 0 07:50:35.659113 IP 10.96.48.159.36394 > 10.96.48.207.5005: Flags [P.], seq 14:32, ack 1, win 502, options [nop,nop,TS val 2823050720 ecr 2874529221], length 18 07:50:35.659299 IP 10.96.48.207.5005 > 10.96.48.159.36394: Flags [.], ack 32, win 509, options [nop,nop,TS val 2874529221 ecr 2823050720], length 0 07:50:40.729542 IP 10.96.48.159.36394 > 10.96.48.207.5005: Flags [F.], seq 32, ack 1, win 502, options [nop,nop,TS val 2823055790 ecr 2874529221], length 0 07:50:40.773484 IP 10.96.48.207.5005 > 10.96.48.159.36394: Flags [.], ack 33, win 509, options [nop,nop,TS val 2874534335 ecr 2823055790], length 0 07:53:35.732815 IP 10.96.48.207.5005 > 10.96.48.159.36394: Flags [P.], seq 1:21, ack 33, win 509, options [nop,nop,TS val 2874709290 ecr 2823055790], length 20 07:53:35.732878 IP 10.96.48.207.5005 > 10.96.48.159.36394: Flags [R.], seq 21, ack 33, win 509, options [nop,nop,TS val 2874709291 ecr 2823055790], length 0 07:53:35.733668 IP 192.168.100.24.36394 > 10.96.48.207.5005: Flags [R], seq 3764020869, win 0, length 0 tcpdump on the bond interface of the compute node in which the tcp server is running 07:50:35.658302 IP 10.96.48.159.36394 > 10.96.48.207.5005: Flags [S], seq 3764020836, win 64240, options [mss 1460,sackOK,TS val 2823050719 ecr 0,nop,wscale 7], length 0 07:50:35.658589 IP 10.96.48.207.5005 > 10.96.48.159.36394: Flags [S.], seq 1750463809, ack 3764020837, win 65160, options [mss 1460,sackOK,TS val 2874529221 ecr 2823050719,nop,wscale 7], length 0 07:50:35.658811 IP 10.96.48.159.36394 > 10.96.48.207.5005: Flags [.], ack 1, win 502, options [nop,nop,TS val 2823050720 ecr 2874529221], length 0 07:50:35.658901 IP 10.96.48.159.36394 > 10.96.48.207.5005: Flags [P.], seq 1:14, ack 1, win 502, options [nop,nop,TS val 2823050720 ecr 2874529221], length 13 07:50:35.658998 IP 10.96.48.207.5005 > 10.96.48.159.36394: Flags [.], ack 14, win 509, options [nop,nop,TS val 2874529221 ecr 2823050720], length 0 07:50:35.659205 IP 10.96.48.159.36394 > 10.96.48.207.5005: Flags [P.], seq 14:32, ack 1, win 502, options [nop,nop,TS val 2823050720 ecr 2874529221], length 18 07:50:35.659350 IP 10.96.48.207.5005 > 10.96.48.159.36394: Flags [.], ack 32, win 509, options [nop,nop,TS val 2874529221 ecr 2823050720], length 0 07:50:40.729633 IP 10.96.48.159.36394 > 10.96.48.207.5005: Flags [F.], seq 32, ack 1, win 502, options [nop,nop,TS val 2823055790 ecr 2874529221], length 0 07:50:40.773533 IP 10.96.48.207.5005 > 10.96.48.159.36394: Flags [.], ack 33, win 509, options [nop,nop,TS val 2874534335 ecr 2823055790], length 0 07:53:35.732868 IP 10.96.48.207.5005 > 10.96.48.159.36394: Flags [P.], seq 1:21, ack 33, win 509, options [nop,nop,TS val 2874709290 ecr 2823055790], length 20 07:53:35.732898 IP 10.96.48.207.5005 > 10.96.48.159.36394: Flags [R.], seq 21, ack 33, win 509, options [nop,nop,TS val 2874709291 ecr 2823055790], length 0 07:53:35.733767 IP 192.168.100.24.36394 > 10.96.48.207.5005: Flags [R], seq 3764020869, win 0, length 0 07:53:35.734408 IP 192.168.100.24.36394 > 10.96.48.207.5005: Flags [R], seq 3764020869, win 0, length 0 07:53:35.734602 IP 192.168.100.24.36394 > 10.96.48.207.5005: Flags [R], seq 3764020869, win 0, length 0 07:53:35.734748 IP 192.168.100.24.36394 > 10.96.48.207.5005: Flags [R], seq 3764020869, win 0, length 0 07:53:35.734873 IP 192.168.100.24.36394 > 10.96.48.207.5005: Flags [R], seq 3764020869, win 0, length 0 07:53:35.734973 IP 192.168.100.24.36394 > 10.9