[Yahoo-eng-team] [Bug 1612222] Re: quota unit test failure
Reviewed: https://review.openstack.org/354011 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=5d597367cfc89267793db0e861aa885044ac8f71 Submitter: Jenkins Branch:master commit 5d597367cfc89267793db0e861aa885044ac8f71 Author: Kevin Benton Date: Thu Aug 11 02:02:59 2016 -0700 Except if tracked resource registered as countable If a resource was registered in the quota engine before being set as a tracked resource, it would have been registered as a CountableResource instead of a TrackedResource. This would cause a failure later when the resources were being unregistered because the quota engine thought it should have been a TrackedResource and tried to call unregister_events on it. This patch just prevents resources from being registered as both types. It also callse unregister_all_resources as part of the standard test case cleanup since the vast majority of tests are using a plugin that may register resources. Closes-Bug: #161 Change-Id: I8a40f38d7c0e5aeca257ba62115fa9b02ad5aa93 ** 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/161 Title: quota unit test failure Status in neutron: Fix Released Bug description: spotted failure in a unit test unrelated to the patch. appears to be a result of leaked resources between the tests. === FAIL: neutron.tests.unit.quota.test_resource_registry.TestAuxiliary Functions.test_set_resources_dirty tags: worker-0 --- --- Empty attachments: pythonlogging:'' stderr stdout Traceback (most recent call last): File "neutron/tests/unit/quota/test_resource_registry.py", line 9 0, in setUp self.registry.unregister_resources() File "neutron/quota/resource_registry.py", line 239, in unregiste r_resources res.unregister_events() AttributeError: 'CountableResource' object has no attribute 'unregi ster_events' To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/161/+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 1620334] Re: Neutron dynamic routing: remove derpracted DB warnings
Reviewed: https://review.openstack.org/365679 Committed: https://git.openstack.org/cgit/openstack/neutron-dynamic-routing/commit/?id=c8a632acf6e7f67f5658469a197a53e4cdcb39e0 Submitter: Jenkins Branch:master commit c8a632acf6e7f67f5658469a197a53e4cdcb39e0 Author: Gary Kotton Date: Mon Sep 5 07:29:50 2016 -0700 Use model_base from neutron-lib This removes the deprecation warnings. In addition to this this also changed HasTenant to HasProject Change-Id: I6cce8dffb5f85276d904b101bcd46c04a12a147d Closes-bug: #1620334 ** 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/1620334 Title: Neutron dynamic routing: remove derpracted DB warnings Status in neutron: Fix Released Bug description: neutron_dynamic_routing/db/bgp_db.py:46: DeprecationWarning: neutron.db.model_base.BASEV2: moved to neutron_lib.db.model_base.BASEV2 class BgpSpeakerPeerBinding(model_base.BASEV2): neutron_dynamic_routing/db/bgp_db.py:64: DeprecationWarning: neutron.db.model_base.BASEV2: moved to neutron_lib.db.model_base.BASEV2 class BgpSpeakerNetworkBinding(model_base.BASEV2): neutron_dynamic_routing/db/bgp_db.py:84: DeprecationWarning: neutron.db.model_base.BASEV2: moved to neutron_lib.db.model_base.BASEV2 class BgpSpeaker(model_base.BASEV2, neutron_dynamic_routing/db/bgp_db.py:85: DeprecationWarning: neutron.db.model_base.HasId: moved to neutron_lib.db.model_base.HasId model_base.HasId, neutron_dynamic_routing/db/bgp_db.py:86: DeprecationWarning: neutron.db.model_base.HasTenant: moved to neutron_lib.db.model_base.HasProject model_base.HasTenant): neutron_dynamic_routing/db/bgp_db.py:107: DeprecationWarning: neutron.db.model_base.BASEV2: moved to neutron_lib.db.model_base.BASEV2 class BgpPeer(model_base.BASEV2, neutron_dynamic_routing/db/bgp_db.py:108: DeprecationWarning: neutron.db.model_base.HasId: moved to neutron_lib.db.model_base.HasId model_base.HasId, neutron_dynamic_routing/db/bgp_db.py:109: DeprecationWarning: neutron.db.model_base.HasTenant: moved to neutron_lib.db.model_base.HasProject model_base.HasTenant): neutron_dynamic_routing/db/bgp_dragentscheduler_db.py:47: DeprecationWarning: neutron.db.model_base.BASEV2: moved to neutron_lib.db.model_base.BASEV2 class BgpSpeakerDrAgentBinding(model_base.BASEV2): To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1620334/+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 1621310] Re: Material theme missing filter icon
Reviewed: https://review.openstack.org/367062 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=766b426bf4152a22d666dad3bd462ed6ff658909 Submitter: Jenkins Branch:master commit 766b426bf4152a22d666dad3bd462ed6ff658909 Author: Travis Tripp Date: Wed Sep 7 21:26:04 2016 -0600 Add material mapping for filter icon The material theme is missing an icon for filter. So, if a horizon plugin uses fa-filter, the material theme just shows an empty box. Change-Id: I7a7c6b337cf2a2906df9cb54c12e513d7a2c2c5e Closes-Bug: #1621310 ** Changed in: horizon Status: New => Fix Released -- 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/1621310 Title: Material theme missing filter icon Status in OpenStack Dashboard (Horizon): Fix Released Bug description: The material theme is missing an icon for filter. so, if a horizon plugin uses fa-filter, the material theme just shows an empty box. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1621310/+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 1608361] Re: After updating metadata any messages are not shown
Reviewed: https://review.openstack.org/349357 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=d8df8bf78b5ad70b4dde63711b05d6a14632ac6d Submitter: Jenkins Branch:master commit d8df8bf78b5ad70b4dde63711b05d6a14632ac6d Author: Kenji Ishii Date: Mon Aug 1 14:45:50 2016 +0900 Add message for a result of update metadata At the moment, even when a user update a metadata, this result is not informed to a user (any message is not displayed). So a user cannot know its result and he has to redisplay 'Update Metadata' modal in order to know its result. Change-Id: I02b1a3c70d0225d2326d038b7519d49b0082985e Closes-Bug: #1608361 ** Changed in: horizon Status: In Progress => Fix Released -- 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/1608361 Title: After updating metadata any messages are not shown Status in OpenStack Dashboard (Horizon): Fix Released Bug description: When I update metadata from somewhere like Admin -> Flavor, Admin -> Image, Project -> Instances and so on, after being updated there is no message on display. So a user could not understand whether this process succeeded or failed. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1608361/+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 1621379] [NEW] In the help msg of command host-evacuate,replace the optional arguments '--target_host' with '--target-host' more appropriate
Public bug reported: In the help msg of command host-evacuate,replace the optional arguments '--target_host' with '--target-host' more appropriate [root@devstack162 devstack]# nova help host-evacuate usage: nova host-evacuate [--target_host ] [--force] Evacuate all instances from failed host. Positional arguments: Name of host. Optional arguments: --target_host Name of target host. If no host is specified the scheduler will select a target. --force Force to not verify the scheduler if a host is provided. (Supported by API versions '2.29' - '2.latest') In the help information of other commands,never seen arguments with a '-' connection.People accustomed to the use of the '-' [root@devstack162 devstack]# nova host-evacuate tecsovs --target-host host1 usage: nova [--version] [--debug] [--os-cache] [--timings] [--os-region-name ] [--service-type ] [--service-name ] [--os-endpoint-type ] [--os-compute-api-version ] [--bypass-url ] [--insecure] [--os-cacert ] [--os-cert ] [--os-key ] [--timeout ] [--os-auth-type ] [--os-auth-url OS_AUTH_URL] [--os-domain-id OS_DOMAIN_ID] [--os-domain-name OS_DOMAIN_NAME] [--os-project-id OS_PROJECT_ID] [--os-project-name OS_PROJECT_NAME] [--os-project-domain-id OS_PROJECT_DOMAIN_ID] [--os-project-domain-name OS_PROJECT_DOMAIN_NAME] [--os-trust-id OS_TRUST_ID] [--os-default-domain-id OS_DEFAULT_DOMAIN_ID] [--os-default-domain-name OS_DEFAULT_DOMAIN_NAME] [--os-user-id OS_USER_ID] [--os-username OS_USERNAME] [--os-user-domain-id OS_USER_DOMAIN_ID] [--os-user-domain-name OS_USER_DOMAIN_NAME] [--os-password OS_PASSWORD] ... error: unrecognized arguments: --target-host host1 Try 'nova help ' for more information. [root@devstack162 devstack]# ** Affects: nova Importance: Undecided Assignee: xiewj (36429515-3) Status: New ** Changed in: nova Assignee: (unassigned) => xiewj (36429515-3) -- 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/1621379 Title: In the help msg of command host-evacuate,replace the optional arguments '--target_host' with '--target-host' more appropriate Status in OpenStack Compute (nova): New Bug description: In the help msg of command host-evacuate,replace the optional arguments '--target_host' with '--target-host' more appropriate [root@devstack162 devstack]# nova help host-evacuate usage: nova host-evacuate [--target_host ] [--force] Evacuate all instances from failed host. Positional arguments: Name of host. Optional arguments: --target_host Name of target host. If no host is specified the scheduler will select a target. --force Force to not verify the scheduler if a host is provided. (Supported by API versions '2.29' - '2.latest') In the help information of other commands,never seen arguments with a '-' connection.People accustomed to the use of the '-' [root@devstack162 devstack]# nova host-evacuate tecsovs --target-host host1 usage: nova [--version] [--debug] [--os-cache] [--timings] [--os-region-name ] [--service-type ] [--service-name ] [--os-endpoint-type ] [--os-compute-api-version ] [--bypass-url ] [--insecure] [--os-cacert ] [--os-cert ] [--os-key ] [--timeout ] [--os-auth-type ] [--os-auth-url OS_AUTH_URL] [--os-domain-id OS_DOMAIN_ID] [--os-domain-name OS_DOMAIN_NAME] [--os-project-id OS_PROJECT_ID] [--os-project-name OS_PROJECT_NAME] [--os-project-domain-id OS_PROJECT_DOMAIN_ID] [--os-project-domain-name OS_PROJECT_DOMAIN_NAME] [--os-trust-id OS_TRUST_ID] [--os-default-domain-id OS_DEFAULT_DOMAIN_ID] [--os-default-domain-name OS_DEFAULT_DOMAIN_NAME] [--os-user-id OS_USER_ID] [--os-username OS_USERNAME] [--os-user-domain-id OS_USER_DOMAIN_ID] [--os-user-domain-name OS_USER_DOMAIN_NAME] [--os-password OS_PASSWORD] ... error: unrecognized arguments: --target-host host1 Try 'nova help ' for more information. [root@devstack162 devstack]# To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1621379/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.
[Yahoo-eng-team] [Bug 1621392] [NEW] emit_event() is failing when locale/language is changed to other than english
You have been subscribed to a public bug: https://github.com/openstack/nova/blob/master/nova/virt/driver.py#L1439 is causing emit_event() failure Even though debug is not on, this line is causing emit_event() method failure. 2016-09-07 01:57:36.286 89568 INFO nova_powervm.virt.powervm.driver [req-9ef673ff-6d82-4a8e-b1fc-b7b635bc5bc8 - - - - -] [instance: bbb4890e-4e7f-47aa-b18f-cac527085966] Sending life cycle event for instance state change to: running 2016-09-07 01:57:36.287 89568 ERROR nova.virt.driver [req-9ef673ff-6d82-4a8e-b1fc-b7b635bc5bc8 - - - - -] Exception dispatching event [G'Startedฏูİı|]>: 'ascii' codec can't encode characters in position 82-86: ordinal not in range(128) ** Affects: nova Importance: Undecided Status: New -- emit_event() is failing when locale/language is changed to other than english https://bugs.launchpad.net/bugs/1621392 You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). -- 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 1621391] [NEW] Error "Could not find resource cirros" even image is created
Public bug reported: Following error is coming even while launching VM in the provider network configuration. #openstack server create --flavor m1.tiny --image cirros --nic net- id=def81dc4-a0bf-4e1f-9a1f-fb020c89bf5e --security-group default --key-name mykey provider-instance "" Could not find resource cirros "" -- # openstack image list +--+++ | ID | Name | Status | +--+++ | bebbae11-5e44-4e13-8d83-dc373ef0cbd5 | cirros | active | +--+++ # openstack image show bebbae11-5e44-4e13-8d83-dc373ef0cbd5 +--+--+ | Field| Value| +--+--+ | checksum | ee1eca47dc88f4879d8a229cc70a07c6 | | container_format | bare | | created_at | 2016-09-05T06:04:31Z | | disk_format | qcow2| | file | /v2/images/bebbae11-5e44-4e13-8d83-dc373ef0cbd5/file | | id | bebbae11-5e44-4e13-8d83-dc373ef0cbd5 | | min_disk | 0| | min_ram | 0| | name | cirros | | owner| 9b237e3ba19c49df8c703085b6629425 | | protected| False| | schema | /v2/schemas/image| | size | 13287936 | | status | active | | tags | | | updated_at | 2016-09-05T06:04:31Z | | virtual_size | None | | visibility | public | +--+--+ ** 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/1621391 Title: Error "Could not find resource cirros" even image is created Status in OpenStack Compute (nova): New Bug description: Following error is coming even while launching VM in the provider network configuration. #openstack server create --flavor m1.tiny --image cirros --nic net- id=def81dc4-a0bf-4e1f-9a1f-fb020c89bf5e --security-group default --key-name mykey provider-instance "" Could not find resource cirros "" -- # openstack image list +--+++ | ID | Name | Status | +--+++ | bebbae11-5e44-4e13-8d83-dc373ef0cbd5 | cirros | active | +--+++ # openstack image show bebbae11-5e44-4e13-8d83-dc373ef0cbd5 +--+--+ | Field| Value| +--+--+ | checksum | ee1eca47dc88f4879d8a229cc70a07c6 | | container_format | bare | | created_at | 2016-09-05T06:04:31Z | | disk_format | qcow2| | file | /v2/images/bebbae11-5e44-4e13-8d83-dc373ef0cbd5/file | | id | bebbae11-5e44-4e13-8d83-dc373ef0cbd5 | | min_disk | 0| | min_ram | 0| | name | cirros | | owner| 9b237e3ba19c49df8c703085b6629425 | | protected| False| | schema | /v2/schemas/image| | size | 13287936 | | status | active | | tags | | | updated_at | 2016-09-05T06:04:31Z | | virtual_size |
[Yahoo-eng-team] [Bug 1621341] Re: Material theme missing star outline icon
Reviewed: https://review.openstack.org/367122 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=5afc9a9d909536ef3f489c985c85cd3f53aaef2d Submitter: Jenkins Branch:master commit 5afc9a9d909536ef3f489c985c85cd3f53aaef2d Author: Travis Tripp Date: Thu Sep 8 00:42:34 2016 -0600 Add material theme icon for star outline The material theme is missing an icon for star outline. So, if a horizon plugin uses fa-star-o, the material theme just shows an empty box. Change-Id: I646c5e46548869136444f567ef1a51668e937e65 Closes-Bug: #1621341 ** Changed in: horizon Status: In Progress => Fix Released -- 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/1621341 Title: Material theme missing star outline icon Status in OpenStack Dashboard (Horizon): Fix Released Bug description: The material theme is missing an icon for star outline. so, if a horizon plugin uses fa-star-o, the material theme just shows an empty box. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1621341/+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 1608934] Re: ephemeral/swap disk creation fails for local storage with image type raw/lvm
Raising appropriate UCA tasks for impacted releases; I see this landed into master; we'll need to look at cherry-picks for stable/liberty and stable/mitaka as well. ** Tags added: regression ** Changed in: cloud-archive Status: New => Triaged ** Changed in: nova (Ubuntu) Status: Confirmed => Triaged ** Changed in: cloud-archive/liberty Importance: Undecided => High ** Changed in: cloud-archive/liberty Status: New => Triaged ** Also affects: cloud-archive/newton Importance: Undecided Status: Triaged ** Also affects: cloud-archive/mitaka Importance: Undecided Status: New ** Changed in: cloud-archive Importance: Undecided => High ** Changed in: cloud-archive/mitaka Status: New => Triaged ** Changed in: cloud-archive/mitaka Importance: Undecided => High -- 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/1608934 Title: ephemeral/swap disk creation fails for local storage with image type raw/lvm Status in Ubuntu Cloud Archive: Triaged Status in Ubuntu Cloud Archive liberty series: Triaged Status in Ubuntu Cloud Archive mitaka series: Triaged Status in Ubuntu Cloud Archive newton series: Triaged Status in OpenStack Compute (nova): Confirmed Status in nova package in Ubuntu: Triaged Bug description: Description === I am currently trying to launch an instance in my mitaka cluster with a flavor with ephemeral and root storage. Whenever i am trying to start the instance i am running into an "DiskNotFound" Error (see trace below). Starting instances without ephemeral works perfectly fine and the root disk is created as expected in /var/lib/nova/instance/$INSTANCEID/disk . Steps to reproduce == 1. Create a flavor with ephemeral and root storage. 2. Start an instance with that flavor. Expected result === Instance starts and ephemeral disk is created in /var/lib/nova/instances/$INSTANCEID/disk.eph0 or disk.local ? (Not sure where the switchase for the naming is) Actual result = Instance does not start, ephemeral disk seems to be created at /var/lib/nova/instances/$INSTANCEID/disk.eph0, but nova checks /var/lib/nova/instances/_base/ephemeral_* for disk_size TRACE: http://pastebin.com/raw/TwtiNLY2 Environment === I am running OpenStack mitaka on Ubuntu 16.04 in the latest version with Libvirt + KVM as hypervisor (also latest stable in xenial). Config == nova.conf: ... [libvirt] images_type = raw rbd_secret_uuid = XXX virt_type = kvm inject_key = true snapshot_image_format = raw disk_cachemodes = "network=writeback" rng_dev_path = /dev/random rbd_user = cinder ... To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1608934/+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 1621392] [NEW] emit_event() is failing when locale/language is changed to other than english
Public bug reported: https://github.com/openstack/nova/blob/master/nova/virt/driver.py#L1439 is causing emit_event() failure Even though debug is not on, this line is causing emit_event() method failure. 2016-09-07 01:57:36.286 89568 INFO nova_powervm.virt.powervm.driver [req-9ef673ff-6d82-4a8e-b1fc-b7b635bc5bc8 - - - - -] [instance: bbb4890e-4e7f-47aa-b18f-cac527085966] Sending life cycle event for instance state change to: running 2016-09-07 01:57:36.287 89568 ERROR nova.virt.driver [req-9ef673ff-6d82-4a8e-b1fc-b7b635bc5bc8 - - - - -] Exception dispatching event [G'Startedฏูİı|]>: 'ascii' codec can't encode characters in position 82-86: ordinal not in range(128) ** Affects: nova Importance: Undecided Status: New ** Project changed: tacker => nova -- 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/1621392 Title: emit_event() is failing when locale/language is changed to other than english Status in OpenStack Compute (nova): New Bug description: https://github.com/openstack/nova/blob/master/nova/virt/driver.py#L1439 is causing emit_event() failure Even though debug is not on, this line is causing emit_event() method failure. 2016-09-07 01:57:36.286 89568 INFO nova_powervm.virt.powervm.driver [req-9ef673ff-6d82-4a8e-b1fc-b7b635bc5bc8 - - - - -] [instance: bbb4890e-4e7f-47aa-b18f-cac527085966] Sending life cycle event for instance state change to: running 2016-09-07 01:57:36.287 89568 ERROR nova.virt.driver [req-9ef673ff-6d82-4a8e-b1fc-b7b635bc5bc8 - - - - -] Exception dispatching event [G'Startedฏูİı|]>: 'ascii' codec can't encode characters in position 82-86: ordinal not in range(128) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1621392/+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 1605084] Re: [RFE] "About page" tab should be available on Dashboard of OpenStack
Most of this information is already available in the dashboard. I don't think there is any value in listing out what the components do, as the end user doesn't need to know that anyway... they just want an instance, they don't want to know which version of Nova they have. ** Changed in: horizon Status: In Progress => Won't Fix -- 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/1605084 Title: [RFE] "About page" tab should be available on Dashboard of OpenStack Status in OpenStack Dashboard (Horizon): Won't Fix Bug description: About page or tab is not available. It should be available as it will give the user which version it is using. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1605084/+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 1576093] Re: [SRU] block migration fail with libvirt since version 1.2.17
** Changed in: cloud-archive Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1576093 Title: [SRU] block migration fail with libvirt since version 1.2.17 Status in Ubuntu Cloud Archive: Invalid Status in Ubuntu Cloud Archive mitaka series: Fix Released Status in OpenStack Compute (nova): Fix Released Status in nova package in Ubuntu: Fix Released Status in nova source package in Xenial: Fix Released Status in nova source package in Yakkety: Fix Released Bug description: [Impact] Try to do block migration but fail and libvirt reports that "Selecting disks to migrate is not implemented for tunneled migration" Nova: a4e15e329f9adbcfe72fbcd6acb94f0743ad02f8 libvirt: 1.3.1 [Test Case] reproduce: default devstack setting and do block migration (no shared instance_dir and shared instance storage used) [Regression Potential] Patch was cherry picked from upstream gerrit review, which was cherry picked with little change from master branch. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1576093/+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 1534445] Re: Multiple floating IPs from the same external network are associated to one port when commands are executed at the same time
Reviewed: https://review.openstack.org/276018 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=a9c3b7ef08a34b27b63a12cfbd5798d13b083fc1 Submitter: Jenkins Branch:master commit a9c3b7ef08a34b27b63a12cfbd5798d13b083fc1 Author: Lujin Luo Date: Wed Feb 3 17:56:53 2016 +0900 Add a composite unique key to floatingip table in Neutron database This patch set avoids associating multiple floating IPs to one fixed_ ip_address on one internal port when commands are executed concurrently by adding a composite unique key between floating_network_id, fixed_port _id and fixed_ip_address in floatingips table in Neutron database. This implies the following 2 use cases are allowed/supported in Neutron: 1. one port_id with different fixed_ip_address(es) can associate with floating_ip_address(es) from the same floating_network_id [1] 2. same fixed_ip_address can associate to same floating_network_id, as long as they are on different ports, because different internal networks could be using the same IP ranges. [1] https://bugs.launchpad.net/neutron/+bug/1057844 Change-Id: Ie8f3ec1b23c14f36992886510c3114cf956769d4 Closes-Bug: #1534445 ** 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/1534445 Title: Multiple floating IPs from the same external network are associated to one port when commands are executed at the same time Status in neutron: Fix Released Bug description: I have three controller nodes and the Neutron servers on these controllers are set behind Pacemaker and HAProxy to realize active/active HA using DevStack. MariaDB Galera cluster is used as my database backend. I am using the latest codes. If I have multiple commands to create floating IPs and associate them to the same port at the same time, all of the commands would return success and end up with multiple floating IPs from the same external network associated to the same port. How to reproduce: Step 1: Create a network $ neutron net-create net1 Step 2: Create a subnet on the network $ neutron subnet-create --name subnet1 net1 192.168.100.0/24 Step 3: Create a port on the network $ neutron port-create net1 Step 4: Create a router $ neutron router-create router-floatingip-test Step 5: Add the subnet as its interface $ neutron router-interface-add router-floatingip-test subnet1 Step 5: Create an external network $ neutron net-create ext-net --router:external True Step 6: Add a subnet on the external network $ neutron subnet-create --name ext-subnet ext-net 192.168.122.0/24 Step 7: Set the external network as the router's default gateway $ neutron router-gateway-set router-floatingip-test ext-net Step 8: Run the three commands at the same time to create floating IPs On controller1: $ neutron floatingip-create ext-net --port-id b53d0826-53c4-427b-81b2-3ab6cb0f4511 On controller2: $ neutron floatingip-create ext-net --port-id b53d0826-53c4-427b-81b2-3ab6cb0f4511 On controller3: $ neutron floatingip-create ext-net --port-id b53d0826-53c4-427b-81b2-3ab6cb0f4511 where, port_id b53d0826-53c4-427b-81b2-3ab6cb0f4511 is the port we created in Step 3. The result would be three floating IPs associated to the same port, as shown in http://paste.openstack.org/show/483691/ The expected error message (say, we run the second command after the first one succeeds) would be Cannot associate floating IP 192.168.122.20 (bd4d47a5-45c1-48e1-a48a-aef08039a955) with port b53d0826-53c4-427b-81b2-3ab6cb0f4511 using fixed IP 192.168.100.3, as that fixed IP already has a floating IP on external network 920ee0f3-3db8-4005-8d29-0be474947186. Since one port with one fixed_ip is not allowed to have multiple floating IPs from the same external network. In the above procedure, I set port_id when creating these three floating IPs. Same bug occurred when I updated three existing floating IPs to be associated with the same port at the same time. I assume this bug happens because multiple APIs are executed concurrently and the validation check on every API succeeds [1]. [1] https://github.com/openstack/neutron/blob/master/neutron/db/l3_db.py#L915 Update on 2016/9/8- The clearer bug description should be to mitigate one fixed_ip_address on one port to be associated with multiple floating_ip_address(es) from the same floating_network_id. This implies the following 2 use cases are allowed/supported in Neutron: 1. one port_id with different fixed_ip_address(es) can associate with floating_ip_address(es) from the same floating_network_id [2] 2. same fixed_ip_address can associate to same floating_network_id, as long as they
[Yahoo-eng-team] [Bug 1430042] Re: Virtual Machine could not be evacuated because virtual interface creation failed
** Also affects: cloud-archive/kilo Importance: Undecided Status: New ** Also affects: cloud-archive/mitaka Importance: Undecided Status: New ** Also affects: cloud-archive/liberty Importance: Undecided Status: New ** Changed in: cloud-archive Status: New => Invalid ** Changed in: cloud-archive/kilo Status: New => Fix Released ** Changed in: cloud-archive/liberty Status: New => Fix Released ** Changed in: cloud-archive/mitaka Status: New => 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/1430042 Title: Virtual Machine could not be evacuated because virtual interface creation failed Status in Ubuntu Cloud Archive: Invalid Status in Ubuntu Cloud Archive kilo series: Fix Released Status in Ubuntu Cloud Archive liberty series: Fix Released Status in Ubuntu Cloud Archive mitaka series: Fix Released Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Status in Ubuntu: New Status in The Trusty Tahr: New Bug description: I believe this issue is related to Question 257358 (https://answers.launchpad.net/ubuntu/+source/nova/+question/257358). On the source host we see the successful vif plug: 2015-03-09 01:22:12.363 629 DEBUG neutron.plugins.ml2.rpc [req-5de70341-d64b-4a3a-bc05-54eb2802f25d None] Device 14ac5edd-269f-4808-9a34-c4cc93e9ab70 up at agent ovs-agent-ipx update_device_up /usr/lib/python2.7/site-packages/neutron/plugins/ml2/rpc.py:156 2015-03-09 01:22:12.392 629 DEBUG oslo_concurrency.lockutils [req-5de70341-d64b-4a3a-bc05-54eb2802f25d ] Acquired semaphore "db-access" lock /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:377 2015-03-09 01:22:12.436 629 DEBUG oslo_concurrency.lockutils [req-5de70341-d64b-4a3a-bc05-54eb2802f25d ] Releasing semaphore "db-access" lock /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:390 2015-03-09 01:22:12.437 629 DEBUG oslo_messaging._drivers.amqp [req-5de70341-d64b-4a3a-bc05-54eb2802f25d ] UNIQUE_ID is 740634ca8c7a49418a39c429669f2f27. _add_unique_id /usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqp.py:224 2015-03-09 01:22:12.439 629 DEBUG oslo_messaging._drivers.amqp [req-5de70341-d64b-4a3a-bc05-54eb2802f25d ] UNIQUE_ID is 3264e8d7dd7c492d9aa17d3e9892b1fc. _add_unique_id /usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqp.py:224 2015-03-09 01:22:14.436 629 DEBUG neutron.notifiers.nova [-] Sending events: [{'status': 'completed', 'tag': u'14ac5edd-269f-4808-9a34-c4cc93e9ab70', 'name': 'network-vif-plugged', 'server_uuid': u'2790be4a-5285-46aa-8ee2-c68f5b936c1d'}] send_events /usr/lib/python2.7/site-packages/neutron/notifiers/nova.py:237 Later, the destination host of the evacuation attempts to plug the vif but can't: 2015-03-09 02:15:41.441 629 DEBUG neutron.plugins.ml2.rpc [req-5ea6625c-a60c-48fb-9264-e2a5a3ed0d26 None] Device 14ac5edd-269f-4808-9a34-c4cc93e9ab70 up at agent ovs-agent-ipxx update_device_up /usr/lib/python2.7/site-packages/neutron/plugins/ml2/rpc.py:156 2015-03-09 02:15:41.485 629 DEBUG neutron.plugins.ml2.rpc [req-5ea6625c-a60c-48fb-9264-e2a5a3ed0d26 None] Device 14ac5edd-269f-4808-9a34-c4cc93e9ab70 not bound to the agent host ipx update_device_up /usr/lib/python2.7/site-packages/neutron/plugins/ml2/rpc.py:163 The cause of the problem seems to be that the neutron port does not have is binding:host_id properly updated on evacuation, the answer to question 257358 looks like the fix. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1430042/+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 1459046] Re: [SRU] nova-* services do not start if rsyslog is not yet started
** Changed in: cloud-archive/juno Status: In Progress => Won't Fix ** Changed in: cloud-archive Status: Confirmed => Fix Released ** Changed in: cloud-archive/kilo Status: Confirmed => Triaged -- 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/1459046 Title: [SRU] nova-* services do not start if rsyslog is not yet started Status in Ubuntu Cloud Archive: Fix Released Status in Ubuntu Cloud Archive icehouse series: Fix Released Status in Ubuntu Cloud Archive juno series: Won't Fix Status in Ubuntu Cloud Archive kilo series: Triaged Status in Ubuntu Cloud Archive liberty series: Fix Released Status in OpenStack Compute (nova): Fix Released Status in oslo.log: Fix Released Status in nova package in Ubuntu: Invalid Status in python-oslo.log package in Ubuntu: Fix Released Status in nova source package in Trusty: Fix Released Status in nova source package in Utopic: Won't Fix Status in nova source package in Vivid: Invalid Status in python-oslo.log source package in Vivid: Won't Fix Status in nova source package in Wily: Invalid Status in python-oslo.log source package in Wily: Fix Released Bug description: [Impact] * If Nova services are configured to log to syslog (use_syslog=True) they will currently fail with ECONNREFUSED if they cannot connect to syslog. This patch adds support for allowing nova to retry connecting a configurable number of times before print an error message and continuing with startup. [Test Case] * Configure nova with use_syslog=True in nova.conf, stop rsyslog service and restart nova services. Check that upstart nova logs to see retries occurring then start rsyslog and observe connection succeed and nova-compute startup. [Regression Potential] * None To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1459046/+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 1611057] Re: Preview Page: Default Theme: Content Horizontally Scrolling
Reviewed: https://review.openstack.org/352537 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=68f46ce25eabb0542450dcf0ad3c8f6da6a78f2f Submitter: Jenkins Branch:master commit 68f46ce25eabb0542450dcf0ad3c8f6da6a78f2f Author: Diana Whitten Date: Mon Aug 8 10:08:18 2016 -0700 Preview Page: Default Theme: Content Horizontally Scrolling Removal of default styles caused page to scroll horizontally. Closes-bug: #1611057 Change-Id: I1a9b7e0da950fa6c66862ba82fcc264d2f3b2280 ** Changed in: horizon Status: In Progress => Fix Released -- 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/1611057 Title: Preview Page: Default Theme: Content Horizontally Scrolling Status in OpenStack Dashboard (Horizon): Fix Released Bug description: Recent removal of styles on default theme has caused the Theme Preview page to horizontally scroll when it shouldn't. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1611057/+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 1621430] [NEW] L3 flavors handling flavor request incorrectly
Public bug reported: When creating a router only specifying a flavor ID, the L3 plugin is incorrectly assuming both a flavor ID and a distributed attribute were set because the DVR code populates the API body with the distributed flag. This results in a validation error like this: Captured traceback: ~~~ Traceback (most recent call last): File "/opt/stack/neutron/neutron/tests/tempest/api/admin/test_routers_flavors.py", line 65, in test_create_router_with_flavor router = self.client.create_router('name', flavor_id=flavor['id']) File "/opt/stack/neutron/neutron/tests/tempest/services/network/json/network_client.py", line 327, in create_router resp, body = self.post(uri, body) File "tempest/lib/common/rest_client.py", line 273, in post return self.request('POST', url, extra_headers, headers, body, chunked) File "tempest/lib/common/rest_client.py", line 667, in request resp, resp_body) File "tempest/lib/common/rest_client.py", line 831, in _error_checker message=message) tempest.lib.exceptions.ServerFault: Got server fault Details: Provider single_node does not support distributed=True ** Affects: neutron Importance: High Assignee: Kevin Benton (kevinbenton) Status: New ** Changed in: neutron Importance: Undecided => High ** Changed in: neutron Assignee: (unassigned) => Kevin Benton (kevinbenton) ** Changed in: neutron Milestone: None => newton-rc1 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1621430 Title: L3 flavors handling flavor request incorrectly Status in neutron: New Bug description: When creating a router only specifying a flavor ID, the L3 plugin is incorrectly assuming both a flavor ID and a distributed attribute were set because the DVR code populates the API body with the distributed flag. This results in a validation error like this: Captured traceback: ~~~ Traceback (most recent call last): File "/opt/stack/neutron/neutron/tests/tempest/api/admin/test_routers_flavors.py", line 65, in test_create_router_with_flavor router = self.client.create_router('name', flavor_id=flavor['id']) File "/opt/stack/neutron/neutron/tests/tempest/services/network/json/network_client.py", line 327, in create_router resp, body = self.post(uri, body) File "tempest/lib/common/rest_client.py", line 273, in post return self.request('POST', url, extra_headers, headers, body, chunked) File "tempest/lib/common/rest_client.py", line 667, in request resp, resp_body) File "tempest/lib/common/rest_client.py", line 831, in _error_checker message=message) tempest.lib.exceptions.ServerFault: Got server fault Details: Provider single_node does not support distributed=True To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1621430/+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 1615763] Re: CommandError: An error occurred during rendering
** Changed in: devstack Status: New => Invalid ** Changed in: congress Assignee: (unassigned) => Anusha (anusha-iiitm) -- 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/1615763 Title: CommandError: An error occurred during rendering Status in congress: In Progress Status in devstack: Invalid Status in OpenStack Dashboard (Horizon): Invalid Bug description: Repeatedly seeing the following error during devstack setup in tempest tests in Congress (for example: http://logs.openstack.org/57/356157/4/check/gate-congress-dsvm- api/70474ca/logs/devstack-early.txt.gz [also attached]). Any idea whether it's a horizon bug or devstack bug or user error on Congress side? Thanks so much! 2016-08-22 04:09:07.389 | 1658 static files copied to '/opt/stack/new/horizon/static'. 2016-08-22 04:09:09.017 | Found 'compress' tags in: 2016-08-22 04:09:09.017 | /opt/stack/new/horizon/openstack_dashboard/templates/horizon/_conf.html 2016-08-22 04:09:09.017 | /opt/stack/new/horizon/openstack_dashboard/templates/horizon/_scripts.html 2016-08-22 04:09:09.017 | /opt/stack/new/congress/congress_dashboard/templates/admin/base.html 2016-08-22 04:09:09.017 | /opt/stack/new/horizon/openstack_dashboard/templates/_stylesheets.html 2016-08-22 04:09:09.017 | /opt/stack/new/congress/congress_dashboard/templates/admin/_scripts.html 2016-08-22 04:09:09.875 | Compressing... CommandError: An error occurred during rendering /opt/stack/new/congress/congress_dashboard/templates/admin/base.html: 'horizon/lib/jquery-ui/ui/jquery-ui.css' could not be found in the COMPRESS_ROOT '/opt/stack/new/horizon/static' or with staticfiles. 2016-08-22 04:09:09.957 | exit_trap: cleaning up child processes 2016-08-22 04:09:09.957 | ./stack.sh: line 486: kill: (15777) - No such process+ unset GREP_OPTIONS To manage notifications about this bug go to: https://bugs.launchpad.net/congress/+bug/1615763/+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 1621437] [NEW] Add Allocations record failed in the startup of compute node
Public bug reported: When startup the compute node, the allocation record failed to add, the message as below: 2016-09-08 19:51:43.615 WARNING nova.scheduler.client.report [req- 78558a2d-3d4c-4357-bbc2-d53281e1300e None None] Unable to submit allocation for instance 31bdb2e4-fb77-41b0-afb9-0cfe4292234d (400 400 Bad Requet The server could not comply with the request since it is either malformed or otherwise incorrect. Allocation for resource provider 'e1c72350-56dd-468a-a035-44b224ff2d05' that does not exist. ) This due to we create ResourceProvider and Inventory in the end of available resource update. ** Affects: nova Importance: Undecided Assignee: Alex Xu (xuhj) Status: In Progress ** Changed in: nova Assignee: (unassigned) => Alex Xu (xuhj) -- 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/1621437 Title: Add Allocations record failed in the startup of compute node Status in OpenStack Compute (nova): In Progress Bug description: When startup the compute node, the allocation record failed to add, the message as below: 2016-09-08 19:51:43.615 WARNING nova.scheduler.client.report [req- 78558a2d-3d4c-4357-bbc2-d53281e1300e None None] Unable to submit allocation for instance 31bdb2e4-fb77-41b0-afb9-0cfe4292234d (400 400 Bad Requet The server could not comply with the request since it is either malformed or otherwise incorrect. Allocation for resource provider 'e1c72350-56dd- 468a-a035-44b224ff2d05' that does not exist. ) This due to we create ResourceProvider and Inventory in the end of available resource update. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1621437/+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 1616126] Re: detachedinstance error when creating router from auto allocate
Reviewed: https://review.openstack.org/359303 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=fef301979eefad717f185170bb5f7ee2ed365aaf Submitter: Jenkins Branch:master commit fef301979eefad717f185170bb5f7ee2ed365aaf Author: Kevin Benton Date: Wed Sep 7 18:09:21 2016 -0700 Don't return ext net DB object in auto allocate Returning a DB object for the external network and passing that to the create_router operation makes the life of the DB object transition many operations. If any of those operations detech it from the session or expire it, it can result in an exception down in the router operations. This patch just returns the network ID since that's all we need. Closes-Bug: #1616126 Change-Id: Ib9c4ba9f00ca7f7a713a89be4f75a230b086ac38 ** 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/1616126 Title: detachedinstance error when creating router from auto allocate Status in neutron: Fix Released Bug description: Traceback below seems to be caused by passing a DB object into create_router for the gw_info rather than a standard dict. 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource [req-152d2fff-ec6f-4049-9753-e9bcf35bd7ef tempest-AutoAllocateNetworkTest-145714278 -] show failed: No details. 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource Traceback (most recent call last): 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/api/v2/resource.py", line 79, in resource 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource result = method(request=request, **args) 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 151, in wrapper 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource ectxt.value = e.inner_exc 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource self.force_reraise() 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource six.reraise(self.type_, self.value, self.tb) 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 139, in wrapper 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource return f(*args, **kwargs) 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/db/api.py", line 92, in wrapped 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource traceback.format_exc()) 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource self.force_reraise() 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource six.reraise(self.type_, self.value, self.tb) 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/db/api.py", line 87, in wrapped 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource return f(*dup_args, **dup_kwargs) 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/api/v2/base.py", line 347, in show 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource parent_id=parent_id), 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/api/v2/base.py", line 310, in _item 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource obj = obj_getter(request.context, id, **kwargs) 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/services/auto_allocate/db.py", line 138, in get_auto_allocated_topology 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource context, tenant_id, default_external_network) 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/services/auto_allocate/db.py", line 165, in _build_topology 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource router_id=router_id, subnets=subnets) 2016-08-23 12:29:55.959 18391 ERROR neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", l
[Yahoo-eng-team] [Bug 1617215] Re: metering-agent sync useless meter label cause error
Hooking up Ubuntu bug with Neutron work to resolve this under: https://review.openstack.org/#/c/361023/ ** Also affects: neutron Importance: Undecided Status: New ** Changed in: neutron (Ubuntu) Importance: Undecided => Low -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1617215 Title: metering-agent sync useless meter label cause error Status in neutron: New Status in neutron package in Ubuntu: In Progress Bug description: Metering-agent may be retrieve useless meter label by sync_routers_task, which tenant's router related metering label didn't scheduler to metering-agent's host. When neutron deployed multi- network node, it will cause Error, e.g Stderr: 'Cannot open network namespace: No such file or directory\n' execute /usr/lib/python2.7 /dist-packages/neutron/agent/linux/utils.py:60 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1617215/+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 1621449] [NEW] Unit tests run on old db schema
Public bug reported: On current master (6a93e9b) most of unit tests do not run on new schema. For example, for test keystone.tests.unit.assignment.role_backends.test_sql.SqlRole.test_role_crud migration contract_repo/versions/002_password_created_at_not_nullable.py never gets applied. Keystone should run all migrations for a test prior to the test's execution. ** Affects: keystone Importance: Undecided Status: New -- 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/1621449 Title: Unit tests run on old db schema Status in OpenStack Identity (keystone): New Bug description: On current master (6a93e9b) most of unit tests do not run on new schema. For example, for test keystone.tests.unit.assignment.role_backends.test_sql.SqlRole.test_role_crud migration contract_repo/versions/002_password_created_at_not_nullable.py never gets applied. Keystone should run all migrations for a test prior to the test's execution. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1621449/+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 1606496] Re: Instance affinity filters do not work in a heterogeneous cloud with Ironic computes
Reviewed: https://review.openstack.org/347948 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=cc64a45d98d7576a78a853cc3da8109c31f4b75d Submitter: Jenkins Branch:master commit cc64a45d98d7576a78a853cc3da8109c31f4b75d Author: Roman Podoliaka Date: Wed Jul 27 19:46:16 2016 +0300 ironic_host_manager: fix population of instances info on start IronicHostManager currently overrides the _init_instance_info() method of the base class and unconditionally skips population of instances information for all compute nodes, even if they are not Ironic ones. If there are compute nodes with the hypervisor_type different from Ironic in the same cloud. the instances info will be missing in nova-scheduler (if IronicHostManager is configured as a host manager impl in nova.conf), which will effectively break instance affinity filters like DifferentHostFilter or SameHostFilter, that check set intersections of instances running on a particular host and the ones passed as a hint for nova-scheduler in a boot request. IronicHostManager should use the method implementation of the base class for non-ironic compute nodes. Ib1ddb44d71f7b085512c1f3fc0544f7b00c754fe fixed the problem with scheduling, this change is needed to make sure we also populate the instances info on start of nova-scheduler. Closes-Bug: #1606496 Co-Authored-By: Timofei Durakov Change-Id: I9d8d2dc99773df4097c178d924d182a0d1971bcc ** 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/1606496 Title: Instance affinity filters do not work in a heterogeneous cloud with Ironic computes Status in OpenStack Compute (nova): Fix Released Bug description: Description === In a heterogeneous cloud with both libvirt and ironic compute nodes instance affinity filters like DifferentHostFilter or SameHostFilter do not filter hosts out when scheduling a subsequent instance. Steps to reproduce == Make sure you have at least two libvirt compute nodes and one ironic node. Make sure DifferentHostFilter and SameHostFilter are configured as nova-scheduler filters in nova.conf, filters scheduler is used. 1. Boot a libvirt instance A. 2. Check the host name of the compute node instance A is running on (nova show from an admin user). 3. Boot a libvirt instance B passing a different_host=$A.uuid hint for nova-scheduler. 4. Check the host name of the compute node instance B is running on (nova show from an admin user). Expected result === Instances A and B are running on two different compute nodes. Actual result = Instances A and B are running on the same compute node. nova-scheduler logs shows that DifferentHost filter was run, but did not filter out one of the hosts: Filter DifferentHostFilter returned 2 host(s) get_filtered_objects Environment === OpenStack Mitaka 2 libvirt compute nodes 1 ironic compute node FiltersScheduler is used DifferentHostFilter and SameHostFilter filters are enabled in nova.conf Root cause analysis === Debugging shown that IronicHostManager is configured to be used by nova-scheduler instead of the default host manager, when Ironic compute are deployed in the same cloud together with libvirt compute nodes. IronicHostManager overrides the _get_instance_info() method and unconditionally returns an empty instance dict, even if this method is called for non-ironic computes of the same cloud. DifferentHostFilter and similar filters later use this info to find an intersection of a set of instances running on a libvirt compute node (currently, always {}) and a set of instances uuids passed as a hint for nova-scheduler, thus compute nodes are never filtered out and the hint is effectively ignored. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1606496/+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 1398999] Re: Block migrate with attached volumes copies volumes to themselves
** Changed in: nova (Ubuntu Vivid) Status: Triaged => Won't Fix -- 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/1398999 Title: Block migrate with attached volumes copies volumes to themselves Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: Fix Released Status in libvirt package in Ubuntu: Fix Released Status in nova package in Ubuntu: Triaged Status in libvirt source package in Trusty: Confirmed Status in nova source package in Trusty: Triaged Status in libvirt source package in Utopic: Won't Fix Status in nova source package in Utopic: Won't Fix Status in libvirt source package in Vivid: Confirmed Status in nova source package in Vivid: Won't Fix Status in libvirt source package in Wily: Fix Released Status in nova source package in Wily: Triaged Bug description: When an instance with attached Cinder volumes is block migrated, the Cinder volumes are block migrated along with it. If they exist on shared storage, then they end up being copied, over the network, from themselves to themselves. At a minimum, this is horribly slow and de- sparses a sparse volume; at worst, this could cause massive data corruption. More details at http://lists.openstack.org/pipermail/openstack- dev/2014-June/038152.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1398999/+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 1621452] [NEW] need handle DevicePathInUse in attach_volume
Public bug reported: Attach a volume with used name will got error, the root cause is we didn't handle DevicePathInUse 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions instance, bdms, new_bdm) 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1667, in _get_device_name_for_instance 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions instance, bdms, block_device_obj.get("device_name")) 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/compute/utils.py", line 104, in get_device_name_for_instance 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions mappings['root'], device) 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/compute/utils.py", line 185, in get_next_device_name 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions raise exception.DevicePathInUse(path=device) 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions DevicePathInUse: The supplied device path (/dev/sda) is in use. 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions 2016-09-06 08:34:17.223 5177 INFO nova.api.openstack.wsgi [req-665260fe-9434-4259-a658-f1eb30948522 6a1f271818af46f3ae3c99d09a1efdff 134b4b70bc464c0db32624ad256a6563 - - -] HTTP exception thrown: Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. ** Affects: nova Importance: Undecided Assignee: jichenjc (jichenjc) Status: New ** Changed in: nova Assignee: (unassigned) => jichenjc (jichenjc) -- 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/1621452 Title: need handle DevicePathInUse in attach_volume Status in OpenStack Compute (nova): New Bug description: Attach a volume with used name will got error, the root cause is we didn't handle DevicePathInUse 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions instance, bdms, new_bdm) 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1667, in _get_device_name_for_instance 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions instance, bdms, block_device_obj.get("device_name")) 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/compute/utils.py", line 104, in get_device_name_for_instance 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions mappings['root'], device) 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/compute/utils.py", line 185, in get_next_device_name 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions raise exception.DevicePathInUse(path=device) 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions DevicePathInUse: The supplied device path (/dev/sda) is in use. 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions 2016-09-06 08:34:17.148 5177 ERROR nova.api.openstack.extensions 2016-09-06 08:34:17.223 5177 INFO nova.api.openstack.wsgi [req-665260fe-9434-4259-a658-f1eb30948522 6a1f271818af46f3ae3c99d09a1efdff 134b4b70bc464c0db32624ad256a6563 - - -] HTTP exception thrown: Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1621452/+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 1398999] Re: Block migrate with attached volumes copies volumes to themselves
** Changed in: nova (Ubuntu Wily) Status: Triaged => Won't Fix -- 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/1398999 Title: Block migrate with attached volumes copies volumes to themselves Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: Fix Released Status in libvirt package in Ubuntu: Fix Released Status in nova package in Ubuntu: Triaged Status in libvirt source package in Trusty: Confirmed Status in nova source package in Trusty: Triaged Status in libvirt source package in Utopic: Won't Fix Status in nova source package in Utopic: Won't Fix Status in libvirt source package in Vivid: Confirmed Status in nova source package in Vivid: Won't Fix Status in libvirt source package in Wily: Fix Released Status in nova source package in Wily: Won't Fix Bug description: When an instance with attached Cinder volumes is block migrated, the Cinder volumes are block migrated along with it. If they exist on shared storage, then they end up being copied, over the network, from themselves to themselves. At a minimum, this is horribly slow and de- sparses a sparse volume; at worst, this could cause massive data corruption. More details at http://lists.openstack.org/pipermail/openstack- dev/2014-June/038152.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1398999/+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 1621391] Re: Error "Could not find resource cirros" even image is created
That doesn't sound a Nova problem, rather an OSC issue. ** Also affects: python-openstackclient Importance: Undecided Status: New ** Changed in: nova Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1621391 Title: Error "Could not find resource cirros" even image is created Status in Glance: Incomplete Status in OpenStack Compute (nova): Invalid Bug description: Following error is coming even while launching VM in the provider network configuration. #openstack server create --flavor m1.tiny --image cirros --nic net- id=def81dc4-a0bf-4e1f-9a1f-fb020c89bf5e --security-group default --key-name mykey provider-instance "" Could not find resource cirros "" -- # openstack image list +--+++ | ID | Name | Status | +--+++ | bebbae11-5e44-4e13-8d83-dc373ef0cbd5 | cirros | active | +--+++ # openstack image show bebbae11-5e44-4e13-8d83-dc373ef0cbd5 +--+--+ | Field| Value| +--+--+ | checksum | ee1eca47dc88f4879d8a229cc70a07c6 | | container_format | bare | | created_at | 2016-09-05T06:04:31Z | | disk_format | qcow2| | file | /v2/images/bebbae11-5e44-4e13-8d83-dc373ef0cbd5/file | | id | bebbae11-5e44-4e13-8d83-dc373ef0cbd5 | | min_disk | 0| | min_ram | 0| | name | cirros | | owner| 9b237e3ba19c49df8c703085b6629425 | | protected| False| | schema | /v2/schemas/image| | size | 13287936 | | status | active | | tags | | | updated_at | 2016-09-05T06:04:31Z | | virtual_size | None | | visibility | public | +--+--+ To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1621391/+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 1621461] [NEW] SR-IOV qos driver calls wrong clear_rate functions
Public bug reported: In neutron/plugins/ml2/drivers/mech_sriov/agent/extension_drivers/qos_driver: - "delete_minimum_bandwidth" is calling ESwitchManager().clear_min_tx_rate - "delete_bandwidth_limit" is calling ESwitchManager().clear_max_rate Both functions don't exist. ** Affects: neutron Importance: Undecided Status: New ** Description changed: In neutron/plugins/ml2/drivers/mech_sriov/agent/extension_drivers/qos_driver: - "delete_minimum_bandwidth" is calling ESwitchManager().clear_min_tx_rate - "delete_bandwidth_limit" is calling ESwitchManager().clear_max_rate - Both functions doesn't exist. + Both functions don't exist. -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1621461 Title: SR-IOV qos driver calls wrong clear_rate functions Status in neutron: New Bug description: In neutron/plugins/ml2/drivers/mech_sriov/agent/extension_drivers/qos_driver: - "delete_minimum_bandwidth" is calling ESwitchManager().clear_min_tx_rate - "delete_bandwidth_limit" is calling ESwitchManager().clear_max_rate Both functions don't exist. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1621461/+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 1606740] Re: The schema of quota's update isn't include networks quota
** Also affects: nova/mitaka Importance: Undecided Status: New ** Changed in: nova/mitaka Status: New => In Progress ** Changed in: nova/mitaka Assignee: (unassigned) => Alex Xu (xuhj) ** Changed in: nova/mitaka Importance: Undecided => Medium -- 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/1606740 Title: The schema of quota's update isn't include networks quota Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) mitaka series: In Progress Bug description: The network work quota is configurable https://github.com/openstack/nova/blob/master/nova/conf/api.py#L307 But we forget enable network quota in the quota's update json-schema. This leads to user can't update network qutoa. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1606740/+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 1621379] Re: In the help msg of command host-evacuate,replace the optional arguments '--target_host' with '--target-host' more appropriate
That's definitly not a bug, rather a nit about the option. ** Changed in: nova Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1621379 Title: In the help msg of command host-evacuate,replace the optional arguments '--target_host' with '--target-host' more appropriate Status in OpenStack Compute (nova): Invalid Bug description: In the help msg of command host-evacuate,replace the optional arguments '--target_host' with '--target-host' more appropriate [root@devstack162 devstack]# nova help host-evacuate usage: nova host-evacuate [--target_host ] [--force] Evacuate all instances from failed host. Positional arguments: Name of host. Optional arguments: --target_host Name of target host. If no host is specified the scheduler will select a target. --force Force to not verify the scheduler if a host is provided. (Supported by API versions '2.29' - '2.latest') In the help information of other commands,never seen arguments with a '-' connection.People accustomed to the use of the '-' [root@devstack162 devstack]# nova host-evacuate tecsovs --target-host host1 usage: nova [--version] [--debug] [--os-cache] [--timings] [--os-region-name ] [--service-type ] [--service-name ] [--os-endpoint-type ] [--os-compute-api-version ] [--bypass-url ] [--insecure] [--os-cacert ] [--os-cert ] [--os-key ] [--timeout ] [--os-auth-type ] [--os-auth-url OS_AUTH_URL] [--os-domain-id OS_DOMAIN_ID] [--os-domain-name OS_DOMAIN_NAME] [--os-project-id OS_PROJECT_ID] [--os-project-name OS_PROJECT_NAME] [--os-project-domain-id OS_PROJECT_DOMAIN_ID] [--os-project-domain-name OS_PROJECT_DOMAIN_NAME] [--os-trust-id OS_TRUST_ID] [--os-default-domain-id OS_DEFAULT_DOMAIN_ID] [--os-default-domain-name OS_DEFAULT_DOMAIN_NAME] [--os-user-id OS_USER_ID] [--os-username OS_USERNAME] [--os-user-domain-id OS_USER_DOMAIN_ID] [--os-user-domain-name OS_USER_DOMAIN_NAME] [--os-password OS_PASSWORD] ... error: unrecognized arguments: --target-host host1 Try 'nova help ' for more information. [root@devstack162 devstack]# To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1621379/+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 1621391] Re: Error "Could not find resource cirros" even image is created
I guess you should provide the glance-api logs. ** No longer affects: python-openstackclient ** Also affects: glance Importance: Undecided Status: New ** Changed in: glance Status: New => Incomplete -- 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/1621391 Title: Error "Could not find resource cirros" even image is created Status in Glance: Incomplete Status in OpenStack Compute (nova): Invalid Bug description: Following error is coming even while launching VM in the provider network configuration. #openstack server create --flavor m1.tiny --image cirros --nic net- id=def81dc4-a0bf-4e1f-9a1f-fb020c89bf5e --security-group default --key-name mykey provider-instance "" Could not find resource cirros "" -- # openstack image list +--+++ | ID | Name | Status | +--+++ | bebbae11-5e44-4e13-8d83-dc373ef0cbd5 | cirros | active | +--+++ # openstack image show bebbae11-5e44-4e13-8d83-dc373ef0cbd5 +--+--+ | Field| Value| +--+--+ | checksum | ee1eca47dc88f4879d8a229cc70a07c6 | | container_format | bare | | created_at | 2016-09-05T06:04:31Z | | disk_format | qcow2| | file | /v2/images/bebbae11-5e44-4e13-8d83-dc373ef0cbd5/file | | id | bebbae11-5e44-4e13-8d83-dc373ef0cbd5 | | min_disk | 0| | min_ram | 0| | name | cirros | | owner| 9b237e3ba19c49df8c703085b6629425 | | protected| False| | schema | /v2/schemas/image| | size | 13287936 | | status | active | | tags | | | updated_at | 2016-09-05T06:04:31Z | | virtual_size | None | | visibility | public | +--+--+ To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1621391/+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 1621449] Re: Unit tests run on old db schema
Sorry, but the bug is invalid. The migrations should not run for unit tests. The tables get created from scratch for every test: keystone/common/sql/contract_repo/versions/002_password_created_at_not_nullable.py . ** Changed in: keystone Status: Confirmed => Invalid -- 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/1621449 Title: Unit tests run on old db schema Status in OpenStack Identity (keystone): Invalid Bug description: On current master (6a93e9b) most of unit tests do not run on new schema. For example, for test keystone.tests.unit.assignment.role_backends.test_sql.SqlRole.test_role_crud migration contract_repo/versions/002_password_created_at_not_nullable.py never gets applied. Keystone should run all migrations for a test prior to the test's execution. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1621449/+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 1582278] Re: [SR-IOV][CPU Pinning] nova compute can try to boot VM with CPUs from one NUMA node and PCI device from another NUMA node.
** Tags added: mitaka-backport-potential ** Also affects: nova (Ubuntu) Importance: Undecided Status: New ** Also affects: nova (Ubuntu Yakkety) Importance: Undecided Status: New ** Also affects: nova (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: nova (Ubuntu Xenial) Status: New => Triaged ** Changed in: nova (Ubuntu Xenial) Importance: Undecided => High ** Changed in: nova (Ubuntu Yakkety) Importance: Undecided => High ** Changed in: nova (Ubuntu Yakkety) Status: New => 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/1582278 Title: [SR-IOV][CPU Pinning] nova compute can try to boot VM with CPUs from one NUMA node and PCI device from another NUMA node. Status in OpenStack Compute (nova): Fix Released Status in nova package in Ubuntu: Fix Released Status in nova source package in Xenial: Triaged Status in nova source package in Yakkety: Fix Released Bug description: Environment: Two NUMA nodes on compute host (node-0 and node-1). One SR-IOV PCI device associated with NUMA node-1. Steps to reproduce: Steps to reproduce: 1) Deploy env with SR-IOV and CPU pinning enable 2) Create new flavor with cpu pinning: nova flavor-show m1.small.performance ++---+ | Property | Value | ++---+ | OS-FLV-DISABLED:disabled | False | | OS-FLV-EXT-DATA:ephemeral | 0 | | disk | 20 | | extra_specs | {"hw:cpu_policy": "dedicated", "hw:numa_nodes": "1"} | | id | 7b0e5ee0-0bf7-4a46-9653-9279a947c650 | | name | m1.small.performance | | os-flavor-access:is_public | True | | ram | 2048 | | rxtx_factor | 1.0 | | swap | | | vcpus | 1 | ++ 3) download ubuntu image 4) create sr-iov port and boot vm on this port with m1.small.performance flavor: NODE_1='node-4.test.domain.local' NODE_2='node-5.test.domain.local' NET_ID_1=$(neutron net-list | grep net_EW_2 | awk '{print$2}') neutron port-create $NET_ID_1 --binding:vnic-type direct --device_owner nova-compute --name sriov_23 port_id=$(neutron port-list | grep 'sriov_23' | awk '{print$2}') nova boot vm23 --flavor m1.small.performance --image ubuntu_image --availability-zone nova:$NODE_1 --nic port-id=$port_id --key-name vm_key Expected results: VM is an ACTIVE state Actual result: In most cases the state is ERROR with following logs: 2016-05-13 08:25:56.598 29097 ERROR nova.pci.stats [req-26138c0b-fa55-4ff8-8f3a-aad980e3c815 d864c4308b104454b7b46fb652f4f377 9322dead0b5d440986b12596d9cbff5b - - -] Failed to allocate PCI devices for instance. Unassigning devices back to pools. This should not happen, since the scheduler should have accurate information, and allocation during claims is controlled via a hold on the compute node semaphore 2016-05-13 08:25:57.502 29097 INFO nova.virt.libvirt.driver [req-26138c0b-fa55-4ff8-8f3a-aad980e3c815 d864c4308b104454b7b46fb652f4f377 9322dead0b5d440986b12596d9cbff5b - - -] [instance: 4e691469-893d-4b24-a0a8-00bbee0fa566] Creating image 2016-05-13 08:25:57.664 29097 ERROR nova.compute.manager [req-26138c0b-fa55-4ff8-8f3a-aad980e3c815 d864c4308b104454b7b46fb652f4f377 9322dead0b5d440986b12596d9cbff5b - - -] Instance failed network setup after 1 attempt(s) 2016-05-13 08:25:57.664 29097 ERROR nova.compute.manager Traceback (most recent call last): 2016-05-13 08:25:57.664 29097 ERROR nova.compute.manager File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 1570, in _allocate_network_async 2016-05-13 08:25:57.664 29097 ERROR nova.compute.manager bind_host_id=bind_host_id) 2016-05-13 08:25:57.664 29097 ERROR nova.compute.manager File "/usr/lib/python2.7/dist-packages/nova/network/neutronv2/api.py", line 666, in allocate_for_instance 2016-05-13 08:25:57.664 29097 ERROR nova.compute.manager self._delete_ports(neutron, instance, created_port_ids) 2016-05-13 08:25:57.664 29097 ERROR nova.compute.manager File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2016-05-13 08:25:57.664 29097 ERROR nova.compute.manager self.force_reraise() 2016-05-13 08:25:57.664 29097 ERROR nova.compute.manager File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2016-05-13 08:25:57.664 29097 ERROR nova.compute.manager six.reraise(self.type_, self.value, self.tb) 2016-05-13 08:25:57.664 29097 ERROR nova.compute.manager File "/usr/lib/python2.7/dist-packages/nova/network
[Yahoo-eng-team] [Bug 1620841] Re: uuid_list validator regression
Reviewed: https://review.openstack.org/366398 Committed: https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=3d043c0ebc0528508a7a7393388c674afd44bae1 Submitter: Jenkins Branch:master commit 3d043c0ebc0528508a7a7393388c674afd44bae1 Author: Henry Gessau Date: Tue Sep 6 18:22:34 2016 -0400 Fix regression in validate_uuid_list() Change https://review.openstack.org/358088 broke validate_uuid_list() by not including the valid_values parameter. Closes-Bug: #1620841 Change-Id: Ic75f4d1319bb88a9e4f9e4699575ce8e75829841 ** 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/1620841 Title: uuid_list validator regression Status in neutron: Fix Released Bug description: Change https://review.openstack.org/358088 broke validate_uuid_list() Validators are always called with a valid_values argument [1] even though it may not be used: https://github.com/openstack/neutron/blob/9.0.0.0b3/neutron/api/v2/attributes.py#L431 The flavors extension was broken by this since it uses uuid_list for the service_profiles attribute: https://github.com/openstack/neutron/blob/9.0.0.0b3/neutron/extensions/flavors.py#L109-L111 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1620841/+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 1621490] [NEW] Migration to Newton fails in 97c25b0d2353_add_name_desc
Public bug reported: The 97c25b0d2353_add_name_desc.py DB migration script is currently getting the primary key returned from the standardattributes table insert to use for the networksegments table insert. However, the inserted_primary_key attribute returns a list of all of the primary key values, so this will blow up (at least on MySQL, since it is trying to insert a list for an integer column. File "/usr/lib/python2.7/site-packages/alembic/runtime/migration.py", line 312, in run_migrations step.migration_fn(**kw) File "/usr/lib/python2.7/site-packages/neutron/db/migration/alembic_migrations/versions/newton/contract/97c25b0d2353_add_name_desc.py", line 74, in upgrade update_existing_records() File "/usr/lib/python2.7/site-packages/neutron/db/migration/alembic_migrations/versions/newton/contract/97c25b0d2353_add_name_desc.py", line 61, in update_existing_records TBL_MODEL.c.id == row[0]) File "/usr/lib64/python2.7/site-packages/sqlalchemy/orm/session.py", line 1046, in execute bind, close_with_result=True).execute(clause, params or {}) File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 914, in execute return meth(self, multiparams, params) File "/usr/lib64/python2.7/site-packages/sqlalchemy/sql/elements.py", line 323, in _execute_on_connection return connection._execute_clauseelement(self, multiparams, params) File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 1010, in _execute_clauseelement compiled_sql, distilled_params File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 1146, in _execute_context context) File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 1337, in _handle_dbapi_exception util.raise_from_cause(newraise, exc_info) File "/usr/lib64/python2.7/site-packages/sqlalchemy/util/compat.py", line 200, in raise_from_cause reraise(type(exception), exception, tb=exc_tb) File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 1139, in _execute_context context) File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/default.py", line 450, in do_execute cursor.execute(statement, parameters) File "/usr/lib64/python2.7/site-packages/MySQLdb/cursors.py", line 174, in execute self.errorhandler(self, exc, value) File "/usr/lib64/python2.7/site-packages/MySQLdb/connections.py", line 36, in defaulterrorhandler raise errorclass, errorvalue oslo_db.exception.DBError: (_mysql_exceptions.ProgrammingError) (1064, "You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ') WHERE networksegments.id = '5d84887d-ed87-4f5b-8661-6be327d3c541'' at line 1") [SQL: u'UPDATE networksegments SET standard_attr_id=%s WHERE networksegments.id = %s'] [parameters: ([10L], '5d84887d-ed87-4f5b-8661-6be327d3c541')] ** 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/1621490 Title: Migration to Newton fails in 97c25b0d2353_add_name_desc Status in neutron: New Bug description: The 97c25b0d2353_add_name_desc.py DB migration script is currently getting the primary key returned from the standardattributes table insert to use for the networksegments table insert. However, the inserted_primary_key attribute returns a list of all of the primary key values, so this will blow up (at least on MySQL, since it is trying to insert a list for an integer column. File "/usr/lib/python2.7/site-packages/alembic/runtime/migration.py", line 312, in run_migrations step.migration_fn(**kw) File "/usr/lib/python2.7/site-packages/neutron/db/migration/alembic_migrations/versions/newton/contract/97c25b0d2353_add_name_desc.py", line 74, in upgrade update_existing_records() File "/usr/lib/python2.7/site-packages/neutron/db/migration/alembic_migrations/versions/newton/contract/97c25b0d2353_add_name_desc.py", line 61, in update_existing_records TBL_MODEL.c.id == row[0]) File "/usr/lib64/python2.7/site-packages/sqlalchemy/orm/session.py", line 1046, in execute bind, close_with_result=True).execute(clause, params or {}) File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 914, in execute return meth(self, multiparams, params) File "/usr/lib64/python2.7/site-packages/sqlalchemy/sql/elements.py", line 323, in _execute_on_connection return connection._execute_clauseelement(self, multiparams, params) File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 1010, in _execute_clauseelement compiled_sql, distilled_params File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 1146, in _execute_context context) File "/usr/lib64/python2.7/site-p
[Yahoo-eng-team] [Bug 1619758] Related fix merged to keystone (master)
Reviewed: https://review.openstack.org/366832 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=59f117f6a87046391e1fc48e40d28a1da5b6cc1d Submitter: Jenkins Branch:master commit 59f117f6a87046391e1fc48e40d28a1da5b6cc1d Author: Lance Bragstad Date: Wed Sep 7 15:33:57 2016 + Log warning if null key is used for encryption The null key doesn't provide any real encryption protection. It only provides security through obscurity since the null key is a known thing. This commit makes it so we log a warning every time it is used for encryption. Change-Id: I10e8b6697c3b35c3ae6e8a1cec5e53f0913b42e6 Related-Bug: 1619758 ** 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/1619758 Title: Credential Encryption breaks deployments without Fernet Status in OpenStack Identity (keystone): Fix Released Status in tripleo: Confirmed Bug description: A recent change to encrypt credetials broke RDO/Tripleo deployments: 2016-09-02 17:16:55.074 17619 ERROR keystone.common.fernet_utils [req-31d60075-7e0e-401e-a93f-58297cd5439b f2caffbaf10d4e3da294c6366fe19a36 fd71b607cfa84539bf0440915ea2d94b - default default] Either [fernet_tokens] key_repository does not exist or Keystone does not have sufficient permission to access it: /etc/keystone/credential-keys/ 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi [req-31d60075-7e0e-401e-a93f-58297cd5439b f2caffbaf10d4e3da294c6366fe19a36 fd71b607cfa84539bf0440915ea2d94b - default default] MultiFernet requires at least one Fernet instance 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi Traceback (most recent call last): 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/wsgi.py", line 225, in __call__ 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi result = method(req, **params) 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/controller.py", line 164, in inner 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi return f(self, request, *args, **kwargs) 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/credential/controllers.py", line 69, in create_credential 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi ref = self.credential_api.create_credential(ref['id'], ref) 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/manager.py", line 124, in wrapped 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi __ret_val = __f(*args, **kwargs) 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/credential/core.py", line 106, in create_credential 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi credential_copy = self._encrypt_credential(credential) 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/credential/core.py", line 72, in _encrypt_credential 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi json.dumps(credential['blob']) 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/credential/providers/fernet/core.py", line 68, in encrypt 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi crypto, keys = get_multi_fernet_keys() 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/credential/providers/fernet/core.py", line 49, in get_multi_fernet_keys 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi crypto = fernet.MultiFernet(fernet_keys) 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi File "/usr/lib64/python2.7/site-packages/cryptography/fernet.py", line 128, in __init__ 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi "MultiFernet requires at least one Fernet instance" 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi ValueError: MultiFernet requires at least one Fernet instance 2016-09-02 17:16:55.074 17619 ERROR keystone.common.wsgi To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1619758/+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 1620445] Re: Correct PERF_EVENTS_CPU_FLAG_MAPPING due to libvirt changes
Reviewed: https://review.openstack.org/365842 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=a2d0b8d1b0954c6fdc622dda8fe8777e41566d92 Submitter: Jenkins Branch:master commit a2d0b8d1b0954c6fdc622dda8fe8777e41566d92 Author: Eli Qiao Date: Tue Sep 6 11:51:29 2016 +0800 Libvirt: Correct PERF_EVENTS_CPU_FLAG_MAPPING History: libvirt 1.3.3 had added perf event support for cmt, mbmt, mbml support when we landing the spec https://blueprints.launchpad.net/nova/+spec/support-perf-event . For the event cmt, mbmt, mbml, we requires that libvirt to expose some some specify cpu features, but libvirt 2.0.0 only has that expose merged `cpu_map.xml: add cmt/mbm feature to x86 (Qiaowei Ren)`, the capabilities changed to: Need to adopt this to let nova driver discover these features when enable cmt, mbmt, mbml event. That is to say: even libvirt 1.3.3 has support perf event, but nova cannot get noticed since libvirt don't expose cpu features until 2.0.0. This patch bump MIN_LIBVIRT_PERF_VERSION to 2.0.0, see: https://libvirt.org/formatdomain.html#elementsPerf Closes-Bug: #1620445 Change-Id: Ie896cfd478f4528903ca5dd56c61680837b646b7 ** 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/1620445 Title: Correct PERF_EVENTS_CPU_FLAG_MAPPING due to libvirt changes Status in OpenStack Compute (nova): Fix Released Bug description: Libvirt 2.0.0 has merge cpu_map.xml: add cmt/mbm feature to x86 (Qiaowei Ren), but the capabilities are: Need to adopt this in nova code. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1620445/+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 1605201] Re: OperationalError:'SAVEPOINT sa_savepoint_1 does not exist' during Rally boot_and_delete_server_with_secgroups
*** This bug is a duplicate of bug 1590298 *** https://bugs.launchpad.net/bugs/1590298 ** This bug has been marked a duplicate of bug 1590298 DB retry wrapper needs to look for savepoint errors -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1605201 Title: OperationalError:'SAVEPOINT sa_savepoint_1 does not exist' during Rally boot_and_delete_server_with_secgroups Status in neutron: New Bug description: Scale environment 45 compute node, 3 controller, Mitaka. During execution of Rally test boot_and_delete_server_with_secgroups error appeared in logs 2016-07-03 08:05:02.314 21792 INFO neutron.plugins.ml2.db [req-0d9d3031-0698-4a24-9ce0-4c886d641c91 ea3ede1f05e348e7853e9f 42c9426830 dc754a03f8de4b468396f8bc3d4a94ee - - -] Added segment af70f885-39df-4c2b-adfc-225d81c8c03c of type vxlan for ne twork 967af409-e2f4-418a-8919-a7e4a2133996 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource [req-1e786fea-0a7b-4613-9914-bda50be6028e d044072ee7c447bb922d 778565b329e2 715ca0f3f5a74733a49133c4d2202939 - - -] create failed 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource Traceback (most recent call last): 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource File "/usr/lib/python2.7/dist-packages/neutron/api/v2/resour ce.py", line 84, in resource 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource result = method(request=request, **args) 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource File "/usr/lib/python2.7/dist-packages/neutron/api/v2/base.p y", line 410, in create 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource return self._create(request, body, **kwargs) 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource File "/usr/lib/python2.7/dist-packages/oslo_db/api.py", line 148, in wrapper 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource ectxt.value = e.inner_exc 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.p y", line 220, in __exit__ 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource self.force_reraise() 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.p y", line 196, in force_reraise 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource six.reraise(self.type_, self.value, self.tb) 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource File "/usr/lib/python2.7/dist-packages/oslo_db/api.py", line 138, in wrapper 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource return f(*args, **kwargs) 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource File "/usr/lib/python2.7/dist-packages/neutron/api/v2/base.p 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource File "/usr/lib/python2.7/dist-packages/neutron/api/v2/base.p y", line 521, in _create 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource obj = do_create(body) 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource File "/usr/lib/python2.7/dist-packages/neutron/api/v2/base.p y", line 503, in do_create 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource request.context, reservation.reservation_id) 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.p y", line 220, in __exit__ 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource self.force_reraise() 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.p y", line 196, in force_reraise 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource six.reraise(self.type_, self.value, self.tb) 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource File "/usr/lib/python2.7/dist-packages/neutron/api/v2/base.p y", line 496, in do_create 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource return obj_creator(request.context, **kwargs) 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource File "/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/p lugin.py", line 696, in create_network 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource result, mech_context = self._create_network_db(context, ne twork) 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource File "/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/p lugin.py", line 659, in _create_network_db 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource self._ensure_default_security_group(context, tenant_id) 2016-07-03 08:05:02.316 21787 ERROR neutron.api.v2.resource File "/usr/lib/python2.7/dist-packages/neutron/db/securitygr oups_db.py", line 709, in _ensure_default_security_group 2
[Yahoo-eng-team] [Bug 1621392] Re: emit_event() is failing when locale/language is changed to other than english
** Also affects: nova/mitaka Importance: Undecided Status: New ** Changed in: nova/mitaka Status: New => Confirmed ** Changed in: nova/mitaka Importance: Undecided => Medium -- 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/1621392 Title: emit_event() is failing when locale/language is changed to other than english Status in OpenStack Compute (nova): In Progress Status in OpenStack Compute (nova) mitaka series: Confirmed Bug description: https://github.com/openstack/nova/blob/master/nova/virt/driver.py#L1439 is causing emit_event() failure Even though debug is not on, this line is causing emit_event() method failure. 2016-09-07 01:57:36.286 89568 INFO nova_powervm.virt.powervm.driver [req-9ef673ff-6d82-4a8e-b1fc-b7b635bc5bc8 - - - - -] [instance: bbb4890e-4e7f-47aa-b18f-cac527085966] Sending life cycle event for instance state change to: running 2016-09-07 01:57:36.287 89568 ERROR nova.virt.driver [req-9ef673ff-6d82-4a8e-b1fc-b7b635bc5bc8 - - - - -] Exception dispatching event [G'Startedฏูİı|]>: 'ascii' codec can't encode characters in position 82-86: ordinal not in range(128) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1621392/+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 1535549] Re: Multiple ports which have duplicated CIDRs are added as one router's interfaces if commands are executed at the same time
Reviewed: https://review.openstack.org/341427 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=17005132d1b17d608077090573c50af591afe670 Submitter: Jenkins Branch:master commit 17005132d1b17d608077090573c50af591afe670 Author: Anh Tran Date: Mon Aug 22 17:28:29 2016 +0700 Rollback port after failed to add it to router After failed to add port to a router, we cannot re-use and/or delete this port. With concurrent requests occuring, neutron will accept one request and the other will be rejected with an 'overlapped CIDR' message. Patch [1] fixed the race condition, but neutron raises 'Port already has an attached device' instead of 'overlapped CIDR', because neutron didn't cleanup the port when the request was retried. [1] https://review.openstack.org/#/c/303966/ This patch is needed to fix the bug completely. We will catch any exception when adding an interface by port to a router. After that, we rollback this port to its original state. Change-Id: Ib68aee164a3062648fc882012d57b5e381f52196 Closes-Bug: #1535549 ** 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/1535549 Title: Multiple ports which have duplicated CIDRs are added as one router's interfaces if commands are executed at the same time Status in neutron: Fix Released Bug description: I have three controller nodes and the Neutron servers on these controllers are set behind Pacemaker and HAProxy to realize active/active HA using DevStack. MariaDB Galera cluster is used as my database backend.I am using the latest codes. If one router is going to add two ports as its interface, however these two ports belong to two subnets which have duplicated CIDRs, the expected result would be the later API request would fail, with error message like BadRequest: Bad router request: Cidr 192.166.100.0/24 of subnet bee7663c-f0a0-4120-b556-944af7ca40cf overlaps with cidr 192.166.0.0/16 of subnet 697c82cf-82fd-4187-b460-7046c81f13dc. But if we run the two commands at the same time, both commands would succeed. The router would have two ports, which belong to subnets with duplicated CIDRs. I have tested for 30 times and only three times I could receive the expected error messages. How to reproduce: Step 1: Create a router $ neutron router-create router-port-test Step 2: Create two internal networks $ neutron net-create net1 $ neutron net-create net2 Step 3: Add one subnet to each of these two networks $ neutron subnet-create --name subnet1 net1 192.166.100.0/24 $ neutron subnet-create --name subnet2 net2 192.166.0.0/16 Here, we are creating two subnets on different networks with DUPLICATED CIDRs. Step 4: Create one port on each of these two networks $ neutron port-create --name port1 net1 $ neutron port-create --name port2 net2 Step 5: Add these two ports as the router's interface at the same time On controller1: $ neutron router-interface-add router-port-test port=port1 On controller2: $ neutron router-interface-add router-port-test port=port2 Both commands would work and we can see the ports listed on the router as http://paste.openstack.org/show/483839/ This bug is similar to [1]. We also have _check_for_dup_router_subnet method to check if subnets have duplicated CIDRs or not. The problem happens multiple API requests arrive at the same time and all the checks validate. [1] https://bugs.launchpad.net/neutron/+bug/1535226 [2] https://github.com/openstack/neutron/blob/master/neutron/db/l3_db.py#L535 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1535549/+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 1621536] [NEW] Remove paramiko dependency
Public bug reported: In Liberty, key pair creation (previously done via ssh-keygen) was replaced with paramiko library calls. While paramiko was listed as a dependency in Liberty, it wasn't actually used until that commit. Replace ssh exec calls with paramiko lib https://review.openstack.org/#/c/157931/ The above commit was unintentionally backwards incompatible. Specifically, it changed the SSH key ASN.1 encoding from DER to BER. Apparently golang doesn't support BER, meaning tools like Terraform no longer work with OpenStack. ssh-keygen-to-Paramiko change breaks third-party tools https://bugs.launchpad.net/nova/+bug/1483132 This has since been fixed in paramiko 2.0, but that major version bump doesn't make it into Nova until Newton, meaning these third-party tools are unusable for Liberty & Mitaka in the mean time. stable/liberty: paramiko>=1.13.0 upper-constraints: paramiko===1.16.0 stable/mitaka: paramiko>=1.16.0 upper-constraints: paramiko===1.16.0 master (newton): paramiko>=2.0 upper-constraints: paramiko===2.0.2 The bump to paramiko 2.0 was a big change, complete with a huge red warning in the changelog (which I suspect makes a backport that bumps the paramiko version to 2.0+ unrealistic for Liberty & Mitaka). http://www.paramiko.org/changelog.html http://bitprophet.org/blog/2016/04/23/paramiko-2.0-is-coming/ The switch to paramiko also introduced a number of Nova regressions along the way. Tolerate installation of pycryptodome https://review.openstack.org/#/c/279909/ crypto: Add support for Paramiko 2.x https://review.openstack.org/#/c/314592/ Drop paramiko < 2 compat code https://review.openstack.org/#/c/314639/ All this, coupled with the known security implications of using the older paramiko versions, makes me think that perhaps we should just go back to using ssh-keygen. Ideally, I'd like to backport this change all the way down to stable/liberty. ** Affects: nova Importance: Undecided Assignee: Diana Clarke (diana-clarke) Status: In Progress ** Changed in: nova Assignee: (unassigned) => Diana Clarke (diana-clarke) -- 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/1621536 Title: Remove paramiko dependency Status in OpenStack Compute (nova): In Progress Bug description: In Liberty, key pair creation (previously done via ssh-keygen) was replaced with paramiko library calls. While paramiko was listed as a dependency in Liberty, it wasn't actually used until that commit. Replace ssh exec calls with paramiko lib https://review.openstack.org/#/c/157931/ The above commit was unintentionally backwards incompatible. Specifically, it changed the SSH key ASN.1 encoding from DER to BER. Apparently golang doesn't support BER, meaning tools like Terraform no longer work with OpenStack. ssh-keygen-to-Paramiko change breaks third-party tools https://bugs.launchpad.net/nova/+bug/1483132 This has since been fixed in paramiko 2.0, but that major version bump doesn't make it into Nova until Newton, meaning these third-party tools are unusable for Liberty & Mitaka in the mean time. stable/liberty: paramiko>=1.13.0 upper-constraints: paramiko===1.16.0 stable/mitaka: paramiko>=1.16.0 upper-constraints: paramiko===1.16.0 master (newton): paramiko>=2.0 upper-constraints: paramiko===2.0.2 The bump to paramiko 2.0 was a big change, complete with a huge red warning in the changelog (which I suspect makes a backport that bumps the paramiko version to 2.0+ unrealistic for Liberty & Mitaka). http://www.paramiko.org/changelog.html http://bitprophet.org/blog/2016/04/23/paramiko-2.0-is-coming/ The switch to paramiko also introduced a number of Nova regressions along the way. Tolerate installation of pycryptodome https://review.openstack.org/#/c/279909/ crypto: Add support for Paramiko 2.x https://review.openstack.org/#/c/314592/ Drop paramiko < 2 compat code https://review.openstack.org/#/c/314639/ All this, coupled with the known security implications of using the older paramiko versions, makes me think that perhaps we should just go back to using ssh-keygen. Ideally, I'd like to backport this change all the way down to stable/liberty. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1621536/+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 1621180] Re: specifying apt_mirror of '' renders empty entries in /etc/apt/sources.list for uri
This bug was fixed in the package cloud-init - 0.7.7-26-g058dd75-0ubuntu1 --- cloud-init (0.7.7-26-g058dd75-0ubuntu1) yakkety; urgency=medium * New upstream snapshot. - apt config conversion: treat empty string as not provided. (LP: #1621180) - Fix typo in default keys for phone_home [Roland Sommer] (LP: #1607810) - salt minion: update default pki directory for newer salt minion. (LP: #1609899) - bddeb: add --release flag to specify the release in changelog. -- Scott Moser Thu, 08 Sep 2016 09:36:52 -0400 ** Changed in: cloud-init (Ubuntu) Status: Confirmed => Fix Released -- 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/1621180 Title: specifying apt_mirror of '' renders empty entries in /etc/apt/sources.list for uri Status in cloud-init: Confirmed Status in cloud-init package in Ubuntu: Fix Released Status in juju-core package in Ubuntu: New Bug description: $ cat /tmp/foo.ud #cloud-config apt_mirror: '' $ lxc launch ubuntu-daily:yakkety sm-y0 "--config=user.user-data=$(cat /tmp/foo.ud)" $ sleep 10 $ lxc exec sm-y0 grep yakkety /etc/apt/sources.list | head -n 3 deb yakkety main restricted deb-src yakkety main restricted deb yakkety-updates main restricted basically if you provide an empty apt_mirror in the old format, then it is taken as providing an apt mirror. This non-true value should just be the same as not providing it. ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: cloud-init 0.7.7-22-g763f403-0ubuntu1 ProcVersionSignature: Ubuntu 4.4.0-9136.55-generic 4.4.16 Uname: Linux 4.4.0-9136-generic x86_64 ApportVersion: 2.20.3-0ubuntu7 Architecture: amd64 Date: Wed Sep 7 17:12:11 2016 PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) SourcePackage: cloud-init UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1621180/+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 1480305] Re: DBDeadlock inserting into instance_extra
** Changed in: nova Assignee: (unassigned) => John Garbutt (johngarbutt) ** Also affects: nova/mitaka Importance: Undecided Status: New ** Changed in: nova/mitaka Status: New => Confirmed ** Changed in: nova/mitaka Importance: Undecided => Medium -- 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/1480305 Title: DBDeadlock inserting into instance_extra Status in OpenStack Compute (nova): Triaged Status in OpenStack Compute (nova) mitaka series: Confirmed Bug description: http://logs.openstack.org/78/193278/15/check/gate-tempest-dsvm- full/7e16644/logs/screen-n-api.txt.gz?level=TRACE#_2015-07-31_01_52_20_792 2015-07-31 01:52:20.792 ERROR nova.api.openstack [req-ea281178-5948-47a1-815d-e97f12b2412b tempest-FloatingIPsTestJSON-1949129213 tempest-FloatingIPsTestJSON-96720078] Caught error: (pymysql.err.InternalError) (1213, u'Deadlock found when trying to get lock; try restarting transaction') [SQL: u'INSERT INTO instance_extra (created_at, updated_at, deleted_at, deleted, instance_uuid, numa_topology, pci_requests, flavor, vcpu_model) VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s)'] [parameters: (datetime.datetime(2015, 7, 31, 1, 52, 20, 772556), None, None, 0, '645dcef8-0852-40b5-ac1f-e422b7909e90', None, '[]', '{"new": null, "old": null, "cur": {"nova_object.version": "1.1", "nova_object.name": "Flavor", "nova_object.data": {"disabled": false, "root_gb": 0, "name": "m1.nano", "flavorid": "42", "deleted": false, "created_at": "2015-07-31T01:50:53Z", "ephemeral_gb": 0, "updated_at": null, "memory_mb": 64, "vcpus": 1, "extra_specs": {}, "swap": 0, "rxtx_factor": 1.0, "is_public": true, "dele ted_at": null, "vcpu_weight": 0, "id": 6}, "nova_object.namespace": "nova"}}', None)] 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack Traceback (most recent call last): 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack File "/opt/stack/new/nova/nova/api/openstack/__init__.py", line 128, in __call__ 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack return req.get_response(self.application) 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line 1317, in send 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack application, catch_exc_info=False) 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line 1281, in call_application 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack app_iter = application(self.environ, start_response) 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 144, in __call__ 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack return resp(environ, start_response) 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 130, in __call__ 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack resp = self.call_func(req, *args, **self.kwargs) 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 195, in call_func 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack return self.func(req, *args, **kwargs) 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/keystonemiddleware/auth_token/__init__.py", line 434, in __call__ 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack response = req.get_response(self._app) 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line 1317, in send 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack application, catch_exc_info=False) 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line 1281, in call_application 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack app_iter = application(self.environ, start_response) 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 144, in __call__ 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack return resp(environ, start_response) 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 144, in __call__ 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack return resp(environ, start_response) 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/routes/middleware.py", line 136, in __call__ 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack response = self.app(environ, start_response) 2015-07
[Yahoo-eng-team] [Bug 1616222] Re: All Table Templates should support template overrides
Reviewed: https://review.openstack.org/359437 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=a988f3c457fca8cd990eec507638cf0dcc0c5011 Submitter: Jenkins Branch:master commit a988f3c457fca8cd990eec507638cf0dcc0c5011 Author: Ryan Peters Date: Tue Aug 23 16:27:26 2016 -0500 All Table Templates should support template overrides Overrides were not possible on some templates due to not reading from the "options" array while assigning values in the DataTableOptions class. Change-Id: Ia0905cbf772445c39006d10a5a040b5244587914 Closes-bug: #1616222 ** Changed in: horizon Status: In Progress => Fix Released -- 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/1616222 Title: All Table Templates should support template overrides Status in OpenStack Dashboard (Horizon): Fix Released Bug description: Only some of the table templates are overridable through the meta DataTableOptions class. They would ALL be overrideable. self.template = getattr(options, 'template', 'horizon/common/_data_table.html') The other templates, listed below, should also use the 'getattr' option. self.row_actions_dropdown_template = ('horizon/common/_data_table_' 'row_actions_dropdown.html') self.row_actions_row_template = ('horizon/common/_data_table_' 'row_actions_row.html') self.table_actions_template = \ 'horizon/common/_data_table_table_actions.html' To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1616222/+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 1619085] Re: incorrect description in nova-api.log about quota check
Reviewed: https://review.openstack.org/364698 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=0d4ad97c26ceff1f3bed92992b49e4262b33e9da Submitter: Jenkins Branch:master commit 0d4ad97c26ceff1f3bed92992b49e4262b33e9da Author: to-niwa Date: Fri Sep 2 17:00:14 2016 +0900 incorrect description in nova-api.log about quota check Change an argument related to logging for user quota check because debug-level log shows only tenant quota even if user quota is defined. Change-Id: I07f585205041e36316d689f9f70c76d82b18 Closes-Bug: #1619085 ** Changed in: nova Status: Fix Committed => 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/1619085 Title: incorrect description in nova-api.log about quota check Status in OpenStack Compute (nova): Fix Released Bug description: * Bug: When checking quotas and trying to reserve resources for instances, the process prints some incorrect information to nova-api.log. * Solution: In line 533 of the code file 'nova.quota.py'(class:DbQuotaDriver,method:reserve) , the argument 'quotas' should be 'user_quotas'. Original code(line 530-533,nova.quota.py): LOG.debug('Quotas for project %(project_id)s and user %(user_id)s ' 'after resource sync: %(quotas)s', {'project_id': project_id, 'user_id': user_id, 'quotas': quotas}) Should be: LOG.debug('Quotas for project %(project_id)s and user %(user_id)s ' 'after resource sync: %(quotas)s', {'project_id': project_id, 'user_id': user_id, 'quotas': user_quotas}) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1619085/+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 1621564] [NEW] Neutron port is not deleted after instance is deleted
Public bug reported: For some reason, instance can be stuck in scheduling or error state, e.g. incompatible image, lack of property in image. In this case, the neutron port is not deleted after instance has been deleted. This happens with recent trunk. By default, devstack creates a KVM image without --property hypervisor_type=qemu. Instance boot with this image is stuck in scheduling state. Port is still there after delete this instance. ** 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/1621564 Title: Neutron port is not deleted after instance is deleted Status in OpenStack Compute (nova): New Bug description: For some reason, instance can be stuck in scheduling or error state, e.g. incompatible image, lack of property in image. In this case, the neutron port is not deleted after instance has been deleted. This happens with recent trunk. By default, devstack creates a KVM image without --property hypervisor_type=qemu. Instance boot with this image is stuck in scheduling state. Port is still there after delete this instance. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1621564/+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 1534652] Re: Host machine exposed to tenant networks via IPv6
** Changed in: ossn 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/1534652 Title: Host machine exposed to tenant networks via IPv6 Status in networking-midonet: Fix Released Status in neutron: Fix Released Status in neutron kilo series: New Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: When creating a new interface Neutron creates interface and brings link up without disabling default IPv6 binding. By default Linux brings IPv6 link local addresses to all interfaces, this is different behavior than IPv4 where an administrator must explicitly configure an address on the interface. The is significantly exposed in LinuxBridgeManager ensure_vlan() and ensure_vxlan() where a new VLAN or VXLAN interface is created and set link up before being enslaved in the bridge. In the case of compute node joining and existing network, there is a time window in which VLAN or VXLAN interface is created and has connectivity to the tenant network before it has been enslaved in bridge. Under normal circumstances this time window is less than the time needed to preform IPv6 duplicate address detection, but under high load this assumption may not hold. I recommend explicitly disabling IPv6 via sysctl on each interface which will be attached to a bridge prior bringing the interface link up. This is already done for the bridge interfaces themselves, but should be done for all Neutron configured interfaces in the default namespace. This issue was referenced in https://bugs.launchpad.net/neutron/+bug/1459856 Related issue addressed being addressed in Nova: https://review.openstack.org/#/c/198054/ To manage notifications about this bug go to: https://bugs.launchpad.net/networking-midonet/+bug/1534652/+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 1621574] [NEW] Instance fails to delete while building in cells v1 due to "ObjectActionError: Object action destroy failed because: host changed"
Public bug reported: Seeing this in a cells v1 job here: http://logs.openstack.org/55/367455/1/check/gate-tempest-dsvm- cells/1d8af83/logs/screen-n-api.txt.gz#_2016-09-08_15_59_02_553 2016-09-08 15:59:02.553 15924 ERROR nova.api.openstack.extensions [req-0f23fed6-0aaf-461f-96d8-f4aa5055b208 tempest-ListServersNegativeTestJSON-1414534476 tempest-ListServersNegativeTestJSON-1414534476] Unexpected exception in API method 2016-09-08 15:59:02.553 15924 ERROR nova.api.openstack.extensions Traceback (most recent call last): 2016-09-08 15:59:02.553 15924 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/api/openstack/extensions.py", line 338, in wrapped 2016-09-08 15:59:02.553 15924 ERROR nova.api.openstack.extensions return f(*args, **kwargs) 2016-09-08 15:59:02.553 15924 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/api/openstack/compute/servers.py", line 915, in delete 2016-09-08 15:59:02.553 15924 ERROR nova.api.openstack.extensions self._delete(req.environ['nova.context'], req, id) 2016-09-08 15:59:02.553 15924 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/api/openstack/compute/servers.py", line 767, in _delete 2016-09-08 15:59:02.553 15924 ERROR nova.api.openstack.extensions self.compute_api.delete(context, instance) 2016-09-08 15:59:02.553 15924 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/compute/cells_api.py", line 213, in delete 2016-09-08 15:59:02.553 15924 ERROR nova.api.openstack.extensions self._handle_cell_delete(context, instance, 'delete') 2016-09-08 15:59:02.553 15924 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/compute/cells_api.py", line 224, in _handle_cell_delete 2016-09-08 15:59:02.553 15924 ERROR nova.api.openstack.extensions if self._delete_while_booting(context, instance): 2016-09-08 15:59:02.553 15924 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/compute/api.py", line 1648, in _delete_while_booting 2016-09-08 15:59:02.553 15924 ERROR nova.api.openstack.extensions instance.destroy() 2016-09-08 15:59:02.553 15924 ERROR nova.api.openstack.extensions File "/usr/local/lib/python2.7/dist-packages/oslo_versionedobjects/base.py", line 226, in wrapper 2016-09-08 15:59:02.553 15924 ERROR nova.api.openstack.extensions return fn(self, *args, **kwargs) 2016-09-08 15:59:02.553 15924 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/objects/instance.py", line 555, in destroy 2016-09-08 15:59:02.553 15924 ERROR nova.api.openstack.extensions reason='host changed') 2016-09-08 15:59:02.553 15924 ERROR nova.api.openstack.extensions ObjectActionError: Object action destroy failed because: host changed 2016-09-08 15:59:02.553 15924 ERROR nova.api.openstack.extensions http://logs.openstack.org/55/367455/1/check/gate-tempest-dsvm- cells/1d8af83/console.html#_2016-09-08_16_13_48_892443 logs.openstack.org/55/367455/1/check/gate-tempest-dsvm- cells/1d8af83/logs/tempest.txt.gz#_2016-09-08_15_59_02_558 In this test it creates a server and then immediately deletes it without waiting for it to be ACTIVE first. I wonder if we're racing with any of the BuildRequest stuff that's new in Newton. http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22ObjectActionError%3A%20Object%20action%20destroy%20failed%20because%3A%20host%20changed%5C%22%20AND%20message%3A%5C%22_handle_cell_delete%5C%22%20AND%20tags%3A%5C%22screen-n-api.txt%5C%22&from=7d 10 hits in the last 7 days, check and gate, master (newton) only at this point. ** Affects: nova Importance: Medium Assignee: Andrew Laski (alaski) Status: Confirmed ** Tags: cells ** Changed in: nova Status: New => Confirmed ** Summary changed: - Instance fails to delete in cells v1 due to "ObjectActionError: Object action destroy failed because: host changed" + Instance fails to delete while building in cells v1 due to "ObjectActionError: Object action destroy failed because: host changed" -- 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/1621574 Title: Instance fails to delete while building in cells v1 due to "ObjectActionError: Object action destroy failed because: host changed" Status in OpenStack Compute (nova): Confirmed Bug description: Seeing this in a cells v1 job here: http://logs.openstack.org/55/367455/1/check/gate-tempest-dsvm- cells/1d8af83/logs/screen-n-api.txt.gz#_2016-09-08_15_59_02_553 2016-09-08 15:59:02.553 15924 ERROR nova.api.openstack.extensions [req-0f23fed6-0aaf-461f-96d8-f4aa5055b208 tempest-ListServersNegativeTestJSON-1414534476 tempest-ListServersNegativeTestJSON-1414534476] Unexpected exception in API method 2016-09-08 15:59:02.553 15924 ERROR nova.api.openstack.extensions Traceback (most recent call last): 2016-09-08 15:59:
[Yahoo-eng-team] [Bug 1480305] Re: DBDeadlock inserting into instance_extra
Reviewed: https://review.openstack.org/292800 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=df15e467b61fee781e78b07bf910d6b411bafd44 Submitter: Jenkins Branch:master commit df15e467b61fee781e78b07bf910d6b411bafd44 Author: John Garbutt Date: Tue Mar 15 10:21:47 2016 + db: retry on deadlocks while adding an instance We are hitting deadlocks in the gate when we are inserting the new instance_extra row into the DB. We should follow up this fix and look at way to avoid the deadlock happening rather than retrying it. It currently doesn't happen too often, so this should be enough to stop the problem while we work on a better fix. Closes-Bug: #1480305 Change-Id: Iba218bf28c7d1e6040c551fe836d6fa5e5e45f4d ** Changed in: nova Status: Triaged => 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/1480305 Title: DBDeadlock inserting into instance_extra Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) mitaka series: Confirmed Bug description: http://logs.openstack.org/78/193278/15/check/gate-tempest-dsvm- full/7e16644/logs/screen-n-api.txt.gz?level=TRACE#_2015-07-31_01_52_20_792 2015-07-31 01:52:20.792 ERROR nova.api.openstack [req-ea281178-5948-47a1-815d-e97f12b2412b tempest-FloatingIPsTestJSON-1949129213 tempest-FloatingIPsTestJSON-96720078] Caught error: (pymysql.err.InternalError) (1213, u'Deadlock found when trying to get lock; try restarting transaction') [SQL: u'INSERT INTO instance_extra (created_at, updated_at, deleted_at, deleted, instance_uuid, numa_topology, pci_requests, flavor, vcpu_model) VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s)'] [parameters: (datetime.datetime(2015, 7, 31, 1, 52, 20, 772556), None, None, 0, '645dcef8-0852-40b5-ac1f-e422b7909e90', None, '[]', '{"new": null, "old": null, "cur": {"nova_object.version": "1.1", "nova_object.name": "Flavor", "nova_object.data": {"disabled": false, "root_gb": 0, "name": "m1.nano", "flavorid": "42", "deleted": false, "created_at": "2015-07-31T01:50:53Z", "ephemeral_gb": 0, "updated_at": null, "memory_mb": 64, "vcpus": 1, "extra_specs": {}, "swap": 0, "rxtx_factor": 1.0, "is_public": true, "dele ted_at": null, "vcpu_weight": 0, "id": 6}, "nova_object.namespace": "nova"}}', None)] 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack Traceback (most recent call last): 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack File "/opt/stack/new/nova/nova/api/openstack/__init__.py", line 128, in __call__ 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack return req.get_response(self.application) 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line 1317, in send 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack application, catch_exc_info=False) 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line 1281, in call_application 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack app_iter = application(self.environ, start_response) 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 144, in __call__ 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack return resp(environ, start_response) 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 130, in __call__ 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack resp = self.call_func(req, *args, **self.kwargs) 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 195, in call_func 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack return self.func(req, *args, **kwargs) 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/keystonemiddleware/auth_token/__init__.py", line 434, in __call__ 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack response = req.get_response(self._app) 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line 1317, in send 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack application, catch_exc_info=False) 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line 1281, in call_application 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack app_iter = application(self.environ, start_response) 2015-07-31 01:52:20.792 18304 ERROR nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 144, in __call__ 2015-07-31 01:5
[Yahoo-eng-team] [Bug 1621582] [NEW] use_usb_tablet and pointer_model have different defaults making switching hard
Public bug reported: The use_usb_tablet config option is deprecated in Newton and replaced with the pointer_model config option. The use_usb_tablet option defaults to True, and pointer_model defaults to None, and the only choices are None and 'usbtablet'. If pointer_model is not set, then use_usb_tablet is used as a fallback while transitioning to the new pointer_model option. The problem is they have different default values/behaviors. Currently devstack sets use_usb_tablet=False, which gives us warnings in CI runs because the option is deprecated. But changing it to None will make the nova code fallback to CONF.use_usb_tablet: https://github.com/openstack/nova/blob/df15e467b61fee781e78b07bf910d6b411bafd44/nova/virt/libvirt/driver.py#L4541 So you can't just remove using use_usb_tablet if you want it disabled (set to False) because the code will use the default and set it to True. I tried setting pointer_model to '' to get around the None check in the nova code, but that fails because we're using choices with the config option so only None and 'usbtablet' are allowed: http://logs.openstack.org/26/367526/1/check/gate-tempest-dsvm-neutron- full-ubuntu- xenial/1479bdd/logs/screen-n-api.txt.gz?level=TRACE#_2016-09-08_17_31_42_490 This makes the transition from use_usb_tablet to pointer_model hard for anyone that wants this set to False like devstack does. We could allow setting '' as a choice for pointer_model to workaround this until use_usb_tablet is gone. We could also default use_usb_tablet to False to mimic pointer_model, but that's a change in default behavior without any warning for a release. We could also just ignore this and drop use_usb_tablet in Ocata and anyone that was setting it in nova.conf will just not have it picked up and used, but that's annoying for anyone that wants to get ahead of cleaning out deprecation warnings before upgrading to ocata. ** Affects: nova Importance: Undecided Status: Confirmed ** Changed in: nova Status: New => Confirmed -- 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/1621582 Title: use_usb_tablet and pointer_model have different defaults making switching hard Status in OpenStack Compute (nova): Confirmed Bug description: The use_usb_tablet config option is deprecated in Newton and replaced with the pointer_model config option. The use_usb_tablet option defaults to True, and pointer_model defaults to None, and the only choices are None and 'usbtablet'. If pointer_model is not set, then use_usb_tablet is used as a fallback while transitioning to the new pointer_model option. The problem is they have different default values/behaviors. Currently devstack sets use_usb_tablet=False, which gives us warnings in CI runs because the option is deprecated. But changing it to None will make the nova code fallback to CONF.use_usb_tablet: https://github.com/openstack/nova/blob/df15e467b61fee781e78b07bf910d6b411bafd44/nova/virt/libvirt/driver.py#L4541 So you can't just remove using use_usb_tablet if you want it disabled (set to False) because the code will use the default and set it to True. I tried setting pointer_model to '' to get around the None check in the nova code, but that fails because we're using choices with the config option so only None and 'usbtablet' are allowed: http://logs.openstack.org/26/367526/1/check/gate-tempest-dsvm-neutron- full-ubuntu- xenial/1479bdd/logs/screen-n-api.txt.gz?level=TRACE#_2016-09-08_17_31_42_490 This makes the transition from use_usb_tablet to pointer_model hard for anyone that wants this set to False like devstack does. We could allow setting '' as a choice for pointer_model to workaround this until use_usb_tablet is gone. We could also default use_usb_tablet to False to mimic pointer_model, but that's a change in default behavior without any warning for a release. We could also just ignore this and drop use_usb_tablet in Ocata and anyone that was setting it in nova.conf will just not have it picked up and used, but that's annoying for anyone that wants to get ahead of cleaning out deprecation warnings before upgrading to ocata. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1621582/+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 1621605] [NEW] placement api doesn't have tests to confirm unicode entry
Public bug reported: There are lots of tests of the placement api but none of them use unicode data. The only place where unicode is valid is in resource provider name so we should have some gabbi tests of that. ** Affects: nova Importance: Undecided Assignee: Chris Dent (cdent) Status: In Progress ** Tags: api placement scheduler -- 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/1621605 Title: placement api doesn't have tests to confirm unicode entry Status in OpenStack Compute (nova): In Progress Bug description: There are lots of tests of the placement api but none of them use unicode data. The only place where unicode is valid is in resource provider name so we should have some gabbi tests of that. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1621605/+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 1585831] Re: Horizon dashboard leaks internal information through cookies
OSSN released: https://wiki.openstack.org/wiki/OSSN/OSSN-0073 ** Changed in: ossn Status: Confirmed => Fix Released -- 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/1585831 Title: Horizon dashboard leaks internal information through cookies Status in OpenStack Dashboard (Horizon): Invalid Status in OpenStack Security Notes: Fix Released Bug description: When horizon is configured where: 1) internalURL and publicURL are on different networks 2) horizon uses the internalURL endpoint for authentication The cookie "login_region" will be set to the value configured as OPENSTACK_KEYSTONE_URL. This URL contains the IP address of the internalURL of keystone. In the case of a deployment where the internal network is different than the public network, the IP address of the internal network is considered sensitive information. By putting the OPENSTACK_KEYSTONE_URL in the cookie that is sent to the public network, horizon leaks the values of the internal network IP addresses. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1585831/+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 1586931] Re: TestServerBasicOps: Test fails when deleting server and floating ip almost at the same time
** Changed in: nova/liberty Status: In Progress => 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/1586931 Title: TestServerBasicOps: Test fails when deleting server and floating ip almost at the same time Status in neutron: Fix Released Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) liberty series: Won't Fix Status in OpenStack Compute (nova) mitaka series: Fix Committed Status in openstack-ansible: Fix Released Status in tempest: Won't Fix Bug description: In tempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basic_ops, after last step: self.servers_client.delete_server(self.instance['id']) it doesn't wait for the server to be deleted, and then deletes the floating ip immediately in the clean up, this will cause faiure: Here is the partial log: 2016-05-29 21:51:29.499 29791 INFO tempest.lib.common.rest_client [req-c3588ac4-21ca-47c3-bdb1-62088efd7a8b ] Request (TestServerBasicOps:test_server_basic_ops): 204 DELETE https://:8774/v2/159886ce087a4f8fbfbcab14947d96b1/servers/6d44763b-ea79-4b5b-b57e-714191802c7c 0.465s 2016-05-29 21:51:29.499 29791 DEBUG tempest.lib.common.rest_client [req-c3588ac4-21ca-47c3-bdb1-62088efd7a8b ] Request - Headers: {'Content-Type': 'application/json', 'Accept': 'application/json', 'X-Auth-Token': ''} Body: None Response - Headers: {'status': '204', 'content-length': '0', 'content-location': 'https://:8774/v2/159886ce087a4f8fbfbcab14947d96b1/servers/6d44763b-ea79-4b5b-b57e-714191802c7c', 'date': 'Mon, 30 May 2016 02:51:29 GMT', 'x-compute-request-id': 'req-c3588ac4-21ca-47c3-bdb1-62088efd7a8b', 'content-type': 'application/json', 'connection': 'close'} Body: _log_request_full tempest/lib/common/rest_client.py:422 2016-05-29 21:51:30.410 29791 INFO tempest.lib.common.rest_client [req-db2323f5-3d58-4fd7-ae51-44f5525c6689 ] Request (TestServerBasicOps:_run_cleanups): 500 DELETE https://:8774/v2/159886ce087a4f8fbfbcab14947d96b1/os-floating-ips/948912f6-ce03-4856-922b-59c4f16d3740 0.910s 2016-05-29 21:51:30.410 29791 DEBUG tempest.lib.common.rest_client [req-db2323f5-3d58-4fd7-ae51-44f5525c6689 ] Request - Headers: {'Content-Type': 'application/json', 'Accept': 'application/json', 'X-Auth-Token': ''} Body: None Response - Headers: {'status': '500', 'content-length': '224', 'content-location': 'https://:8774/v2/159886ce087a4f8fbfbcab14947d96b1/os-floating-ips/948912f6-ce03-4856-922b-59c4f16d3740', 'date': 'Mon, 30 May 2016 02:51:30 GMT', 'x-compute-request-id': 'req-db2323f5-3d58-4fd7-ae51-44f5525c6689', 'content-type': 'application/json; charset=UTF-8', 'connection': 'close'} Body: {"computeFault": {"message": "Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.\n", "code": 500}} To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1586931/+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 1621650] [NEW] PortNotFound in DHCP agent logs
Public bug reported: The DHCP agent can call update_dhcp_port, in which case a PortNotFound exception can be thrown. This currently goes uncaught and leads to lots of log noise. http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22Remote%20error%3A%20PortNotFound%5C%22 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server [req-cadd9638-976b-4c45-8a67-b8e027c31b07 - -] Exception during message handling 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server Traceback (most recent call last): 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", line 133, in _process_incoming 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server res = self.dispatcher.dispatch(message) 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 150, in dispatch 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server return self._do_dispatch(endpoint, method, ctxt, args) 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 121, in _do_dispatch 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server result = func(ctxt, **new_args) 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server File "/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 151, in wrapper 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server ectxt.value = e.inner_exc 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server self.force_reraise() 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server six.reraise(self.type_, self.value, self.tb) 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server File "/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 139, in wrapper 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server return f(*args, **kwargs) 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server File "/opt/stack/new/neutron/neutron/db/api.py", line 82, in wrapped 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server traceback.format_exc()) 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server self.force_reraise() 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server six.reraise(self.type_, self.value, self.tb) 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server File "/opt/stack/new/neutron/neutron/db/api.py", line 77, in wrapped 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server return f(*args, **kwargs) 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server File "/opt/stack/new/neutron/neutron/api/rpc/handlers/dhcp_rpc.py", line 274, in update_dhcp_port 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server return self._port_action(plugin, context, port, 'update_port') 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server File "/opt/stack/new/neutron/neutron/api/rpc/handlers/dhcp_rpc.py", line 100, in _port_action 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server return plugin.update_port(context, port['id'], port) 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server File "/opt/stack/new/neutron/neutron/common/utils.py", line 618, in inner 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server return f(self, context, *args, **kwargs) 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server File "/opt/stack/new/neutron/neutron/plugins/ml2/plugin.py", line 1364, in update_port 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server raise exc.PortNotFound(port_id=id) 2016-09-08 07:23:35.069 13627 ERROR oslo_messaging.rpc.server PortNotFound: Port 3671e6b0-b969-4949-a486-d708e43aa60c could not be found. ** Affects: neutron Importance: Undecided Assignee: Kevin Benton (kevinbenton) Status: New ** Changed in: neutron Milestone: None => mitaka-rc1 ** Changed in: neutron Assignee: (unassigned) => Kevin Benton (kevinbenton) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1621650 Title
[Yahoo-eng-team] [Bug 1617353] Re: Edit 'Protected' for namespace is missing
Reviewed: https://review.openstack.org/364361 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=6fb02c52681e4c4fd43fc4abc8947cc8e6331abd Submitter: Jenkins Branch:master commit 6fb02c52681e4c4fd43fc4abc8947cc8e6331abd Author: Luis Daniel Castellanos Date: Thu Sep 1 09:37:20 2016 -0500 Update action for namespaces table public/protected attributes With the inline edit deprecation the ability to edit the public/protected attributes for a namespace was also removed. This patch adds an update action to the namespaces table so users can edit these attributes. Change-Id: I7476b49a5bfe161c46dfb5d622bfec924da7 Closes-Bug: #1617353 ** Changed in: horizon Status: In Progress => Fix Released -- 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/1617353 Title: Edit 'Protected' for namespace is missing Status in OpenStack Dashboard (Horizon): Fix Released Bug description: Now the table cell inline edit is removed, the previous inline edit protected is missing, so there should provide a edit form for editing namespace's attributes. Please see the screenshot for more detail. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1617353/+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 1561176] Re: Single tab workflows are styled poorly
Reviewed: https://review.openstack.org/345062 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=a0bd5756393733cf9934644273febda4e601acbe Submitter: Jenkins Branch:master commit a0bd5756393733cf9934644273febda4e601acbe Author: Yosef Hoffman Date: Thu Jun 30 07:04:15 2016 -0400 Hide nav in workflows if only one tab Currently, workflows use nav-pills for tabs, and this causes the tabs to look like buttons, which looks confusing in single tab workflows. This patch just changes workflows to hide the nav-pills if there is only one tab. Change-Id: I11d17535180cfa38b32463143f0e40cf7a119d9c Closes-Bug: #1561176 ** Changed in: horizon Status: In Progress => Fix Released -- 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/1561176 Title: Single tab workflows are styled poorly Status in OpenStack Dashboard (Horizon): Fix Released Bug description: Workflows with a single nav-pill tab look like they just have a button instead, such as on Admin/Instances/Edit Instance or Admin/Network/[detail]/Create Subnet To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1561176/+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 1621667] [NEW] cc_locale fails on CentOS 7
Public bug reported: Sep 08 17:14:56 testing03.novalocal cloud-init[1465]: [CLOUDINIT] handlers.py[DEBUG]: finish: modules-config/config-locale: FAIL: running config-locale with frequency once-per-instance Sep 08 17:14:56 testing03.novalocal cloud-init[1465]: [CLOUDINIT] util.py[WARNING]: Running module locale () failed Sep 08 17:14:56 testing03.novalocal cloud-init[1465]: 2016-09-08 17:14:56,954 - util.py[WARNING]: Running module locale () failed Sep 08 17:14:56 testing03.novalocal cloud-init[1465]: [CLOUDINIT] util.py[DEBUG]: Running module locale () failed Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/cloud_init-0.7.7-py2.7.egg/cloudinit/stages.py", line 785, in _run_modules freq=freq) File "/usr/lib/python2.7/site-packages/cloud_init-0.7.7-py2.7.egg/cloudinit/cloud.py", line 70, in run return self._runners.run(name, functor, args, freq, clear_on_fail) File "/usr/lib/python2.7/site-packages/cloud_init-0.7.7-py2.7.egg/cloudinit/helpers.py", line 199, in run results = functor(*args) File "/usr/lib/python2.7/site-packages/cloud_init-0.7.7-py2.7.egg/cloudinit/config/cc_locale.py", line 37, in handle cloud.distro.apply_locale(locale, locale_cfgfile) File "/usr/lib/python2.7/site-packages/cloud_init-0.7.7-py2.7.egg/cloudinit/distros/rhel.py", line 133, in apply_locale rhel_util.update_sysconfig_file(out_fn, locale_cfg) File "/usr/lib/python2.7/site-packages/cloud_init-0.7.7-py2.7.egg/cloudinit/distros/rhel_util.py", line 37, in update_sysconfig_file (exists, contents) = read_sysconfig_file(fn) File "/usr/lib/python2.7/site-packages/cloud_init-0.7.7-py2.7.egg/cloudinit/distros/rhel_util.py", line 64, in read_sysconfig_file return (exists, SysConf(contents)) File "/usr/lib/python2.7/site-packages/cloud_init-0.7.7-py2.7.egg/cloudinit/distros/parsers/sys_conf.py", line 61, in __init__ write_empty_values=True) File "/usr/lib/python2.7/site-packages/configobj.py", line 1242, in __init__ self._load(infile, configspec) File "/usr/lib/python2.7/site-packages/configobj.py", line 1302, in _load infile = self._handle_bom(infile) File "/usr/lib/python2.7/site-packages/configobj.py", line 1457, in _handle_bom if not line.startswith(BOM): UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 0: ordinal not in range(128) ** 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/1621667 Title: cc_locale fails on CentOS 7 Status in cloud-init: New Bug description: Sep 08 17:14:56 testing03.novalocal cloud-init[1465]: [CLOUDINIT] handlers.py[DEBUG]: finish: modules-config/config-locale: FAIL: running config-locale with frequency once-per-instance Sep 08 17:14:56 testing03.novalocal cloud-init[1465]: [CLOUDINIT] util.py[WARNING]: Running module locale () failed Sep 08 17:14:56 testing03.novalocal cloud-init[1465]: 2016-09-08 17:14:56,954 - util.py[WARNING]: Running module locale () failed Sep 08 17:14:56 testing03.novalocal cloud-init[1465]: [CLOUDINIT] util.py[DEBUG]: Running module locale () failed Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/cloud_init-0.7.7-py2.7.egg/cloudinit/stages.py", line 785, in _run_modules freq=freq) File "/usr/lib/python2.7/site-
[Yahoo-eng-team] [Bug 1621671] [NEW] cloud-init.service should Require/After network.service not networking.service (CentOS 7/RHEL 7)
Public bug reported: cloud-init.service currently depends on networking.service, and wants to be launched after that. On CentOS/RHEL 7 this should be network.service. Without this you will get errors related to netstat -rn not working correctly due to being started before networking is fully up. ** 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/1621671 Title: cloud-init.service should Require/After network.service not networking.service (CentOS 7/RHEL 7) Status in cloud-init: New Bug description: cloud-init.service currently depends on networking.service, and wants to be launched after that. On CentOS/RHEL 7 this should be network.service. Without this you will get errors related to netstat -rn not working correctly due to being started before networking is fully up. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1621671/+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 1510979] Re: Instance reschedule failure leaves orphaned neutron ports
** Also affects: nova/liberty Importance: Undecided Status: New ** Changed in: nova/liberty Status: New => In Progress ** Changed in: nova/liberty Assignee: (unassigned) => jichenjc (jichenjc) -- 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/1510979 Title: Instance reschedule failure leaves orphaned neutron ports Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) liberty series: In Progress Bug description: During the instance boot (spawn/run) process, neutron ports are allocated for the instance if necessary. If the instance fails to spawn (say as a result of a compute host failure), the default behavior is to reschedule the instance and leave it's networking resources in-tact for potential reuse on the rescheduled host (as per deallocate_networks_on_reschedule() [1] which returns False for most compute drivers). All is good if the instance is successfully rescheduled, but if the reschedule fails (say no more applicable hosts) the allocated ports are left as-is and effectively orphaned. There are some related defects ([2] and [3]), but they don't quite touch on the particular behavior described herein. Obviously there are a number of ways to address this issue, but the most obvious is perhaps nova should be aware of the reschedule failure and deallocate any resources which may have been left in-tact for the reschedule. I'm running devstack all-in-one setup from openstack master branches. nova --version 2.32.0 neutron --version 3.1.0 The easiest way to repo is to use an all-in-one devstack (only 1 compute host) simulate a host spawn failure by editing the spwan() method of your compute driver to raise an exception at the end of the method and simply try to boot a server. In this setup there's only 1 host so the reschedule will fail and you can verify the port allocated for the instance still exists after trying to boot the instance. [1] https://github.com/openstack/nova/blob/master/nova/virt/driver.py#L1273 [2] https://bugs.launchpad.net/nova/+bug/1410739 [3] https://bugs.launchpad.net/nova/+bug/1327124 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1510979/+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 1621698] [NEW] AFTER_DELETE event for SECURITY_GROUP_RULE should contain sg_id
Public bug reported: In the notification of AFTER_DELETE event for SECURITY_GROUP_RULE, the security group rule is actually deleted from DB. There is no way for subscriber to know the latest information of related security group. To be specific, dragonflow will maintain the security group version, and we are using revision_number in dragonflow now. The sg_rule_delete will bump the sg revision, which will only happen after the db transaction. dragonflow stores security group rule as part of security group. So, in the AFTER_DELETE event of SECURITY_GROUP_RULE, we don't know which security group is updated, if neutron don't pass the security group id. We can query all security group and iterate their security group rules. But that is inefficient and it will be nice if neutron just pass the related security group id. ** Affects: neutron Importance: Undecided Assignee: Hong Hui Xiao (xiaohhui) Status: New ** Changed in: neutron Assignee: (unassigned) => Hong Hui Xiao (xiaohhui) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1621698 Title: AFTER_DELETE event for SECURITY_GROUP_RULE should contain sg_id Status in neutron: New Bug description: In the notification of AFTER_DELETE event for SECURITY_GROUP_RULE, the security group rule is actually deleted from DB. There is no way for subscriber to know the latest information of related security group. To be specific, dragonflow will maintain the security group version, and we are using revision_number in dragonflow now. The sg_rule_delete will bump the sg revision, which will only happen after the db transaction. dragonflow stores security group rule as part of security group. So, in the AFTER_DELETE event of SECURITY_GROUP_RULE, we don't know which security group is updated, if neutron don't pass the security group id. We can query all security group and iterate their security group rules. But that is inefficient and it will be nice if neutron just pass the related security group id. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1621698/+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 1580239] Re: [RFE] Add agent extension framework for L3 agent
** 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/1580239 Title: [RFE] Add agent extension framework for L3 agent Status in neutron: Fix Released Bug description: Neutron advanced services (*aaS) projects need a standardized method to gain access to resources internal to the L3 agent. Previously, the proper methodology was using inheritance from L3NATAgent and it's subclasses. But now it is necessary to decouple these things, so that each *aaS can be a separate extension that registers with the L3 agent, can interrogate the L3 agent for necessary information, and receives notifications of events through callbacks. Some examples of what this would enable FWaaS and other advanced services to do are: - The ability to map router_id to router info so we can program iptables to the correct namespace. - The ability to load the Service Agent - so we have an RPC endpoint in the context of L3Agent. FWaaS can then use the existing observer hierarchy pattern to listen for notifications. This would prevent the need to patch the agent code for advanced services to function. Note: This must be executed in such a way that multiple *aaS services can plug in simultaneously without interfering with each other. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1580239/+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 1560003] Re: [RFE] Creating a new stadium project for BGP Dynamic Routing effort
** 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/1560003 Title: [RFE] Creating a new stadium project for BGP Dynamic Routing effort Status in neutron: Fix Released Bug description: This bug is logged for getting driver's team opinion on creating a new stadium project for BGP dynamic routing project. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1560003/+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 1621709] [NEW] There is no allocation record for migration action
Public bug reported: In the current RT, the migration case was consider as resource consuming. But we didn't update any allocation record to Placement API. ** Affects: nova Importance: Undecided Assignee: Alex Xu (xuhj) Status: New ** Tags: placement ** Changed in: nova Assignee: (unassigned) => Alex Xu (xuhj) ** Tags added: placement -- 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/1621709 Title: There is no allocation record for migration action Status in OpenStack Compute (nova): New Bug description: In the current RT, the migration case was consider as resource consuming. But we didn't update any allocation record to Placement API. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1621709/+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 1578500] Re: Nova 'ComputeManager._build_and_run_instance' method sends inappropriate notification ('create.end')
Reviewed: https://review.openstack.org/312887 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=19cc6e2ca897e65a630dfb3905ca62e8101d5b2e Submitter: Jenkins Branch:master commit 19cc6e2ca897e65a630dfb3905ca62e8101d5b2e Author: Rajesh Tailor Date: Thu May 5 06:11:25 2016 -0400 Fix inappropriate notification send The method '_build_and_run_instance' sends inappropriate notification 'create.end' when an exception is raised, instead it should be sending 'create.error' notification. Replaced 'create.end' notification with 'create.error' when exception is raised. Change-Id: I2661cc47b6ebb674cce2f2b43851aa9eca12b5f8 Closes-Bug:1578500 ** 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/1578500 Title: Nova 'ComputeManager._build_and_run_instance' method sends inappropriate notification ('create.end') Status in OpenStack Compute (nova): Fix Released Bug description: In Nova 'ComputeManager._build_and_run_instance' method, if InstanceNotFound or UnexpectedDeletingTaskStateError raises, 'compute.instance.create.end' notification will be sent[1]. It would be more reasonable if we send 'compute.instance.create.error' notification instead. [1]https://github.com/openstack/nova/blob/13.0.0.0rc3/nova/compute/manager.py#L2072 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1578500/+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 1621716] [NEW] [server-group] server-group feature can not support multi-node pattern
Public bug reported: Description === server-group can force instances to place on same host or different host. but it can not force servers to place on same node or different node. Node concept represent true hypervisor. if we can not force instances to hypervisor, server-group is less meaningful. After all, nova-compute can map to multi-node. Steps to reproduce == after creating server-group, we boot two instances nova boot diffCVKVnf1 --flavor 2b32765a-93ef-4bdd-95cc-3203477dedb7 --image cb0d7033-7818-481d-9cfe-700769eac740 --availability-zone "nova:CentOS7Kilo:CVM192.168.12.52(cvk1252)" --nic net- id=4fe8add8-82a5-4c0b-b104-cbee13f72a77 --hint group=21bf6740-71d7-4fdb- ae96-d3fa254e2daa nova boot diffCVKVnf2 --flavor 2b32765a-93ef-4bdd-95cc-3203477dedb7 --image cb0d7033-7818-481d-9cfe-700769eac740 --availability-zone "nova:CentOS7Kilo:CVM192.168.12.52(cvk1253)" --nic net-id=4fe8add8-82a5-4c0b-b104-cbee13f72a77 --hint group=21bf6740-71d7-4fdb-ae96-d3fa254e2daa Expected result === creations are successful Actual result = the second creation failed Build of instance 1a94a6dc-ba3d-4190-8417-973ffe6609a6 was re-scheduled: Build of instance 1a94a6dc-ba3d-4190-8417-973ffe6609a6 was re-scheduled: Anti-affinity instance group policy was violated. Environment === openstack version: Mitaka CentOS7Kilo host have two nodes: CVM192.168.12.52(cvk1253), CVM192.168.12.52(cvk1252) Code Analysis == affinity_filter is supporting server-group to node level. so filter is all alright but when nova-compute validate server-group, it use instances of host to validate. related function: nova/compute/manager.py:_do_validation nova/objects/instance_group.py: get_hosts ** Affects: nova Importance: Undecided Assignee: xhzhf (guoyongxhzhf) Status: New ** Changed in: nova Assignee: (unassigned) => xhzhf (guoyongxhzhf) -- 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/1621716 Title: [server-group] server-group feature can not support multi-node pattern Status in OpenStack Compute (nova): New Bug description: Description === server-group can force instances to place on same host or different host. but it can not force servers to place on same node or different node. Node concept represent true hypervisor. if we can not force instances to hypervisor, server-group is less meaningful. After all, nova-compute can map to multi-node. Steps to reproduce == after creating server-group, we boot two instances nova boot diffCVKVnf1 --flavor 2b32765a-93ef-4bdd-95cc-3203477dedb7 --image cb0d7033-7818-481d-9cfe-700769eac740 --availability-zone "nova:CentOS7Kilo:CVM192.168.12.52(cvk1252)" --nic net- id=4fe8add8-82a5-4c0b-b104-cbee13f72a77 --hint group=21bf6740-71d7 -4fdb-ae96-d3fa254e2daa nova boot diffCVKVnf2 --flavor 2b32765a-93ef-4bdd-95cc-3203477dedb7 --image cb0d7033-7818-481d-9cfe-700769eac740 --availability-zone "nova:CentOS7Kilo:CVM192.168.12.52(cvk1253)" --nic net-id=4fe8add8-82a5-4c0b-b104-cbee13f72a77 --hint group=21bf6740-71d7-4fdb-ae96-d3fa254e2daa Expected result === creations are successful Actual result = the second creation failed Build of instance 1a94a6dc-ba3d-4190-8417-973ffe6609a6 was re-scheduled: Build of instance 1a94a6dc-ba3d-4190-8417-973ffe6609a6 was re-scheduled: Anti-affinity instance group policy was violated. Environment === openstack version: Mitaka CentOS7Kilo host have two nodes: CVM192.168.12.52(cvk1253), CVM192.168.12.52(cvk1252) Code Analysis == affinity_filter is supporting server-group to node level. so filter is all alright but when nova-compute validate server-group, it use instances of host to validate. related function: nova/compute/manager.py:_do_validation nova/objects/instance_group.py: get_hosts To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1621716/+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 1621717] [NEW] Delete agent will not delete related SegmentHostMapping
Public bug reported: SegmentHostMapping will record the relationship between segments and hosts. If admin delete an agent, related SegmentHostMapping should be cleared too. Or else, other logic which leverage SegmentHostMapping will still think the host is available. This will cause error is admin just want to remove a node from openstack topology. ** Affects: neutron Importance: Undecided Assignee: Hong Hui Xiao (xiaohhui) Status: New ** Tags: routed-network ** Changed in: neutron Assignee: (unassigned) => Hong Hui Xiao (xiaohhui) ** Tags added: routed-network -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1621717 Title: Delete agent will not delete related SegmentHostMapping Status in neutron: New Bug description: SegmentHostMapping will record the relationship between segments and hosts. If admin delete an agent, related SegmentHostMapping should be cleared too. Or else, other logic which leverage SegmentHostMapping will still think the host is available. This will cause error is admin just want to remove a node from openstack topology. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1621717/+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 1602320] Re: ha + distributed router: keepalived process kill vrrp child process
Reviewed: https://review.openstack.org/366493 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=2b148c3f9299642e0bb068983de68ec6441a23be Submitter: Jenkins Branch:master commit 2b148c3f9299642e0bb068983de68ec6441a23be Author: He Qing Date: Wed Sep 7 05:07:25 2016 + Fix wrong HA router state When we add/remove router interface from HA router, l3 agent will send SIGHUP signal to keepalived for reloading configuraion. But for DVR+HA router, l3 agent will send SIGHUP signal TWICE which will cause VRRP sub-process terminated and vip addresses and routes left over. Keepalived then restart VRRP process and there will be a re-election between VRRP peers. After the election, if the former is still master, the state showed from Neutron will be correct. But if the former master transitioned to backup, the new VRRP process will NOT delete vips and routes because it is not the one who configured them. There will be two active agent showed from Neutron. HaRouter.enable_keepalived() will send SIGHUP signal to keepalived. DvrEdgeHaRouter.process() should not call enable_keepalived() by itself because it has inherited from class HaRouter. Closes-Bug: 1602320 Change-Id: I647269665a22b4becb3e326e1f4b03ddd961d6b1 ** 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/1602320 Title: ha + distributed router: keepalived process kill vrrp child process Status in neutron: Fix Released Bug description: Code Repo: mitaka keepalived version: 1.2.13 node mode: 4 nodes(containers), dvr_snat(l3 agent_mode) OS: Centos 7 I both configure router_distributed and l3_ha True. Then I create a router, using neutron l3-agent-list-hosting-router command, the result show 1 active, 3 standby. Then I add a router interface, there are more than 1 active. I trace the /var/log/messages, in the original active l3 agent node: 2016-07-12T16:33:32.083140+08:00 localhost Keepalived[1320437]: VRRP child process(1320438) died: Respawning 2016-07-12T16:33:32.083613+08:00 localhost Keepalived[1320437]: Starting VRRP child process, pid=1340135 Strace info: http://paste.openstack.org/show/530791/ This is not always failed, sometimes there was only 1 active. Maybe this is related to the environment, because I can't reproduce in VMs. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1602320/+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 1621720] [NEW] Unify the code path of creating segment
Public bug reported: Before routed network, functions in [1] are used to manage network segment. Routed network introduces a plugin [2] to manage network segment. So, now there are 2 code paths to do the same job. This cause issue when create network in ml2. When the network is created, related segmentation_id will be reserved in ml2 and related segments will be created by using [1]. In [1], PRECOMMIT_CREATE event for SEGMENT will be sent out. In patch [3], a subscriber was added in ml2 to subscribe the PRECOMMIT_CREATE event of SEGMENT. The subscriber will reserve the segmentation_id. But the segmentation_id has already been reserved. A workaround was added at [4] to avoid issue. Ideally, ml2 should use [2] to create segment and let [2] to do other things(like reserve segmentation_id). This can eliminate the workaround. [1] neutron.db.segments_db [2] neutron.services.segments.plugin [3] f564dcad4d8c072767ae235353a982653b156c76 [4] https://github.com/openstack/neutron/blob/8dffc238759cf543681443a2a4540dd0d569da6a/neutron/plugins/ml2/plugin.py#L1814-L1821 ** Affects: neutron Importance: Undecided Assignee: Hong Hui Xiao (xiaohhui) Status: New ** Changed in: neutron Assignee: (unassigned) => Hong Hui Xiao (xiaohhui) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1621720 Title: Unify the code path of creating segment Status in neutron: New Bug description: Before routed network, functions in [1] are used to manage network segment. Routed network introduces a plugin [2] to manage network segment. So, now there are 2 code paths to do the same job. This cause issue when create network in ml2. When the network is created, related segmentation_id will be reserved in ml2 and related segments will be created by using [1]. In [1], PRECOMMIT_CREATE event for SEGMENT will be sent out. In patch [3], a subscriber was added in ml2 to subscribe the PRECOMMIT_CREATE event of SEGMENT. The subscriber will reserve the segmentation_id. But the segmentation_id has already been reserved. A workaround was added at [4] to avoid issue. Ideally, ml2 should use [2] to create segment and let [2] to do other things(like reserve segmentation_id). This can eliminate the workaround. [1] neutron.db.segments_db [2] neutron.services.segments.plugin [3] f564dcad4d8c072767ae235353a982653b156c76 [4] https://github.com/openstack/neutron/blob/8dffc238759cf543681443a2a4540dd0d569da6a/neutron/plugins/ml2/plugin.py#L1814-L1821 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1621720/+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 1621750] [NEW] Port does not revert device_owner to previous value in concurrent requests case
Public bug reported: >From this patch: https://review.openstack.org/#/c/341427/ Sometimes, port doesn't revert device_owner to previous value in concurrent requests case. $ neutron port-create --name port1 net1 | Overlapped CIDR $ neutron port-create --name port2 net2 | mysql> select name, device_id, device_owner from ports; +---+---+--+ | name--| device_id --- | device_owner --- | +---+---+--+ | port1 | - | | | port2 | - | | +---+---+--+ $ neutron router-interface-add router-test port=port1 & neutron router-interface-add router-test port=port2 Added interface 68c26144-4ae5-4316-a631-93d5e3a44fd8 to router router-test. Bad router request: Cidr 192.166.0.0/16 of subnet 87d56713-e6f0-47ee-918d-759cb69b372d overlaps with cidr 192.166.100.0/24 of subnet 94cdfe4c-0e8e-40af-93fe-e8dcc2cb7484. WE EXPECTED IN DATABASE: mysql> select name, device_id, device_owner from ports; +---+---+--+ | name--| device_id | device_owner --- | +---+---+--+ | port1 | f872184e-031e-43ae-9bc7-e1f05137e09e | network:router_interface | | port2 | - | | +---+---+--+ BUT, CURRENT RESULT HERE: mysql> select name, device_id, device_owner from ports; +---+---+--+ | name--| device_id --- | device_owner --- | +---+---+--+ | port1 | f872184e-031e-43ae-9bc7-e1f05137e09e | network:router_interface | | port2 | - | network:router_interface | +---+---+--+ ** Affects: neutron Importance: Undecided Assignee: Anh Tran (trananhkma) Status: 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/1621750 Title: Port does not revert device_owner to previous value in concurrent requests case Status in neutron: In Progress Bug description: From this patch: https://review.openstack.org/#/c/341427/ Sometimes, port doesn't revert device_owner to previous value in concurrent requests case. $ neutron port-create --name port1 net1 | Overlapped CIDR $ neutron port-create --name port2 net2 | mysql> select name, device_id, device_owner from ports; +---+---+--+ | name--| device_id --- | device_owner --- | +---+---+--+ | port1 | - | | | port2 | - | | +---+---+--+ $ neutron router-interface-add router-test port=port1 & neutron router-interface-add router-test port=port2 Added interface 68c26144-4ae5-4316-a631-93d5e3a44fd8 to router router-test. Bad router request: Cidr 192.166.0.0/16 of subnet 87d56713-e6f0-47ee-918d-759cb69b372d overlaps with cidr 192.166.100.0/24 of subnet 94cdfe4c-0e8e-40af-93fe-e8dcc2cb7484. WE EXPECTED IN DATABASE: mysql> select name, device_id, device_owner from ports; +---+-