[Yahoo-eng-team] [Bug 1555356] Re: Neutron too coupled with Tempest
[Expired for neutron because there has been no activity for 60 days.] ** Changed in: neutron Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1555356 Title: Neutron too coupled with Tempest Status in neutron: Expired Bug description: I recently dropped Tempest 'plumbing' code from Neutron and imported it instead from Tempest: https://review.openstack.org/#/c/269771/ Since then, we've had two instances of changes to Tempest breaking the Neutron API tests: https://bugs.launchpad.net/neutron/+bug/1554362, and: https://review.openstack.org/#/c/284911/ Neutron imports the following files from Tempest (That aren't a stable interface e.g. in tempest.lib) that Manila and Ironic (As examples of projects that have Tempest plugins) do not: from tempest.services.identity.v2.json.tenants_client import TenantsClient Instead of waiting for the next breakage, we should go through each such import and figure out a strategy to stop using it: 1) Perhaps there is already equivalent code in tempest.lib? 2) If not, can we help move it to tempest.lib? 3) Failing that, we can always copy the needed functionality in to Neutron To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1555356/+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 1677097] [NEW] AvailabilityZoneFilter returns a wrong result because of the availablity_zone in the instances table has not be updated
Public bug reported: When you do a live-migration for an instance from one zone to another successfully or you change the zone of the compute node which the instance launched on, but the availablity_zone of this instance in the instances table won't be updated. Then when you do a cold_migrate or resize the instance, the AvailabilityZoneFilter will get a wrong zone of the instance, and the filter result must be wrong, and maybe you won't get the result you want for the cold_migrate or resize. ** 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/1677097 Title: AvailabilityZoneFilter returns a wrong result because of the availablity_zone in the instances table has not be updated Status in OpenStack Compute (nova): New Bug description: When you do a live-migration for an instance from one zone to another successfully or you change the zone of the compute node which the instance launched on, but the availablity_zone of this instance in the instances table won't be updated. Then when you do a cold_migrate or resize the instance, the AvailabilityZoneFilter will get a wrong zone of the instance, and the filter result must be wrong, and maybe you won't get the result you want for the cold_migrate or resize. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1677097/+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 1596829] Re: String interpolation should be delayed at logging calls
** Also affects: sahara
Importance: Undecided
Status: New
** Changed in: sahara
Assignee: (unassigned) => pawnesh kumar (pawnesh.kumar)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1596829
Title:
String interpolation should be delayed at logging calls
Status in congress:
Fix Released
Status in Glance:
In Progress
Status in glance_store:
In Progress
Status in OpenStack Dashboard (Horizon):
In Progress
Status in Ironic:
Fix Released
Status in masakari:
Fix Released
Status in networking-vsphere:
Fix Released
Status in neutron:
Fix Released
Status in OpenStack Compute (nova):
Fix Released
Status in os-brick:
Fix Released
Status in os-vif:
Fix Released
Status in python-cinderclient:
Fix Released
Status in Glance Client:
Fix Released
Status in python-manilaclient:
Fix Released
Status in python-neutronclient:
Fix Released
Status in python-openstackclient:
Fix Released
Status in python-troveclient:
In Progress
Status in Sahara:
New
Status in senlin:
Invalid
Bug description:
String interpolation should be delayed to be handled by the logging
code, rather than being done at the point of the logging call.
Wrong: LOG.debug('Example: %s' % 'bad')
Right: LOG.debug('Example: %s', 'good')
See the following guideline.
* http://docs.openstack.org/developer/oslo.i18n/guidelines.html
#adding-variables-to-log-messages
The rule for it should be added to hacking checks.
To manage notifications about this bug go to:
https://bugs.launchpad.net/congress/+bug/1596829/+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 1669450] Re: Python modals are not animated like angular modals
Resetting the status to New due to the revert. ** Changed in: horizon Status: Fix Released => New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1669450 Title: Python modals are not animated like angular modals Status in OpenStack Dashboard (Horizon): New Bug description: The Python modals aren't animated like the Angular modals; this is just due to a missing 'fade' class, and is a minor fix. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1669450/+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 1677064] Re: Security Group Add Rule form is not setup properly
Reviewed: https://review.openstack.org/451117 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=343cbd19b5e4c17c4c4e86fb6ae86cfde95cb84b Submitter: Jenkins Branch:master commit 343cbd19b5e4c17c4c4e86fb6ae86cfde95cb84b Author: Akihiro Motoki Date: Tue Mar 28 23:36:33 2017 + Revert "Add the 'fade' class to Python modals, for animation" After this commit, "Add Rule" in security group panel is not setup properly and only a few fields are displayed. I haven't identified the root cause but it looks better to revert this commit and tackle the original problem again. This reverts commit 8be1ec5e706b07b47f13b8c97c70327b25b09552. Change-Id: I266484da68dd355082144889699dda299ab9f997 Closes-Bug: #1677064 Related-Bug: #1669450 ** 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/1677064 Title: Security Group Add Rule form is not setup properly Status in OpenStack Dashboard (Horizon): Fix Released Bug description: Security Group Add Rule form is not setup properly. We can see only "Rule" and "Remote" fields. When I change a selected item in "Rule" to others, all expected fields were displayed. After that when I selected "Custom TCP Rule" again, all expected fields were displayed. From this, it seems all fields are prepared expectedly but the initial setup is not done properly. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1677064/+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 1677064] [NEW] Security Group Add Rule form is not setup properly
Public bug reported: Security Group Add Rule form is not setup properly. We can see only "Rule" and "Remote" fields. When I change a selected item in "Rule" to others, all expected fields were displayed. After that when I selected "Custom TCP Rule" again, all expected fields were displayed. >From this, it seems all fields are prepared expectedly but the initial setup >is not done properly. ** Affects: horizon Importance: High Assignee: Akihiro Motoki (amotoki) Status: In Progress -- 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/1677064 Title: Security Group Add Rule form is not setup properly Status in OpenStack Dashboard (Horizon): In Progress Bug description: Security Group Add Rule form is not setup properly. We can see only "Rule" and "Remote" fields. When I change a selected item in "Rule" to others, all expected fields were displayed. After that when I selected "Custom TCP Rule" again, all expected fields were displayed. From this, it seems all fields are prepared expectedly but the initial setup is not done properly. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1677064/+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 1647432] Re: Multiple SIGHUPs to keepalived might trigger re-election
Reviewed: https://review.openstack.org/407099 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=977d254cc69915819cf4226dc8cfc8c36969735b Submitter: Jenkins Branch:master commit 977d254cc69915819cf4226dc8cfc8c36969735b Author: John Schwarz Date: Mon Dec 5 14:15:17 2016 +0200 Throttle SIGHUPs to keepalived Multiple SIGHUPs in quick succession might cause the master keepalived to forfeit its mastership (which will cause keepalived to remove IPs of its external devices, severing connectivity). This can happen when, for example, associating or disassociating multiple floatingips. The patch makes the agent throttle SIGHUP sent to keepalived: the very first SIGHUP is always sent; as for subsequent signals, they are delayed till agent threshold is reached. (It's 3 seconds by default.) As an example, when three consequent router updates trigger keepalived respawn then: * the very first signal is sent as usual; * the second signal is deferred and sent in up to 3 seconds since the first signal; * the third signal is ignored, though the change that triggered it will be correctly applied by the second signal handler when it is triggered after threshold delay. If the last time a spawn request occurred is older than current-time minus threshold then there is no delay. Co-Authored-By: Jakub Libosvar Co-Authored-By: Cedric Brandily Co-Authored-By: Ihar Hrachyshka Closes-Bug: 1647432 Change-Id: I2955e0de835458a2eea4dd088addf33b656f8670 ** 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/1647432 Title: Multiple SIGHUPs to keepalived might trigger re-election Status in neutron: Fix Released Bug description: As the title says, multiple SIGHUPs that are sent to the keepalived process might cause it to forfeit mastership and re-negotiate a new master (which might be the original master). This means that when, for example, associating/disassociating 2 floatingips in quick succession (each triggers a SIGHUP), the master node will forfeit re-election (causing it to switch to BACKUP, thus removing all the remaining FIP's IPs and severing connectivity. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1647432/+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 1676787] Re: Release note shows non-existent feature
Reviewed: https://review.openstack.org/450652 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=2f8b4e06feb4a03f77490c7758c5979005e0ea68 Submitter: Jenkins Branch:master commit 2f8b4e06feb4a03f77490c7758c5979005e0ea68 Author: Hirofumi Ichihara Date: Tue Mar 28 17:48:07 2017 +0900 Remove a release note for reverted patch The release note was missed remove in revert patch[1]. Now it shows non-existent feature in the release note[2]. This patch removes it. [1]: https://review.openstack.org/#/c/431506/ [2]: https://docs.openstack.org/releasenotes/neutron/ocata.html#new-features Closes-Bug: #1676787 Change-Id: I377de0c8491424f3ae9d56ed8ba2526e6137fc2e ** 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/1676787 Title: Release note shows non-existent feature Status in neutron: Fix Released Bug description: Ocata release note shows linux bridge supports QoS egress minimum bandwidth but it's reverted in Ocata[2]. [1]: https://docs.openstack.org/releasenotes/neutron/ocata.html#new-features [2]: https://review.openstack.org/#/c/431506/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1676787/+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 1677047] [NEW] glance download fsync raises EINVAL for FIFOs
Public bug reported: Description === The nova.image.glance.GlanceImageServiceV2.download method recently added fsync [1][2] before closing the download file. Some hypervisors don't use regular files for download. For example, PowerVM uses a FIFO pipe, the other end of which is read by a service that offloads the image data to a remote node. fsync on a pipe, FIFO, or socket errors with EINVAL [3]. [1] https://review.openstack.org/#/c/441246/ [2] https://review.openstack.org/#/c/443583/ [3] http://man7.org/linux/man-pages/man2/fsync.2.html#ERRORS Steps to reproduce == Invoke nova.image.glance.GlanceImageServiceV2.download with data=None, dst_path=path where path represents a FIFO or socket. Expected result === Successful transfer of data through the FIFO/socket. Actual result = An exception similar to the following: File "/usr/local/lib/python2.7/dist-packages/pypowervm/internal_utils/thread_utils.py", line 34, in future_func return func(*args, **kwargs) File "/opt/stack/nova/nova/virt/powervm/disk/ssp.py", line 161, in upload IMAGE_API.download(context, image_meta.id, dest_path=path) File "/opt/stack/nova/nova/image/api.py", line 184, in download dst_path=dest_path) File "/opt/stack/nova/nova/image/glance.py", line 387, in download os.fsync(data.fileno()) OSError: [Errno 22] Invalid argument Immutable reference to the offending fsync call: https://github.com/openstack/nova/blob/640b152004fe3d9c43c26538809c3ac796f20eba/nova/image/glance.py#L375 Environment === devstack, pike, with the nova tree at this in-flight patch set: https://review.openstack.org/#/c/443189/15 Ubuntu 16.04.1 LTS running on PowerVM NovaLink, using Shared Storage Pools through a single VIOS. No networking. Logs & Configs == Available on request if needed. This is a snap to reproduce. ** 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/1677047 Title: glance download fsync raises EINVAL for FIFOs Status in OpenStack Compute (nova): New Bug description: Description === The nova.image.glance.GlanceImageServiceV2.download method recently added fsync [1][2] before closing the download file. Some hypervisors don't use regular files for download. For example, PowerVM uses a FIFO pipe, the other end of which is read by a service that offloads the image data to a remote node. fsync on a pipe, FIFO, or socket errors with EINVAL [3]. [1] https://review.openstack.org/#/c/441246/ [2] https://review.openstack.org/#/c/443583/ [3] http://man7.org/linux/man-pages/man2/fsync.2.html#ERRORS Steps to reproduce == Invoke nova.image.glance.GlanceImageServiceV2.download with data=None, dst_path=path where path represents a FIFO or socket. Expected result === Successful transfer of data through the FIFO/socket. Actual result = An exception similar to the following: File "/usr/local/lib/python2.7/dist-packages/pypowervm/internal_utils/thread_utils.py", line 34, in future_func return func(*args, **kwargs) File "/opt/stack/nova/nova/virt/powervm/disk/ssp.py", line 161, in upload IMAGE_API.download(context, image_meta.id, dest_path=path) File "/opt/stack/nova/nova/image/api.py", line 184, in download dst_path=dest_path) File "/opt/stack/nova/nova/image/glance.py", line 387, in download os.fsync(data.fileno()) OSError: [Errno 22] Invalid argument Immutable reference to the offending fsync call: https://github.com/openstack/nova/blob/640b152004fe3d9c43c26538809c3ac796f20eba/nova/image/glance.py#L375 Environment === devstack, pike, with the nova tree at this in-flight patch set: https://review.openstack.org/#/c/443189/15 Ubuntu 16.04.1 LTS running on PowerVM NovaLink, using Shared Storage Pools through a single VIOS. No networking. Logs & Configs == Available on request if needed. This is a snap to reproduce. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1677047/+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 1676607] Re: cloud-init is disabled when data source is set to just "None"
OK, I must have misread the source code; testing in lxd didn't occur to me! ** Changed in: cloud-init Status: Incomplete => Invalid ** Changed in: cloud-init (Ubuntu) Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1676607 Title: cloud-init is disabled when data source is set to just "None" Status in cloud-init: Invalid Status in cloud-init package in Ubuntu: Invalid Bug description: For some images we build as part of the CPC programme, the target cloud doesn't support any sort of metadata, so they are configured with datasource_list as ["None"]. However, we still want cloud-init to run because we lay down some configuration in /etc/cloud/cloud.cfg.d/* (to configure mirrors, for example). Currently, ds-identify will disable cloud-init entirely, which is less than ideal. We either need another data-source name which means "None but please still run", or an independent way of telling ds-identify that its normal data-source logic doesn't work in this case (or just a way of overriding it). To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1676607/+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 1677020] [NEW] test_filtering_shared_subnets failed in -api job with MismatchError comparing subnets
*** This bug is a duplicate of bug 1674517 ***
https://bugs.launchpad.net/bugs/1674517
Public bug reported:
http://logs.openstack.org/99/407099/48/check/gate-neutron-dsvm-api-
ubuntu-xenial/a1969ce/testr_results.html.gz
pythonlogging:'': {{{
2017-03-28 19:25:18,166 7692 INFO [tempest.lib.common.rest_client] Request
(SharedNetworksTest:test_filtering_shared_subnets): 201 POST
http://15.184.69.59:9696/v2.0/networks 0.879s
2017-03-28 19:25:18,167 7692 DEBUG[tempest.lib.common.rest_client] Request
- Headers: {'Content-Type': 'application/json', 'Accept': 'application/json',
'X-Auth-Token': ''}
Body: {"network": {"name": "tempest-test-network--1848706369"}}
Response - Headers: {u'connection': 'close', 'status': '201',
u'x-openstack-request-id': 'req-052b7e7e-7b14-4675-a354-c07f3a9f125c',
u'content-length': '587', u'content-type': 'application/json; charset=UTF-8',
'content-location': 'http://15.184.69.59:9696/v2.0/networks', u'date': 'Tue, 28
Mar 2017 19:25:18 GMT'}
Body:
{"network":{"ipv6_address_scope":null,"dns_domain":"","revision_number":3,"port_security_enabled":true,"id":"2a656de1-7782-4205-9561-d9bb8e50c8c0","router:external":false,"availability_zone_hints":[],"availability_zones":[],"ipv4_address_scope":null,"shared":false,"project_id":"1f33d41e817c42b38d1a920b6eb5842e","status":"ACTIVE","subnets":[],"description":"","tags":[],"updated_at":"2017-03-28T19:25:17Z","name":"tempest-test-network--1848706369","qos_policy_id":null,"admin_state_up":true,"tenant_id":"1f33d41e817c42b38d1a920b6eb5842e","created_at":"2017-03-28T19:25:17Z","mtu":1450}}
2017-03-28 19:25:19,087 7692 INFO [tempest.lib.common.rest_client] Request
(SharedNetworksTest:test_filtering_shared_subnets): 201 POST
http://15.184.69.59:9696/v2.0/subnets 0.919s
2017-03-28 19:25:19,088 7692 DEBUG[tempest.lib.common.rest_client] Request
- Headers: {'Content-Type': 'application/json', 'Accept': 'application/json',
'X-Auth-Token': ''}
Body: {"subnet": {"cidr": "10.1.0.0/28", "ip_version": 4, "gateway_ip":
"10.1.0.1", "network_id": "2a656de1-7782-4205-9561-d9bb8e50c8c0"}}
Response - Headers: {u'connection': 'close', 'status': '201',
u'x-openstack-request-id': 'req-e3c6dc37-7d8c-4f11-8c5a-1cabeae75931',
u'content-length': '594', u'content-type': 'application/json; charset=UTF-8',
'content-location': 'http://15.184.69.59:9696/v2.0/subnets', u'date': 'Tue, 28
Mar 2017 19:25:19 GMT'}
Body:
{"subnet":{"service_types":[],"description":"","enable_dhcp":true,"tags":[],"network_id":"2a656de1-7782-4205-9561-d9bb8e50c8c0","tenant_id":"1f33d41e817c42b38d1a920b6eb5842e","created_at":"2017-03-28T19:25:18Z","dns_nameservers":[],"updated_at":"2017-03-28T19:25:18Z","gateway_ip":"10.1.0.1","ipv6_ra_mode":null,"allocation_pools":[{"start":"10.1.0.2","end":"10.1.0.14"}],"host_routes":[],"revision_number":2,"ip_version":4,"ipv6_address_mode":null,"cidr":"10.1.0.0/28","project_id":"1f33d41e817c42b38d1a920b6eb5842e","id":"34750ed3-99c0-4de3-9971-076ac992ea1a","subnetpool_id":null,"name":""}}
2017-03-28 19:25:20,438 7692 INFO [tempest.lib.common.rest_client] Request
(SharedNetworksTest:test_filtering_shared_subnets): 201 POST
http://15.184.69.59:9696/v2.0/subnets 1.349s
2017-03-28 19:25:20,438 7692 DEBUG[tempest.lib.common.rest_client] Request
- Headers: {'Content-Type': 'application/json', 'Accept': 'application/json',
'X-Auth-Token': ''}
Body: {"subnet": {"cidr": "10.1.0.0/28", "ip_version": 4, "gateway_ip":
"10.1.0.1", "network_id": "30e2c6c3-0e6f-4c47-a516-6f0f6f3a2b1d"}}
Response - Headers: {u'connection': 'close', 'status': '201',
u'x-openstack-request-id': 'req-46a771ec-b3f9-4ed8-918d-edf3fdb4bac2',
u'content-length': '594', u'content-type': 'application/json; charset=UTF-8',
'content-location': 'http://15.184.69.59:9696/v2.0/subnets', u'date': 'Tue, 28
Mar 2017 19:25:20 GMT'}
Body:
{"subnet":{"service_types":[],"description":"","enable_dhcp":true,"tags":[],"network_id":"30e2c6c3-0e6f-4c47-a516-6f0f6f3a2b1d","tenant_id":"7671eeda385745399b668bf68c000c53","created_at":"2017-03-28T19:25:19Z","dns_nameservers":[],"updated_at":"2017-03-28T19:25:19Z","gateway_ip":"10.1.0.1","ipv6_ra_mode":null,"allocation_pools":[{"start":"10.1.0.2","end":"10.1.0.14"}],"host_routes":[],"revision_number":2,"ip_version":4,"ipv6_address_mode":null,"cidr":"10.1.0.0/28","project_id":"7671eeda385745399b668bf68c000c53","id":"9d97a397-c27d-4b35-9c20-151930e40362","subnetpool_id":null,"name":""}}
2017-03-28 19:25:20,796 7692 INFO [tempest.lib.common.rest_client] Request
(SharedNetworksTest:test_filtering_shared_subnets): 200 GET
http://15.184.69.59:9696/v2.0/subnets?shared=True 0.357s
2017-03-28 19:25:20,797 7692 DEBUG[tempest.lib.common.rest_client] Request
- Headers: {'Content-Type': 'application/json', 'Accept': 'application/json',
'X-Auth-Token': ''}
Body: None
Response - Headers: {u'connection': 'close', 'status': '200',
u'x-openstack-request-id': 're
[Yahoo-eng-team] [Bug 1596829] Re: String interpolation should be delayed at logging calls
** Also affects: horizon
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/1596829
Title:
String interpolation should be delayed at logging calls
Status in congress:
Fix Released
Status in Glance:
In Progress
Status in glance_store:
In Progress
Status in OpenStack Dashboard (Horizon):
In Progress
Status in Ironic:
Fix Released
Status in masakari:
Fix Released
Status in networking-vsphere:
Fix Released
Status in neutron:
Fix Released
Status in OpenStack Compute (nova):
Fix Released
Status in os-brick:
Fix Released
Status in os-vif:
Fix Released
Status in python-cinderclient:
Fix Released
Status in Glance Client:
Fix Released
Status in python-manilaclient:
Fix Released
Status in python-neutronclient:
Fix Released
Status in python-openstackclient:
Fix Released
Status in python-troveclient:
In Progress
Status in senlin:
Invalid
Bug description:
String interpolation should be delayed to be handled by the logging
code, rather than being done at the point of the logging call.
Wrong: LOG.debug('Example: %s' % 'bad')
Right: LOG.debug('Example: %s', 'good')
See the following guideline.
* http://docs.openstack.org/developer/oslo.i18n/guidelines.html
#adding-variables-to-log-messages
The rule for it should be added to hacking checks.
To manage notifications about this bug go to:
https://bugs.launchpad.net/congress/+bug/1596829/+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 1677008] Re: Stop using os-cloud-config
** Changed in: neutron Status: New => Confirmed ** Changed in: neutron Milestone: None => pike-1 ** Changed in: neutron Importance: Undecided => High ** Project changed: neutron => python-neutronclient ** Changed in: python-neutronclient Milestone: pike-1 => None ** Tags added: needs-attention -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1677008 Title: Stop using os-cloud-config Status in tripleo: Triaged Bug description: os-cloud-config is deprecated in Ocata and will be removed in the future. TripleO doesn't use it anymore. Only Neutron Client functional tests are using it. To manage notifications about this bug go to: https://bugs.launchpad.net/tripleo/+bug/1677008/+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 1677008] [NEW] Stop using os-cloud-config
Public bug reported: os-cloud-config is deprecated in Ocata and will be removed in the future. TripleO doesn't use it anymore. Only Neutron Client functional tests are using it. ** Affects: tripleo Importance: Medium Status: Triaged ** Tags: needs-attention ** Changed in: tripleo Status: New => Triaged ** Changed in: tripleo Importance: Undecided => Medium ** Changed in: tripleo Milestone: None => pike-3 ** Also affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1677008 Title: Stop using os-cloud-config Status in tripleo: Triaged Bug description: os-cloud-config is deprecated in Ocata and will be removed in the future. TripleO doesn't use it anymore. Only Neutron Client functional tests are using it. To manage notifications about this bug go to: https://bugs.launchpad.net/tripleo/+bug/1677008/+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 1675571] Re: Cloud-init update renders secondary addresses to be incompatible with standard tools
** Also affects: curtin
Importance: Undecided
Status: New
** Changed in: curtin
Status: New => Confirmed
** Changed in: curtin
Importance: Undecided => Medium
** Changed in: cloud-init
Importance: Undecided => Medium
--
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/1675571
Title:
Cloud-init update renders secondary addresses to be incompatible with
standard tools
Status in cloud-init:
Confirmed
Status in curtin:
Confirmed
Status in cloud-init package in Ubuntu:
Confirmed
Status in resolvconf package in Ubuntu:
New
Bug description:
The change of how cloud-init renders
/etc/network/interface.d/50-cloud-init.cfg, standard tools no longer work as
expected:
* resolvconf will nullify nameservers
* if* commands ignore secondary addresses
[ORIGINAL REPORT]
Regresion from Bug #1657940.
When provisioning with multiple eth0 addresses, /etc/resolv.conf is
empty:
Consider:
root@tester:~# cat /etc/network/interfaces.d/50-cloud-init.cfg
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 138.197.98.102
dns-nameservers 8.8.8.8 8.8.4.4
gateway 138.197.96.1
netmask 255.255.240.0
# control-alias eth0
iface eth0 inet static
address 10.17.0.11
netmask 255.255.0.0
Which then yields an empty /etc/resolv.conf:
root@tester:/run/resolvconf# cat interface/eth0.inet
root@tester:/run/resolvconf# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
The problem is that resolvconfg does pattern matching for eth*.inet.
The second definition of eth0 has no nameserver and therefore
overrides the definition.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1675571/+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 1513771] Re: functional tests random failure on TestProcessMonitor.test_respawn_handler trying to kill a process
Reviewed: https://review.openstack.org/446991 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=9049c32c7c7314e05250551807b4164082da4695 Submitter: Jenkins Branch:master commit 9049c32c7c7314e05250551807b4164082da4695 Author: Attila Czira Date: Fri Mar 17 11:43:11 2017 +0100 Stabilizing process monitor function test case The problem seems to be that the TC is starting new processes parallelly but it does not wait for them to start properly instead it tries to kill one of them immediately but in some cases if the startup phase is delayed the process that is about to be killed is not started yet. The fix is to introduce a waiting phase until all the child processes are up and running right after the initial spawning phase. As the problem is not functional the fix is difficult to test. I executed this TC in a loop with this fix for a 5000 times and the problem has not appeared. Without the fix I had 3.8% failure rate. Change-Id: I19a8a4c35efc35a002478204fd24910d73c9c8c2 closes-bug: #1513771 ** 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/1513771 Title: functional tests random failure on TestProcessMonitor.test_respawn_handler trying to kill a process Status in neutron: Fix Released Bug description: 2015-11-06 08:16:42.407 | 2015-11-06 08:16:42.364 | == 2015-11-06 08:16:42.408 | 2015-11-06 08:16:42.366 | Failed 1 tests - output below: 2015-11-06 08:16:42.408 | 2015-11-06 08:16:42.367 | == 2015-11-06 08:16:42.408 | 2015-11-06 08:16:42.369 | 2015-11-06 08:16:42.408 | 2015-11-06 08:16:42.370 | neutron.tests.functional.agent.linux.test_process_monitor.TestProcessMonitor.test_respawn_handler 2015-11-06 08:16:42.408 | 2015-11-06 08:16:42.372 | - 2015-11-06 08:16:42.409 | 2015-11-06 08:16:42.373 | 2015-11-06 08:16:42.409 | 2015-11-06 08:16:42.374 | Captured traceback: 2015-11-06 08:16:42.409 | 2015-11-06 08:16:42.376 | ~~~ 2015-11-06 08:16:42.409 | 2015-11-06 08:16:42.377 | Traceback (most recent call last): 2015-11-06 08:16:42.409 | 2015-11-06 08:16:42.378 | File "neutron/tests/functional/agent/linux/test_process_monitor.py", line 108, in test_respawn_handler 2015-11-06 08:16:42.409 | 2015-11-06 08:16:42.380 | self._kill_last_child() 2015-11-06 08:16:42.410 | 2015-11-06 08:16:42.381 | File "neutron/tests/functional/agent/linux/test_process_monitor.py", line 77, in _kill_last_child 2015-11-06 08:16:42.410 | 2015-11-06 08:16:42.383 | self._child_processes[-1].disable() 2015-11-06 08:16:42.410 | 2015-11-06 08:16:42.385 | File "neutron/agent/linux/external_process.py", line 109, in disable 2015-11-06 08:16:42.410 | 2015-11-06 08:16:42.386 | utils.execute(cmd, run_as_root=True) 2015-11-06 08:16:42.410 | 2015-11-06 08:16:42.388 | File "neutron/agent/linux/utils.py", line 159, in execute 2015-11-06 08:16:42.411 | 2015-11-06 08:16:42.389 | raise RuntimeError(m) 2015-11-06 08:16:42.411 | 2015-11-06 08:16:42.391 | RuntimeError: 2015-11-06 08:16:42.411 | 2015-11-06 08:16:42.393 | Command: ['sudo', 'kill', '-9', 'None'] 2015-11-06 08:16:42.411 | 2015-11-06 08:16:42.394 | Exit code: 1 2015-11-06 08:16:42.413 | 2015-11-06 08:16:42.396 | Stdin: 2015-11-06 08:16:42.415 | 2015-11-06 08:16:42.397 | Stdout: 2015-11-06 08:16:42.416 | 2015-11-06 08:16:42.399 | Stderr: kill: failed to parse argument: 'None' 2015-11-06 08:16:42.418 | 2015-11-06 08:16:42.400 | 2015-11-06 08:16:42.419 | 2015-11-06 08:16:42.402 | 2015-11-06 08:16:42.440 | 2015-11-06 08:16:42.403 | 2015-11-06 08:16:42.441 | 2015-11-06 08:16:42.405 | Captured pythonlogging: 2015-11-06 08:16:42.441 | 2015-11-06 08:16:42.407 | ~~~ 2015-11-06 08:16:42.441 | 2015-11-06 08:16:42.408 | 2015-11-06 08:14:13,232ERROR [neutron.agent.linux.utils] Unable to convert value in /tmp/tmpPzSZY1/tmpLtA4wt/external/pids/test-uuid-1.pid 2015-11-06 08:16:42.441 | 2015-11-06 08:16:42.410 | 2015-11-06 08:14:13,243ERROR [neutron.agent.linux.utils] 2015-11-06 08:16:42.441 | 2015-11-06 08:16:42.411 | Command: ['sudo', 'kill', '-9', 'None'] 2015-11-06 08:16:42.441 | 2015-11-06 08:16:42.413 | Exit code: 1 2015-11-06 08:16:42.442 | 2015-11-06 08:16:42.414 | Stdin: 2015-11-06 08:16:42.442 | 2015-11-06 08:16:42.416 | Stdout: 2015-11-06 08:16:42.442 | 2015-11-06 08:16:42.418 | Stderr: kill: failed to parse argument: 'None' 2015-11-06 08:16:42.442 | 2015-11-06 08:16:42.420 | 2015-11-06 08:16:42.442 | 2015
[Yahoo-eng-team] [Bug 1675185] Re: cannot disable apt_configure via cloud-config
** Also affects: cloud-init Importance: Undecided Status: New ** Changed in: cloud-init Status: New => Confirmed ** Changed in: cloud-init (Ubuntu) Status: New => Confirmed ** Changed in: cloud-init (Ubuntu) Importance: Undecided => Medium -- 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/1675185 Title: cannot disable apt_configure via cloud-config Status in cloud-init: Confirmed Status in cloud-init package in Ubuntu: Confirmed Bug description: 1. Zesty 2. 0.7.9-68-gef18b8ac-0ubuntu1 3. Boot instance with cloud-config like: #cloud-config apt_configure_enabled: False Or #cloud-config apt_configure: enabled: False cloud-init would not run the apt_configure config module 4. cloud-init cc_apt_configure.py does not check whether it's been disabled by config To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1675185/+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 1676966] [NEW] TrunkManagerTestCase.test_connectivity failed to spawn ping
Public bug reported: http://logs.openstack.org/99/407099/48/check/gate-neutron-dsvm- functional-ubuntu-xenial/bb1c3ee/testr_results.html.gz Traceback (most recent call last): File "neutron/tests/base.py", line 116, in func return f(self, *args, **kwargs) File "neutron/tests/functional/services/trunk/drivers/openvswitch/agent/test_trunk_manager.py", line 216, in test_connectivity self.tester.wait_for_sub_port_connectivity(self.tester.INGRESS) File "neutron/tests/common/conn_testers.py", line 494, in wait_for_sub_port_connectivity "can't get through." % (src_ns, dst_ip))) File "neutron/common/utils.py", line 688, in wait_until_true while not predicate(): File "neutron/tests/common/conn_testers.py", line 60, in all_replied sent, received = _get_packets_sent_received(src_ns, dst_ip, count) File "neutron/tests/common/conn_testers.py", line 54, in _get_packets_sent_received pinger.start() File "neutron/tests/common/net_helpers.py", line 387, in start self.proc = RootHelperProcess(cmd, namespace=self.namespace) File "neutron/tests/common/net_helpers.py", line 280, in __init__ self._wait_for_child_process() File "neutron/tests/common/net_helpers.py", line 315, in _wait_for_child_process "in %d seconds" % (self.cmd, timeout))) File "neutron/common/utils.py", line 693, in wait_until_true raise exception RuntimeError: Process ['ping', '192.168.0.1', '-W', '1', '-c', '3'] hasn't been spawned in 20 seconds http://logs.openstack.org/99/407099/48/check/gate-neutron-dsvm- functional-ubuntu-xenial/bb1c3ee/logs/dsvm-functional- logs/neutron.tests.functional.services.trunk.drivers.openvswitch.agent.test_trunk_manager.TrunkManagerTestCase.test_connectivity.txt.gz ** Affects: neutron Importance: High Status: Confirmed ** Tags: functional-tests gate-failure ** Changed in: neutron Status: New => Confirmed ** Changed in: neutron Importance: Undecided => High ** Tags added: functional-tests gate-failure -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1676966 Title: TrunkManagerTestCase.test_connectivity failed to spawn ping Status in neutron: Confirmed Bug description: http://logs.openstack.org/99/407099/48/check/gate-neutron-dsvm- functional-ubuntu-xenial/bb1c3ee/testr_results.html.gz Traceback (most recent call last): File "neutron/tests/base.py", line 116, in func return f(self, *args, **kwargs) File "neutron/tests/functional/services/trunk/drivers/openvswitch/agent/test_trunk_manager.py", line 216, in test_connectivity self.tester.wait_for_sub_port_connectivity(self.tester.INGRESS) File "neutron/tests/common/conn_testers.py", line 494, in wait_for_sub_port_connectivity "can't get through." % (src_ns, dst_ip))) File "neutron/common/utils.py", line 688, in wait_until_true while not predicate(): File "neutron/tests/common/conn_testers.py", line 60, in all_replied sent, received = _get_packets_sent_received(src_ns, dst_ip, count) File "neutron/tests/common/conn_testers.py", line 54, in _get_packets_sent_received pinger.start() File "neutron/tests/common/net_helpers.py", line 387, in start self.proc = RootHelperProcess(cmd, namespace=self.namespace) File "neutron/tests/common/net_helpers.py", line 280, in __init__ self._wait_for_child_process() File "neutron/tests/common/net_helpers.py", line 315, in _wait_for_child_process "in %d seconds" % (self.cmd, timeout))) File "neutron/common/utils.py", line 693, in wait_until_true raise exception RuntimeError: Process ['ping', '192.168.0.1', '-W', '1', '-c', '3'] hasn't been spawned in 20 seconds http://logs.openstack.org/99/407099/48/check/gate-neutron-dsvm- functional-ubuntu-xenial/bb1c3ee/logs/dsvm-functional- logs/neutron.tests.functional.services.trunk.drivers.openvswitch.agent.test_trunk_manager.TrunkManagerTestCase.test_connectivity.txt.gz To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1676966/+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 1674676] Re: The URL listed against the details of identity resources returns 404 Not Found error
Feel free to reoen if this is actually causing issues in a deployment. ** 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/1674676 Title: The URL listed against the details of identity resources returns 404 Not Found error Status in OpenStack Identity (keystone): Invalid Bug description: Many of the details referencing the relationship between the operation and the resource return 404 Not Found when you try and follow the link. For example, the details of the endpoint given against the following URL: https://developer.openstack.org/api- ref/identity/v3/index.html?expanded=create-endpoint-detail#create- endpoint Points to: https://docs.openstack.org/api/openstack-identity/3/rel/endpoints To describe the relationship but results in a 404 Not Found error. This issue it consistent across many of the relationship links. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1674676/+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 1676952] [NEW] Add "_obj_make_compatible" testing for objects InstancePCIRequests and InstancePCIRequest
Public bug reported: There are no tests for objects: - InstancePCIRequest - InstancePCIRequests Those tests should be added to the unit test inventory. ** Affects: nova Importance: Undecided Status: Invalid ** 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/1676952 Title: Add "_obj_make_compatible" testing for objects InstancePCIRequests and InstancePCIRequest Status in OpenStack Compute (nova): Invalid Bug description: There are no tests for objects: - InstancePCIRequest - InstancePCIRequests Those tests should be added to the unit test inventory. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1676952/+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 1675571] Re: Cloud-init update renders secondary addresses ti be incompatible with standard tools
** Also affects: resolvconf (Ubuntu)
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/1675571
Title:
Cloud-init update renders secondary addresses ti be incompatible with
standard tools
Status in cloud-init:
Confirmed
Status in cloud-init package in Ubuntu:
Confirmed
Status in resolvconf package in Ubuntu:
New
Bug description:
The change of how cloud-init renders
/etc/network/interface.d/50-cloud-init.cfg, standard tools no longer work as
expected:
* resolvconf will nullify nameservers
* if* commands ignore secondary addresses
The rendering is considered dangerous per Debian
(https://wiki.debian.org/NetworkConfiguration), to whit:
"Also, ifupdown supports specifying multiple interfaces by repeating iface
sections with the same interface name. The key difference from the method
described above is that all such sections are treated by ifupdown as just one
interface, so user can't add or remove them individually. However, up/down
commands, as well as scripts, are called for every section as it used to be.
"Note however that this method is dangerous! Certain driver/hardware
combinations may sometimes fail to bring the link up if no labels are assigned
to the alias interfaces. (Seen this on Debian Wheezy and Jessie with
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01)
auto-negotiating to 10/full. A similar warning from another person exists in
the history of this page.)
"
[ORIGINAL REPORT]
Regresion from Bug #1657940.
When provisioning with multiple eth0 addresses, /etc/resolv.conf is
empty:
Consider:
root@tester:~# cat /etc/network/interfaces.d/50-cloud-init.cfg
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 138.197.98.102
dns-nameservers 8.8.8.8 8.8.4.4
gateway 138.197.96.1
netmask 255.255.240.0
# control-alias eth0
iface eth0 inet static
address 10.17.0.11
netmask 255.255.0.0
Which then yields an empty /etc/resolv.conf:
root@tester:/run/resolvconf# cat interface/eth0.inet
root@tester:/run/resolvconf# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
The problem is that resolvconfg does pattern matching for eth*.inet.
The second definition of eth0 has no nameserver and therefore
overrides the definition.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1675571/+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 1676607] Re: cloud-init is disabled when data source is set to just "None"
** Also affects: cloud-init Importance: Undecided Status: New ** Changed in: cloud-init Importance: Undecided => Medium ** Changed in: cloud-init Status: New => Confirmed ** Changed in: cloud-init (Ubuntu) Status: New => Confirmed ** Changed in: cloud-init (Ubuntu) Importance: Undecided => Medium -- 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/1676607 Title: cloud-init is disabled when data source is set to just "None" Status in cloud-init: Confirmed Status in cloud-init package in Ubuntu: Confirmed Bug description: For some images we build as part of the CPC programme, the target cloud doesn't support any sort of metadata, so they are configured with datasource_list as ["None"]. However, we still want cloud-init to run because we lay down some configuration in /etc/cloud/cloud.cfg.d/* (to configure mirrors, for example). Currently, ds-identify will disable cloud-init entirely, which is less than ideal. We either need another data-source name which means "None but please still run", or an independent way of telling ds-identify that its normal data-source logic doesn't work in this case (or just a way of overriding it). To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1676607/+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 1676656] Re: Extensions unit tests failing after neutron change
** Also affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1676656
Title:
Extensions unit tests failing after neutron change
Status in networking-bgpvpn:
In Progress
Status in networking-sfc:
In Progress
Status in neutron:
New
Bug description:
Recent gate runs fail on unit tests, example:
http://logs.openstack.org/54/449754/3/check/gate-networking-sfc-python35/86e22ce/console.html#_2017-03-27_17_35_01_740640
networking_sfc.tests.unit.extensions.test_sfc.SfcExtensionTestCase.test_create_port_chain_none_chain_parameters
Captured traceback:
~~~
b'Traceback (most recent call last):'
b' File "/tmp/openstack/neutron/neutron/tests/base.py", line 116, in
func'
b'return f(self, *args, **kwargs)'
b' File
"/home/jenkins/workspace/gate-networking-sfc-python35/networking_sfc/tests/unit/extensions/test_sfc.py",
line 130, in test_create_port_chain_none_chain_parameters'
b'self._test_create_port_chain(chain_parameters=None)'
b' File
"/home/jenkins/workspace/gate-networking-sfc-python35/networking_sfc/tests/unit/extensions/test_sfc.py",
line 103, in _test_create_port_chain'
b"content_type='application/%s' % self.fmt)"
b' File
"/home/jenkins/workspace/gate-networking-sfc-python35/.tox/py35/lib/python3.5/site-packages/webtest/app.py",
line 378, in post'
b'content_type=content_type)'
b' File
"/home/jenkins/workspace/gate-networking-sfc-python35/.tox/py35/lib/python3.5/site-packages/webtest/app.py",
line 747, in _gen_request'
b'expect_errors=expect_errors)'
b' File
"/home/jenkins/workspace/gate-networking-sfc-python35/.tox/py35/lib/python3.5/site-packages/webtest/app.py",
line 643, in do_request'
b'self._check_status(status, res)'
b' File
"/home/jenkins/workspace/gate-networking-sfc-python35/.tox/py35/lib/python3.5/site-packages/webtest/app.py",
line 675, in _check_status'
b'res)'
b'webtest.app.AppError: Bad response: 500 Internal Server Error (not 200
OK or 3xx redirect for http://localhost/sfc/port_chains.json)'
b'b\'{"NeutronError": {"message": "Request Failed: internal server error
while processing your request.", "type": "HTTPInternalServerError", "detail":
""}}\''
b''
After some research and bisect, these are broken since
93d8376c44cdba58b1db88137b3dcb3a1ad1b2e6 (OVO for Quotas and Reservation )
landed in Neutron:
https://github.com/openstack/neutron/commit/93d8376c44cdba58b1db88137b3dcb3a1ad1b2e6
Fast way to reproduce on single failing test:
tox -e py27
networking_sfc.tests.unit.extensions.test_flowclassifier.FlowClassifierExtensionTestCase.test_create_flow_classifier_all_fields
To manage notifications about this bug go to:
https://bugs.launchpad.net/bgpvpn/+bug/1676656/+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 1486565] Re: Network/Image names allows terminal escape sequence
** Changed in: glance Status: New => Opinion ** Changed in: glance 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/1486565 Title: Network/Image names allows terminal escape sequence Status in Glance: Opinion Status in neutron: Incomplete Status in OpenStack Compute (nova): Opinion Status in OpenStack Security Advisory: Won't Fix Bug description: This allows a malicious user to create network that will mess with administrator terminal when they list network. Steps to reproduces: As a user: neutron net-create $(echo -e "\E[37mhidden\x1b[f") As an admin: neutron net-list To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1486565/+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 1676925] [NEW] db_sync --expand may run downtime-incurring operations
Public bug reported: In discussing a fix for bug 1615014 with Richard, we realized that running: keystone-manage db_sync --expand ... automatically runs legacy (offline) migrations *specifically* when upgrading from Mitaka->Newton. Therefore, we don't technically support zero-downtime, rolling upgrades for Mitaka->Newton, despite having all the rolling upgrade commands available in Newton. Therefore, all of the following migration paths are effectively identical in Mitaka->Newton upgrades, in that they all involve destructive migrations downtime in the first step: Migration path A: keystone-manage db_sync # downtime-incurring operations normally occur here Migration path B: keystone-manage db_sync # downtime-incurring operations normally occur here keystone-manage db_sync --expand # this becomes a no-op keystone-manage db_sync --migrate # this becomes a no-op keystone-manage db_sync --contract # this becomes a no-op Migration path C: keystone-manage db_sync --expand # downtime-incurring operations only occur here in Mitaka->Newton keystone-manage db_sync --migrate keystone-manage db_sync --contract # downtime-incurring operations normally occur here Migration path A is required for migrations up until Liberty->Mitaka, and is still supported in Ocata and beyond. Migration path B works, but there is no reason to recommend this path. Migration path C is recommended for Newton->Ocata upgrades and beyond. ** Affects: keystone Importance: Low Assignee: Dolph Mathews (dolph) Status: Triaged ** Tags: documentation upgrades ** Changed in: keystone Status: New => Triaged -- 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/1676925 Title: db_sync --expand may run downtime-incurring operations Status in OpenStack Identity (keystone): Triaged Bug description: In discussing a fix for bug 1615014 with Richard, we realized that running: keystone-manage db_sync --expand ... automatically runs legacy (offline) migrations *specifically* when upgrading from Mitaka->Newton. Therefore, we don't technically support zero-downtime, rolling upgrades for Mitaka->Newton, despite having all the rolling upgrade commands available in Newton. Therefore, all of the following migration paths are effectively identical in Mitaka->Newton upgrades, in that they all involve destructive migrations downtime in the first step: Migration path A: keystone-manage db_sync # downtime-incurring operations normally occur here Migration path B: keystone-manage db_sync # downtime-incurring operations normally occur here keystone-manage db_sync --expand # this becomes a no-op keystone-manage db_sync --migrate # this becomes a no-op keystone-manage db_sync --contract # this becomes a no-op Migration path C: keystone-manage db_sync --expand # downtime-incurring operations only occur here in Mitaka->Newton keystone-manage db_sync --migrate keystone-manage db_sync --contract # downtime-incurring operations normally occur here Migration path A is required for migrations up until Liberty->Mitaka, and is still supported in Ocata and beyond. Migration path B works, but there is no reason to recommend this path. Migration path C is recommended for Newton->Ocata upgrades and beyond. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1676925/+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 1676922] [NEW] changing Public attribute in FWaaS
Public bug reported: Currently Firewall-as-a-Service uses Public attribute to represent firewall resource which is shared among multiple tenants. However, the attribute should be aptly named as "Shared" and not "Public" [1]. This issue is used to track the migration of "Public" attribute of FWaaS v2 to "Shared". FwaaS v1 is Out of Scope for this bug [1]: http://eavesdrop.openstack.org/meetings/fwaas/2017/fwaas.2017-03-21-14.00.log.html#l-151 ** Affects: neutron Importance: Medium Assignee: Reedip (reedip-banerjee) Status: New ** Tags: fwaas ** Changed in: neutron Assignee: (unassigned) => Reedip (reedip-banerjee) ** Changed in: neutron Importance: Undecided => Medium ** Tags added: fwaas ** Description changed: Currently Firewall-as-a-Service uses Public attribute to represent firewall resource which is shared among multiple tenants. - However, the attribute should be aptly named as "Shared" and not "Public". + However, the attribute should be aptly named as "Shared" and not "Public" [1]. This issue is used to track the migration of "Public" attribute of FWaaS v2 to "Shared". FwaaS v1 is Out of Scope for this bug + [1]: http://eavesdrop.openstack.org/meetings/fwaas/2017/fwaas.2017-03-21-14.00.log.html#l-151 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1676922 Title: changing Public attribute in FWaaS Status in neutron: New Bug description: Currently Firewall-as-a-Service uses Public attribute to represent firewall resource which is shared among multiple tenants. However, the attribute should be aptly named as "Shared" and not "Public" [1]. This issue is used to track the migration of "Public" attribute of FWaaS v2 to "Shared". FwaaS v1 is Out of Scope for this bug [1]: http://eavesdrop.openstack.org/meetings/fwaas/2017/fwaas.2017-03-21-14.00.log.html#l-151 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1676922/+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 1657089] Re: [RFE]Add bandwidth_limit to vip
Patch up for review : https://review.openstack.org/#/c/441912/ ** Project changed: neutron => octavia -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1657089 Title: [RFE]Add bandwidth_limit to vip Status in octavia: New Bug description: Currently, neutron lbaas and octavia just support connection_limit, but not bandwidth_limit. We need support it to make LB more powerful. If no bandwidth_limit, the upstream bottleneck of vip will issue the low speed in the public cloud, eventhough the backend server is powerful. To manage notifications about this bug go to: https://bugs.launchpad.net/octavia/+bug/1657089/+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 1552971] Re: [SRU] InstanceList.get_by_security_group_id can run very slow
This bug was fixed in the package nova - 2:12.0.6-0ubuntu1~cloud1 --- nova (2:12.0.6-0ubuntu1~cloud1) trusty-liberty; urgency=medium . * Backport fix for 'InstanceList.get_by_security_group_id can run very slow' (LP: #1552971): - d/p/list-instances-for-secgroup-without-joining-on-rules.patch ** Changed in: cloud-archive/liberty 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/1552971 Title: [SRU] InstanceList.get_by_security_group_id can run very slow Status in Ubuntu Cloud Archive: Invalid Status in Ubuntu Cloud Archive liberty series: Fix Released Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) mitaka series: Fix Committed Bug description: [Impact] Backporting to Liberty Ubuntu Cloud Archive from Mitaka. The backport is fairly simple and clean with the exception of extra two unit tests that had to be ammended in order to work. The Liberty codebase still has the ec2 api code that is deprecated in Kilo and subsequently removed in Mitaka and there is a unit test for that api that was failing. [Test Case] * Deploy Openstack Liberty with this patch * Populate some security groups and create/delete some instances, checking that the security groups are functioning properly. * Run full Tempest test suite (rev 13.0.0) against deployed cloud. [Regression Potential] This patch has not received any testing with the ec2 api in future releases due the fact that that api is removed in M. Tempest did not find any errors when testing against L though so I not envisaging any regressions. The nova.objects.instance.InstanceList class's get_by_security_group_id function calls the db.security_group_get function, which uses the _security_group_get_query() function to generate a query object. That query, by default, joins with the secgroup-rules table, and currently the db.security_group_get function offers no option to avoid joining with the rules. As a result: If a group-source secgroup-rule exists on a security group with a large number of instances and a large number of rules, the db query result will be very large and take multiple seconds to complete, tying up conductor and making the system unresponsive. Since the InstanceList.get_by_security_group_id call only aims to build a list of instances, there is no need in this case to join with the rules, and so the db.security_group_get call should optionally avoid joining with the rules table. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1552971/+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 1552971] Re: [SRU] InstanceList.get_by_security_group_id can run very slow
The verification of the Stable Release Update for nova has completed successfully and the package has now been released to -updates. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. ** 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/1552971 Title: [SRU] InstanceList.get_by_security_group_id can run very slow Status in Ubuntu Cloud Archive: Invalid Status in Ubuntu Cloud Archive liberty series: Fix Released Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) mitaka series: Fix Committed Bug description: [Impact] Backporting to Liberty Ubuntu Cloud Archive from Mitaka. The backport is fairly simple and clean with the exception of extra two unit tests that had to be ammended in order to work. The Liberty codebase still has the ec2 api code that is deprecated in Kilo and subsequently removed in Mitaka and there is a unit test for that api that was failing. [Test Case] * Deploy Openstack Liberty with this patch * Populate some security groups and create/delete some instances, checking that the security groups are functioning properly. * Run full Tempest test suite (rev 13.0.0) against deployed cloud. [Regression Potential] This patch has not received any testing with the ec2 api in future releases due the fact that that api is removed in M. Tempest did not find any errors when testing against L though so I not envisaging any regressions. The nova.objects.instance.InstanceList class's get_by_security_group_id function calls the db.security_group_get function, which uses the _security_group_get_query() function to generate a query object. That query, by default, joins with the secgroup-rules table, and currently the db.security_group_get function offers no option to avoid joining with the rules. As a result: If a group-source secgroup-rule exists on a security group with a large number of instances and a large number of rules, the db query result will be very large and take multiple seconds to complete, tying up conductor and making the system unresponsive. Since the InstanceList.get_by_security_group_id call only aims to build a list of instances, there is no need in this case to join with the rules, and so the db.security_group_get call should optionally avoid joining with the rules table. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1552971/+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 1676908] [NEW] DigitalOcean network improvements
Public bug reported: This is a request to merge the improvements to the linked PR that improves the DigitalOcean datasource. The changes: - No longer bind the nameservers to a specific interface to bring it inline with the other DataSources like OpenStack and SmartOS. - Fix mis-binding the IPV4all address to a secondary interface by considering 'eth0' or 'ens3' first - Consider all network definitions, not just 'public' or 'private'. ** 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/1676908 Title: DigitalOcean network improvements Status in cloud-init: New Bug description: This is a request to merge the improvements to the linked PR that improves the DigitalOcean datasource. The changes: - No longer bind the nameservers to a specific interface to bring it inline with the other DataSources like OpenStack and SmartOS. - Fix mis-binding the IPV4all address to a secondary interface by considering 'eth0' or 'ens3' first - Consider all network definitions, not just 'public' or 'private'. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1676908/+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 1669430] Re: Deprecation warning in Neutron QoSDSCPMarkingRule functional tests
This change was addressed by this patch: https://review.openstack.org/#/c/438148 This bug should be closed. ** 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/1669430 Title: Deprecation warning in Neutron QoSDSCPMarkingRule functional tests Status in neutron: Fix Released Bug description: http://logs.openstack.org/56/425756/18/check/gate-neutron-dsvm- fullstack-ubuntu- xenial/49cf5a9/console.html#_2017-03-01_14_32_34_632471 DeprecationWarning: Raising eventlet.TimeoutError by default has been deprecated in version 'Ocata' and will be removed in version 'Pike': wait_until_true() now raises WaitTimeout error by default. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1669430/+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 1645810] Re: neutron api update port and agent rpc update port timestamp may cause db deadlock
Also we don't lock records anymore. ** Tags removed: needs-attention ** Changed in: neutron Status: New => Fix Released ** Changed in: neutron Status: Fix Released => Opinion -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1645810 Title: neutron api update port and agent rpc update port timestamp may cause db deadlock Status in neutron: Opinion Bug description: The test scenario as follow steps : 1,server api update some attributes of port ,like hostid: (1),ml2 plugin: update_port > db.get_locked_port_and_binding . (2),server api thread get port db update lock , and wait for release lock to update timestamp. 2,ovs agent receive rpc message ,handler update port statues (1),ovs agent rpc method update_port_status is called (2),in this method it will flush session firstly to get timestamp lock for updating port 3,at the this time : (1),agent rpc get timestamp lock to update timestamp (2),server api get port lock to update port (3),agent method update_port_status wait for port lock , but server method db.get_locked_port_and_binding also wait for timestamp lock which caused deadlock To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1645810/+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 1674961] Re: Instances are not left in active state after a notification test
Reviewed: https://review.openstack.org/448655 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=300e64f84fff086a5ed2ee0c45d539e3268efc68 Submitter: Jenkins Branch:master commit 300e64f84fff086a5ed2ee0c45d539e3268efc68 Author: Gábor Antal Date: Wed Mar 22 16:11:43 2017 +0100 Ensure instance is in active state after notification test In versioned notification tests, we should ensure that after testing a notification in test_instance_action, the instance is in active state. Currently, there is no guarantee that instance left in active state after a notification test. In this patchset, it is ensured, and the notifications, which violates this rule, are refactored. Change-Id: Iff0012a4065e6b69c96e1a4f2074340d9c41 Co-Authored-By: Béla Vancsics Implements: bp versioned-notification-transformation-pike Closes-Bug: #1674961 ** 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/1674961 Title: Instances are not left in active state after a notification test Status in OpenStack Compute (nova): Fix Released Bug description: As a notification transformation guideline in [1] explains that each called test in test_instance_action should ensure that instance is left in ACTIVE state after a notification test. However currently it is not ensured, thus some of the test does not even care about it (like suspend, pause actions). This can cause problems, which can be seen at [2]. In the future, we should ensure that after a test, the instance is in active state. [1]: https://github.com/openstack/nova/blob/39cd54091747723a392dc33a2b5d6f5a28b537a7/nova/tests/functional/notification_sample_tests/test_instance.py#L57 [2]: https://review.openstack.org/#/c/396225/21 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1674961/+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 1676877] [NEW] Increase "TestQosPlugin.test_update_policy_rule" coverage
Public bug reported: Test "test_update_policy_rule" [1] is not fully testing the functionality of the function under test, for several reasons: - The test is not testing the QoS policy object has the rule updated. In [2], the QoS policy reload the rules by requesting from the DB the new rule objects and then writing the result to "rules" member. [3] should be mocked to return the correct values (updated rules). - The test is updating the rule value with the same content. At least there should be a change in the content to check the difference. - Function "_validate_driver_params" should check not only the last parameter in the notification driver and the service notification call is a QosPolicy object, but also the content of the parameter. [1] https://github.com/openstack/neutron/blob/master/neutron/tests/unit/services/qos/test_qos_plugin.py#L155 [2] https://github.com/openstack/neutron/blob/master/neutron/services/qos/qos_plugin.py#L94 [3] https://github.com/openstack/neutron/blob/master/neutron/objects/qos/policy.py#L80 ** Affects: neutron Importance: Undecided Assignee: Reedip (reedip-banerjee) Status: New ** Tags: qos ** Tags added: qos -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1676877 Title: Increase "TestQosPlugin.test_update_policy_rule" coverage Status in neutron: New Bug description: Test "test_update_policy_rule" [1] is not fully testing the functionality of the function under test, for several reasons: - The test is not testing the QoS policy object has the rule updated. In [2], the QoS policy reload the rules by requesting from the DB the new rule objects and then writing the result to "rules" member. [3] should be mocked to return the correct values (updated rules). - The test is updating the rule value with the same content. At least there should be a change in the content to check the difference. - Function "_validate_driver_params" should check not only the last parameter in the notification driver and the service notification call is a QosPolicy object, but also the content of the parameter. [1] https://github.com/openstack/neutron/blob/master/neutron/tests/unit/services/qos/test_qos_plugin.py#L155 [2] https://github.com/openstack/neutron/blob/master/neutron/services/qos/qos_plugin.py#L94 [3] https://github.com/openstack/neutron/blob/master/neutron/objects/qos/policy.py#L80 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1676877/+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 1676876] [NEW] cloud-init login warning
Public bug reported: login as: ubuntu Authenticating with public key Welcome to Ubuntu 16.04.2 LTS (GNU/Linux 4.4.0-70-generic x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support:https://ubuntu.com/advantage Get cloud support with Ubuntu Advantage Cloud Guest: http://www.ubuntu.com/business/services/cloud 0 packages can be updated. 0 updates are security updates. Last login: Tue Mar 28 15:29:39 2017 from * ** # A new feature in cloud-init identified possible datasources for# # this system as:# # ['Ec2', 'None'] # # However, the datasource used was: OpenStack# ## # In the future, cloud-init will only attempt to use datasources that# # are identified or specifically configured. # # For more information see # # https://bugs.launchpad.net/bugs/1669675 # ## # If you are seeing this message, please file a bug against # # cloud-init at # #https://bugs.launchpad.net/cloud-init/+filebug?field.tags=dsid # # Make sure to include the cloud provider your instance is # # running on.# ## # After you have filed a bug, you can disable this warning by launching # # your instance with the cloud-config below, or putting that content # # into /etc/cloud/cloud.cfg.d/99-warnings.cfg# ## # #cloud-config # # warnings: # # dsid_missing_source: off # ** Disable the warnings above by: touch /home/ubuntu/.cloud-warnings.skip or touch /var/lib/cloud/instance/warnings/.skip ubuntu@images-import:~$ ** Affects: cloud-init Importance: Undecided Status: New ** Tags: dsid -- 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/1676876 Title: cloud-init login warning Status in cloud-init: New Bug description: login as: ubuntu Authenticating with public key Welcome to Ubuntu 16.04.2 LTS (GNU/Linux 4.4.0-70-generic x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support:https://ubuntu.com/advantage Get cloud support with Ubuntu Advantage Cloud Guest: http://www.ubuntu.com/business/services/cloud 0 packages can be updated. 0 updates are security updates. Last login: Tue Mar 28 15:29:39 2017 from * ** # A new feature in cloud-init identified possible datasources for# # this system as:# # ['Ec2', 'None'] # # However, the datasource used was: OpenStack# ## # In the future, cloud-init will only attempt to use datasources that# # are identified or specifically configured. # # For more information see # # https://bugs.launchpad.net/bugs/1669675 # ## # If you are seeing this message, please file a bug against # # cloud-init at # #https://bugs.launchpad.net/cloud-init/+filebug?field.tags=dsid # # Make sure to include the cloud provider your instance is # # running on.# ## # After you have filed a bug, you can disable this warning by launching # # your instance with the cloud-config below, or putting that content # # into /etc/cloud/cloud.cfg.d/99-warnings.cfg# ## # #cloud-config
[Yahoo-eng-team] [Bug 1676828] [NEW] identify datasource OpenStack - Cloud-init shows warning on Openstack
Public bug reported: Ubuntu Xenial shows the following information after logging in. The Image is started on Openstack Mitaka included with Ubuntu Xenial using the LXD hypervisor: ** # A new feature in cloud-init identified possible datasources for# # this system as:# # ['None'] # # However, the datasource used was: OpenStack# ## # In the future, cloud-init will only attempt to use datasources that# # are identified or specifically configured. # # For more information see # # https://bugs.launchpad.net/bugs/1669675 # ## # If you are seeing this message, please file a bug against # # cloud-init at # #https://bugs.launchpad.net/cloud-init/+filebug?field.tags=dsid # # Make sure to include the cloud provider your instance is # # running on.# ## # After you have filed a bug, you can disable this warning by launching # # your instance with the cloud-config below, or putting that content # # into /etc/cloud/cloud.cfg.d/99-warnings.cfg# ## # #cloud-config # # warnings: # # dsid_missing_source: off # ** Version of cloud-init: ubuntu@test:~$ dpkg -s cloud-init Package: cloud-init Status: install ok installed Priority: extra Section: admin Installed-Size: 1417 Maintainer: Scott Moser Architecture: all Version: 0.7.9-48-g1c795b9-0ubuntu1~16.04.1 Replaces: ec2-init (<< 0.5.3) Provides: ec2-init ** Affects: cloud-init Importance: Undecided Status: New ** Tags: dsid ** Summary changed: - Cloud-init shows warning on Openstack + identify datasource Openstack - Cloud-init shows warning on Openstack ** Summary changed: - identify datasource Openstack - Cloud-init shows warning on Openstack + identify datasource OpenStack - Cloud-init shows warning on Openstack -- 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/1676828 Title: identify datasource OpenStack - Cloud-init shows warning on Openstack Status in cloud-init: New Bug description: Ubuntu Xenial shows the following information after logging in. The Image is started on Openstack Mitaka included with Ubuntu Xenial using the LXD hypervisor: ** # A new feature in cloud-init identified possible datasources for# # this system as:# # ['None'] # # However, the datasource used was: OpenStack# ## # In the future, cloud-init will only attempt to use datasources that# # are identified or specifically configured. # # For more information see # # https://bugs.launchpad.net/bugs/1669675 # ## # If you are seeing this message, please file a bug against # # cloud-init at # #https://bugs.launchpad.net/cloud-init/+filebug?field.tags=dsid # # Make sure to include the cloud provider your instance is # # running on.# ## # After you have filed a bug, you can disable this warning by launching # # your instance with the cloud-config below, or putting that content # # into /etc/cloud/cloud.cfg.d/99-warnings.cfg# ## # #cloud-config # # warnings: # # dsid_missing_source:
[Yahoo-eng-team] [Bug 1676811] [NEW] Get error "Unable to create server" when launch new instance
Public bug reported:
Step to reproduce:
1 Go to dashboard then create new instance
Actual result:
App return error message "Unable to create server"
Environment:
Centos7, Openstack mitaka
Note:
Check nova log
tail -100f /var/log/nova/nova-api.log
2017-03-28 05:44:05.407 6517 ERROR nova.image.glance CommunicationError: Error
finding address for
http://controller:9292/v1/images/7ed07fa9-82b7-4095-8c5f-92e8104bfe05:
('Connection aborted.', LineTooLong('got more than 65536 bytes when reading
header line',))
2017-03-28 05:44:05.407 6517 ERROR nova.image.glance
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions
[req-e57abe3f-af2c-4cb5-9a0b-35aa4668d99a 9b2b14c8e96f4dcbbdd18d82506be7de
4b710995d93e4a5da3c596ab94418557 - - -] Unexpected exception in API method
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions Traceback
(most recent call last):
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions File
"/usr/lib/python2.7/site-packages/nova/api/openstack/extensions.py", line 478,
in wrapped
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions return
f(*args, **kwargs)
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions File
"/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 73, in
wrapper
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions return
func(*args, **kwargs)
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions File
"/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 73, in
wrapper
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions return
func(*args, **kwargs)
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions File
"/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 73, in
wrapper
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions return
func(*args, **kwargs)
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions File
"/usr/lib/python2.7/site-packages/nova/api/openstack/compute/servers.py", line
629, in create
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions
**create_kwargs)
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions File
"/usr/lib/python2.7/site-packages/nova/hooks.py", line 154, in inner
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions rv =
f(*args, **kwargs)
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions File
"/usr/lib/python2.7/site-packages/nova/compute/api.py", line 1563, in create
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions
check_server_group_quota=check_server_group_quota)
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions File
"/usr/lib/python2.7/site-packages/nova/compute/api.py", line 1131, in
_create_instance
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions image_id,
boot_meta = self._get_image(context, image_href)
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions File
"/usr/lib/python2.7/site-packages/nova/compute/api.py", line 789, in _get_image
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions image =
self.image_api.get(context, image_href)
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions File
"/usr/lib/python2.7/site-packages/nova/image/api.py", line 93, in get
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions
show_deleted=show_deleted)
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions File
"/usr/lib/python2.7/site-packages/nova/image/glance.py", line 333, in show
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions
_reraise_translated_image_exception(image_id)
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions File
"/usr/lib/python2.7/site-packages/nova/image/glance.py", line 684, in
_reraise_translated_image_exception
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions
six.reraise(new_exc, None, exc_trace)
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions File
"/usr/lib/python2.7/site-packages/nova/image/glance.py", line 331, in show
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions image =
self._client.call(context, version, 'get', image_id)
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions File
"/usr/lib/python2.7/site-packages/nova/image/glance.py", line 269, in call
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions
server=str(self.api_server), reason=six.text_type(e))
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extensions
GlanceConnectionFailed: Connection to glance host http://controller:9292
failed: Error finding address for
http://controller:9292/v1/images/7ed07fa9-82b7-4095-8c5f-92e8104bfe05:
('Connection aborted.', LineTooLong('got more than 65536 bytes when reading
header line',))
2017-03-28 05:44:05.409 6517 ERROR nova.api.openstack.extens
[Yahoo-eng-team] [Bug 1676815] [NEW] A new feature in cloud-init identified possible datasources
Public bug reported: ** # A new feature in cloud-init identified possible datasources for# # this system as:# # ['Ec2', 'None'] # # However, the datasource used was: OpenStack# ## # In the future, cloud-init will only attempt to use datasources that# # are identified or specifically configured. # # For more information see # # https://bugs.launchpad.net/bugs/1669675 # ## # If you are seeing this message, please file a bug against # # cloud-init at # #https://bugs.launchpad.net/cloud-init/+filebug?field.tags=dsid # # Make sure to include the cloud provider your instance is # # running on.# ## # After you have filed a bug, you can disable this warning by launching # # your instance with the cloud-config below, or putting that content # # into /etc/cloud/cloud.cfg.d/99-warnings.cfg# ## # #cloud-config # # warnings: # # dsid_missing_source: off # ** Running Ubuntu 16.04 on http://cloud9.nebula.fi/ OpenStack ** Affects: cloud-init Importance: Undecided Status: New ** Tags: dsid -- 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/1676815 Title: A new feature in cloud-init identified possible datasources Status in cloud-init: New Bug description: ** # A new feature in cloud-init identified possible datasources for# # this system as:# # ['Ec2', 'None'] # # However, the datasource used was: OpenStack# ## # In the future, cloud-init will only attempt to use datasources that# # are identified or specifically configured. # # For more information see # # https://bugs.launchpad.net/bugs/1669675 # ## # If you are seeing this message, please file a bug against # # cloud-init at # #https://bugs.launchpad.net/cloud-init/+filebug?field.tags=dsid # # Make sure to include the cloud provider your instance is # # running on.# ## # After you have filed a bug, you can disable this warning by launching # # your instance with the cloud-config below, or putting that content # # into /etc/cloud/cloud.cfg.d/99-warnings.cfg# ## # #cloud-config # # warnings: # # dsid_missing_source: off # ** Running Ubuntu 16.04 on http://cloud9.nebula.fi/ OpenStack To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1676815/+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 1676787] [NEW] Release note shows non-existent feature
Public bug reported: Ocata release note shows linux bridge supports QoS egress minimum bandwidth but it's reverted in Ocata[2]. [1]: https://docs.openstack.org/releasenotes/neutron/ocata.html#new-features [2]: https://review.openstack.org/#/c/431506/ ** Affects: neutron Importance: Undecided Assignee: Hirofumi Ichihara (ichihara-hirofumi) Status: In Progress ** Tags: qos ** Changed in: neutron Assignee: (unassigned) => Hirofumi Ichihara (ichihara-hirofumi) ** Tags added: qos -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1676787 Title: Release note shows non-existent feature Status in neutron: In Progress Bug description: Ocata release note shows linux bridge supports QoS egress minimum bandwidth but it's reverted in Ocata[2]. [1]: https://docs.openstack.org/releasenotes/neutron/ocata.html#new-features [2]: https://review.openstack.org/#/c/431506/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1676787/+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 1676298] Re: Need to remove usage of novaclient.v2.security_group_rules
This also affects Horizon, which uses novaclient.v2.security_group_rules in https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/nova.py#L36 ** Also affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1676298 Title: Need to remove usage of novaclient.v2.security_group_rules Status in OpenStack Dashboard (Horizon): New Status in python-openstackclient: New Bug description: python-novaclient has removed the deprecated security_group_rules APIs in https://review.openstack.org/447707 . These are still being used by openstackclient (see [1]), so it will fail when a new novaclient version is released. [1] https://github.com/openstack/python- openstackclient/blob/f63a9f402dc3761a1f7e358d92b7e1aa33098c7a/openstackclient/network/v2/security_group_rule.py#L19-L22 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1676298/+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
