[Yahoo-eng-team] [Bug 1757425] Re: Problem with Pip 9.0.2 and Ryu (dependency)
As per Brian's comment, closing this ticket. Please consider reopening if the repro conditions happen to be different or the proposed fix does not solve the issue you're observing. ** Changed in: neutron Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1757425 Title: Problem with Pip 9.0.2 and Ryu (dependency) Status in neutron: Invalid Bug description: Hello, While I was following kolla kubernetes guide for containerized Openstack I found a problem concerning Neutron and its dependency Ryu, while using new Pip version (9.0.2). I am creating this issue here because it may affect other users of Neutron. Please find more information on the issues I opened to Pip page and kolla-kubernetes launchpad. * https://bugs.launchpad.net/kolla-kubernetes/+bug/1757140 * https://github.com/pypa/pip/issues/5099 Kind regards. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1757425/+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 1750121] Re: Dynamic routing: adding speaker to agent fails
Reviewed: https://review.openstack.org/545783 Committed: https://git.openstack.org/cgit/openstack/neutron-dynamic-routing/commit/?id=fd497a491afec89d4a15cf061b5d5610fb7ad6d2 Submitter: Zuul Branch:master commit fd497a491afec89d4a15cf061b5d5610fb7ad6d2 Author: Jens Harbott Date: Mon Feb 19 10:53:04 2018 +0100 Fix failure when adding a speaker to an agent When get_bgp_speaker_with_advertised_routes() collects the data for BGP peers, it needs to include the auth_type field, otherwise adding the speaker to an agent will fail. Change-Id: I668397be4a531ba5c0628eb23df9a84d0de8c28c Closes-Bug: 1750121 ** 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/1750121 Title: Dynamic routing: adding speaker to agent fails Status in neutron: Fix Released Bug description: When following https://docs.openstack.org/neutron-dynamic- routing/latest/contributor/testing.html everything works fine because the speaker is scheduled to the agent automatically (in contrast to what the docs say). But if I remove the speaker from the agent and add it again with $ neutron bgp-dragent-speaker-remove 0159fc0a-22de-4995-8fad-8fb8835a4d86 bgp-speaker $ neutron bgp-dragent-speaker-add 0159fc0a-22de-4995-8fad-8fb8835a4d86 bgp-speaker the following error is seen in the log: Feb 17 10:56:30 test-node01 neutron-bgp-dragent[18999]: ERROR neutron_dynamic_routing.services.bgp.agent.bgp_dragent [None req- da9a22ae-52a2-4be7-a3e8-2dc2dc970fdd admin admin] Call to driver for BGP Speaker d2aa5935-30c2-4369-83ee-b3a0ff77cc49 add_bgp_peer has failed with exception 'auth_type'. The same thing happens when there are multiple agents and one tries to add the speaker to one of the other agents. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1750121/+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 1757190] Re: resize fails with volume multiattach using with libvirt 4.0.0 (and qemu 2.11.1): Failed to get shared "write" lock
Reviewed: https://review.openstack.org/554667 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=5f3cca205581d45d92714ce1a909d4394b7812ff Submitter: Zuul Branch:master commit 5f3cca205581d45d92714ce1a909d4394b7812ff Author: Matt Riedemann Date: Tue Mar 20 15:04:27 2018 -0400 Preserve multiattach flag when refreshing connection_info When we attach a multiattach-capable volume, we do something dirty and stash a "multiattach" boolean flag in the BlockDeviceMapping.connection_info dict. This is used by the virt driver to determine how to connect the volume (for the libvirt driver, it sets the "shareable" element on the disk config xml). When resizing an instance, ComputeManager._finish_resize on the destination host refreshes the block device mapping list along with the connection_info for each BDM. Because of this, it would overwrite the BDM.connection_info along with the stashed "multiattach" flag which is later used to connect the volumes on the destination host via the virt driver.finish_migration method. This leads to failures with multiattach volumes because the disk config is wrong. To fix this, when refreshing BDM connection_info, we preserve the multiattach flag in the connection_info, similar to the serial (volume ID) and multipath_id. Interestingly enough, the nova-multiattach job does not fail the volume multiattach resize test with libvirt 1.3.1 and qemu 2.5. This failure was only noticed once the nova-multiattach job was tested with libvirt 4.0.0 and qemu 2.11.1. So maybe there was something in the older package versions that masked this obvious bug in the nova code. Change-Id: Iaee13478212cc04e6d1a1249f33822369d94d41d Closes-Bug: #1757190 ** 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/1757190 Title: resize fails with volume multiattach using with libvirt 4.0.0 (and qemu 2.11.1): Failed to get shared "write" lock Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) queens series: In Progress Bug description: Seeing this in a patch https://review.openstack.org/#/c/554317/ that runs the nova-multiattach job with the Queens Ubuntu Cloud Archive which has libvirt 4.0.0 and qemu 2.11.1: http://logs.openstack.org/17/554317/1/check/nova- multiattach/8e97832/logs/libvirt/qemu/instance-0066.txt.gz 2018-03-19T19:48:16.175548Z qemu-system-x86_64: -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1: Failed to get shared "write" lock Is another process using the image? http://logs.openstack.org/17/554317/1/check/nova-multiattach/8e97832/logs/screen-n-cpu.txt.gz?level=TRACE#_Mar_19_19_48_16_261051 Mar 19 19:48:17.132940 ubuntu-xenial-inap-mtl01-0003062768 nova-compute[27735]: ERROR nova.compute.manager [None req-3a092a4b-7ae7-4f29-9f78-97bf1dc0d46d service nova] [instance: 0eed0237-245e-4a18-9e30-9e72accd36c6] Setting instance vm_state to ERROR: libvirtError: internal error: process exited while connecting to monitor: 2018-03-19T19:48:16.147136Z qemu-system-x86_64: -drive file=/dev/sdb,format=raw,if=none,id=drive-virtio-disk1,serial=652600d5-f6dc-4089-ba95-d71d7640cafa,cache=none,aio=native: 'serial' is deprecated, please use the corresponding option of '-device' instead Mar 19 19:48:17.133724 ubuntu-xenial-inap-mtl01-0003062768 nova-compute[27735]: 2018-03-19T19:48:16.155115Z qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5] Mar 19 19:48:17.134022 ubuntu-xenial-inap-mtl01-0003062768 nova-compute[27735]: 2018-03-19T19:48:16.175548Z qemu-system-x86_64: -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1: Failed to get shared "write" lock That last error likely means the 'shareable' element isn't in the disk config xml, and it's not: 652600d5-f6dc-4089-ba95-d71d7640cafa To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1757190/+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 1757931] [NEW] Some policy values are not actually respected
Public bug reported: I have a (slightly imaginary) deployment in which I want to allow some service user to get information about networks belonging to other projects, but I don't want this user to be the admin of the entire Neutron. To satisfy that requirement, I took a look in policy.json and found the following default entry: "get_network": "rule:admin_or_owner or rule:shared or rule:external or rule:context_is_advsvc" Naturally I tried to add an additional "or role:some_service_role" in order to make it so this special service user would have those extra permissions I desire. Unfortunately this did not work. It turns out that, at least from my experience, this policy file entry is not actually interpreted in a meaningful way by Neutron. To test my theory that the policy values are not respected, I tried manipulating the following line: "external": "field:networks:router:external=True" ...just for fun I tried setting external to False, changing the whole string to "rule:some_other_rule", etc... from all these policy.json changes nothing actually changed in Neutron's behavior. Based on the little that I know about how Neutron has its API and database logic stitched together, I'm assuming that there is some logic there which does something hardcoded equivalent to "rule:admin_or_owner or rule:shared or rule:external or rule:context_is_advsvc"... but isn't actually looking in the policy file to see what the operator might have overridden. I wonder if others can reproduce this, and also what the steps forward would be. ** 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/1757931 Title: Some policy values are not actually respected Status in neutron: New Bug description: I have a (slightly imaginary) deployment in which I want to allow some service user to get information about networks belonging to other projects, but I don't want this user to be the admin of the entire Neutron. To satisfy that requirement, I took a look in policy.json and found the following default entry: "get_network": "rule:admin_or_owner or rule:shared or rule:external or rule:context_is_advsvc" Naturally I tried to add an additional "or role:some_service_role" in order to make it so this special service user would have those extra permissions I desire. Unfortunately this did not work. It turns out that, at least from my experience, this policy file entry is not actually interpreted in a meaningful way by Neutron. To test my theory that the policy values are not respected, I tried manipulating the following line: "external": "field:networks:router:external=True" ...just for fun I tried setting external to False, changing the whole string to "rule:some_other_rule", etc... from all these policy.json changes nothing actually changed in Neutron's behavior. Based on the little that I know about how Neutron has its API and database logic stitched together, I'm assuming that there is some logic there which does something hardcoded equivalent to "rule:admin_or_owner or rule:shared or rule:external or rule:context_is_advsvc"... but isn't actually looking in the policy file to see what the operator might have overridden. I wonder if others can reproduce this, and also what the steps forward would be. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1757931/+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 1757919] [NEW] Downloading created key-pair was prevented by popup blocker
Public bug reported: After Chrome update to version 64, it blocks downloading created private key on new window. This problem occurs in Angularized panels that uses text-download service. ** Affects: horizon Importance: Undecided Assignee: Shu Muto (shu-mutou) Status: In Progress ** Changed in: horizon Assignee: (unassigned) => Shu Muto (shu-mutou) ** Changed in: horizon Status: New => In Progress ** Description changed: After Chrome update to version 64, it blocks downloading created private key on new window. - This problem occurs in Angularized panels using text-download service. + This problem occurs in Angularized panels that uses text-download service. -- 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/1757919 Title: Downloading created key-pair was prevented by popup blocker Status in OpenStack Dashboard (Horizon): In Progress Bug description: After Chrome update to version 64, it blocks downloading created private key on new window. This problem occurs in Angularized panels that uses text-download service. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1757919/+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 1750917] Re: Insufficient logging when xmlsec binary is missing
Reviewed: https://review.openstack.org/553592 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=ccdf2d976f4d26df4f6a2a915da6ff0f643757ac Submitter: Zuul Branch:master commit ccdf2d976f4d26df4f6a2a915da6ff0f643757ac Author: Lance Bragstad Date: Thu Mar 15 19:39:43 2018 + Add logging for xmlsec1 installation Keystone uses a library called xmlsec1 to create SAML assertions when acting as an identity provider. If this library isn't present and someone attempts to authenticate, keystone will throw an HTTP 500. The only thing the error says is that a file or directory doesn't exist. This patch uses subprocess to check if the provided binary actually exists on the system and handles cases when it isn't and logs a useful message for operators. Change-Id: I41cf87702df5389c1424d35f0abcef9c16301450 Closes-Bug: 1750917 ** 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/1750917 Title: Insufficient logging when xmlsec binary is missing Status in OpenStack Identity (keystone): Fix Released Bug description: Keystone log is also unhelpful. All we got is "ERROR idp _sign_assertion Error when signing assertion, reason: [Errno 2] No such file or directory" When the xmlsec1 package is absent. We may need to add a check here https://github.com/openstack/keystone/blob/master/keystone/federation/idp.py#L421 to see if CONF.saml.xmlsec1_binary exist. If absent, we just to provide a more helpful log entry. Steps to reproduce: 1. Install devstack and enable federation. 2. Uninstall the xmlsec1 package 3. Try to authenticate via federation and you'll get a HTTP 500 error and the corresponding log entry in keystone.log To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1750917/+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 1752152] Re: Attach Volume Fails with secure call to cinder
I'm also beginning to wonder how it is that if this was regressed since
Pike, how is it we haven't heard more about this issue? I assume most
productions clouds are using SSL.
** Changed in: nova
Status: Triaged => Incomplete
** No longer affects: nova/pike
** No longer affects: nova/queens
--
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/1752152
Title:
Attach Volume Fails with secure call to cinder
Status in OpenStack Compute (nova):
Incomplete
Status in python-cinderclient:
Invalid
Bug description:
It is found that when cinder endpoint is configured to use https,
attach volume flow fails with the stack trace seen below (seen in nova
api log) because it fails to make a secure call from nova to cinder.
Secure calls perform certificate validation and in this particular
flow, certificate validation is completely skipped
File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 3971, in
attach_volume
2018-02-27 08:16:51.338 1324 ERROR
cinder.is_microversion_supported(context, '3.44')
2018-02-27 08:16:51.338 1324 ERRORFile
"/usr/lib/python2.7/site-packages/nova/volume/cinder.py", line 138, in
is_microversion_supported
2018-02-27 08:16:51.338 1324 ERROR _check_microversion(url, microversion)
2018-02-27 08:16:51.338 1324 ERRORFile
"/usr/lib/python2.7/site-packages/nova/volume/cinder.py", line 86, in
_check_microversion
2018-02-27 08:16:51.338 1324 ERROR max_api_version =
cinder_client.get_highest_client_server_version(url)
2018-02-27 08:16:51.338 1324 ERRORFile
"/usr/lib/python2.7/site-packages/cinderclient/client.py", line 126, in
get_highest_client_server_version
2018-02-27 08:16:51.338 1324 ERROR min_server, max_server =
get_server_version(url)
2018-02-27 08:16:51.338 1324 ERRORFile
"/usr/lib/python2.7/site-packages/cinderclient/client.py", line 109, in
get_server_version
2018-02-27 08:16:51.338 1324 ERROR response = requests.get(version_url)
2018-02-27 08:16:51.338 1324 ERRORFile
"/usr/lib/python2.7/site-packages/requests/api.py", line 72, in get
2018-02-27 08:16:51.338 1324 ERROR return request('get', url,
params=params, **kwargs)
2018-02-27 08:16:51.338 1324 ERRORFile
"/usr/lib/python2.7/site-packages/requests/api.py", line 58, in request
2018-02-27 08:16:51.338 1324 ERROR return session.request(method=method,
url=url, **kwargs)
2018-02-27 08:16:51.338 1324 ERRORFile
"/usr/lib/python2.7/site-packages/requests/sessions.py", line 502, in request
2018-02-27 08:16:51.338 1324 ERROR resp = self.send(prep, **send_kwargs)
2018-02-27 08:16:51.338 1324 ERRORFile
"/usr/lib/python2.7/site-packages/requests/sessions.py", line 612, in send
2018-02-27 08:16:51.338 1324 ERROR r = adapter.send(request, **kwargs)
2018-02-27 08:16:51.338 1324 ERRORFile
"/usr/lib/python2.7/site-packages/requests/adapters.py", line 504, in send
2018-02-27 08:16:51.338 1324 ERROR raise ConnectionError(e,
request=request)
2018-02-27 08:16:51.338 1324 ERROR ConnectionError:
HTTPSConnectionPool(host='ip9-114-192-132.pok.stglabs.ibm.com', port=9000): Max
retries exceeded with url: / (Caused by SSLError(SSLError("bad handshake:
Error([('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify
failed')],)",),))
This is a regression bug introduced as part of changeset
https://review.openstack.org/#/c/469579/, which was merged way back in
June 2017. As part of this changeset, a new function namely
_check_microversion was introduced, which then makes a cinderclient
call , which finally makes a cinder https REST api call without
passing the certificate. This leads to the problem listed above.
https://github.com/openstack/nova/blob/stable/queens/nova/volume/cinder.py#L75
https://github.com/openstack/nova/blob/stable/queens/nova/volume/cinder.py#L86
https://github.com/openstack/python-cinderclient/blob/stable/queens/cinderclient/client.py#L126
https://github.com/openstack/python-cinderclient/blob/stable/queens/cinderclient/client.py#L109
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1752152/+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 1757562] Re: "Network Mask" field in "Subnet Create" form is not shown even when subnetpool is selected as "Address Source"
I was wrong. When I select a subnet pool, I can now see "Network Mask" field. It is the expected behavior. ** Changed in: horizon Status: New => Invalid ** Tags removed: queens-backport-potential ** Changed in: horizon Milestone: rocky-1 => None ** Changed in: horizon Importance: Medium => Undecided -- 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/1757562 Title: "Network Mask" field in "Subnet Create" form is not shown even when subnetpool is selected as "Address Source" Status in OpenStack Dashboard (Horizon): Invalid Bug description: 1. Open "Subnet Create" form or "Network Create" form 2. Go to the "Subnet" tab 3. Select "Allocate Network Address from a pool" as "Network Address Source" [Expected] "Network Mask" field should be specified. [Actual] "Network Mask" field is not shown. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1757562/+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 1752152] Re: Attach Volume Fails with secure call to cinder
I think we can mark this as invalid for cinderclient as there isn't
anything we can backport and require with a new minimum version on
stable branches for cinderclient, so nova likely has to solve this
alone.
** Changed in: python-cinderclient
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/1752152
Title:
Attach Volume Fails with secure call to cinder
Status in OpenStack Compute (nova):
Triaged
Status in OpenStack Compute (nova) pike series:
Triaged
Status in OpenStack Compute (nova) queens series:
Triaged
Status in python-cinderclient:
Invalid
Bug description:
It is found that when cinder endpoint is configured to use https,
attach volume flow fails with the stack trace seen below (seen in nova
api log) because it fails to make a secure call from nova to cinder.
Secure calls perform certificate validation and in this particular
flow, certificate validation is completely skipped
File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 3971, in
attach_volume
2018-02-27 08:16:51.338 1324 ERROR
cinder.is_microversion_supported(context, '3.44')
2018-02-27 08:16:51.338 1324 ERRORFile
"/usr/lib/python2.7/site-packages/nova/volume/cinder.py", line 138, in
is_microversion_supported
2018-02-27 08:16:51.338 1324 ERROR _check_microversion(url, microversion)
2018-02-27 08:16:51.338 1324 ERRORFile
"/usr/lib/python2.7/site-packages/nova/volume/cinder.py", line 86, in
_check_microversion
2018-02-27 08:16:51.338 1324 ERROR max_api_version =
cinder_client.get_highest_client_server_version(url)
2018-02-27 08:16:51.338 1324 ERRORFile
"/usr/lib/python2.7/site-packages/cinderclient/client.py", line 126, in
get_highest_client_server_version
2018-02-27 08:16:51.338 1324 ERROR min_server, max_server =
get_server_version(url)
2018-02-27 08:16:51.338 1324 ERRORFile
"/usr/lib/python2.7/site-packages/cinderclient/client.py", line 109, in
get_server_version
2018-02-27 08:16:51.338 1324 ERROR response = requests.get(version_url)
2018-02-27 08:16:51.338 1324 ERRORFile
"/usr/lib/python2.7/site-packages/requests/api.py", line 72, in get
2018-02-27 08:16:51.338 1324 ERROR return request('get', url,
params=params, **kwargs)
2018-02-27 08:16:51.338 1324 ERRORFile
"/usr/lib/python2.7/site-packages/requests/api.py", line 58, in request
2018-02-27 08:16:51.338 1324 ERROR return session.request(method=method,
url=url, **kwargs)
2018-02-27 08:16:51.338 1324 ERRORFile
"/usr/lib/python2.7/site-packages/requests/sessions.py", line 502, in request
2018-02-27 08:16:51.338 1324 ERROR resp = self.send(prep, **send_kwargs)
2018-02-27 08:16:51.338 1324 ERRORFile
"/usr/lib/python2.7/site-packages/requests/sessions.py", line 612, in send
2018-02-27 08:16:51.338 1324 ERROR r = adapter.send(request, **kwargs)
2018-02-27 08:16:51.338 1324 ERRORFile
"/usr/lib/python2.7/site-packages/requests/adapters.py", line 504, in send
2018-02-27 08:16:51.338 1324 ERROR raise ConnectionError(e,
request=request)
2018-02-27 08:16:51.338 1324 ERROR ConnectionError:
HTTPSConnectionPool(host='ip9-114-192-132.pok.stglabs.ibm.com', port=9000): Max
retries exceeded with url: / (Caused by SSLError(SSLError("bad handshake:
Error([('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify
failed')],)",),))
This is a regression bug introduced as part of changeset
https://review.openstack.org/#/c/469579/, which was merged way back in
June 2017. As part of this changeset, a new function namely
_check_microversion was introduced, which then makes a cinderclient
call , which finally makes a cinder https REST api call without
passing the certificate. This leads to the problem listed above.
https://github.com/openstack/nova/blob/stable/queens/nova/volume/cinder.py#L75
https://github.com/openstack/nova/blob/stable/queens/nova/volume/cinder.py#L86
https://github.com/openstack/python-cinderclient/blob/stable/queens/cinderclient/client.py#L126
https://github.com/openstack/python-cinderclient/blob/stable/queens/cinderclient/client.py#L109
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1752152/+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 1289565] Re: required field asterisk missing
Extra Spec form was reimplemented. The current "Update Metadata" form has no issue described here. ** Changed in: horizon Status: New => Invalid -- 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/1289565 Title: required field asterisk missing Status in OpenStack Dashboard (Horizon): Invalid Bug description: Admin > Flavors > View Extra Specs > Create "Key" field is missing the asterisk. It will give the "This field is required" error if you try to 'Create'. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1289565/+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 1752152] Re: Attach Volume Fails with secure call to cinder
** Also affects: nova/pike
Importance: Undecided
Status: New
** Also affects: nova/queens
Importance: Undecided
Status: New
** Changed in: nova
Status: New => Triaged
** Changed in: nova/queens
Status: New => Triaged
** Changed in: nova/pike
Status: New => 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/1752152
Title:
Attach Volume Fails with secure call to cinder
Status in OpenStack Compute (nova):
Triaged
Status in OpenStack Compute (nova) pike series:
Triaged
Status in OpenStack Compute (nova) queens series:
Triaged
Status in python-cinderclient:
New
Bug description:
It is found that when cinder endpoint is configured to use https,
attach volume flow fails with the stack trace seen below (seen in nova
api log) because it fails to make a secure call from nova to cinder.
Secure calls perform certificate validation and in this particular
flow, certificate validation is completely skipped
File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 3971, in
attach_volume
2018-02-27 08:16:51.338 1324 ERROR
cinder.is_microversion_supported(context, '3.44')
2018-02-27 08:16:51.338 1324 ERRORFile
"/usr/lib/python2.7/site-packages/nova/volume/cinder.py", line 138, in
is_microversion_supported
2018-02-27 08:16:51.338 1324 ERROR _check_microversion(url, microversion)
2018-02-27 08:16:51.338 1324 ERRORFile
"/usr/lib/python2.7/site-packages/nova/volume/cinder.py", line 86, in
_check_microversion
2018-02-27 08:16:51.338 1324 ERROR max_api_version =
cinder_client.get_highest_client_server_version(url)
2018-02-27 08:16:51.338 1324 ERRORFile
"/usr/lib/python2.7/site-packages/cinderclient/client.py", line 126, in
get_highest_client_server_version
2018-02-27 08:16:51.338 1324 ERROR min_server, max_server =
get_server_version(url)
2018-02-27 08:16:51.338 1324 ERRORFile
"/usr/lib/python2.7/site-packages/cinderclient/client.py", line 109, in
get_server_version
2018-02-27 08:16:51.338 1324 ERROR response = requests.get(version_url)
2018-02-27 08:16:51.338 1324 ERRORFile
"/usr/lib/python2.7/site-packages/requests/api.py", line 72, in get
2018-02-27 08:16:51.338 1324 ERROR return request('get', url,
params=params, **kwargs)
2018-02-27 08:16:51.338 1324 ERRORFile
"/usr/lib/python2.7/site-packages/requests/api.py", line 58, in request
2018-02-27 08:16:51.338 1324 ERROR return session.request(method=method,
url=url, **kwargs)
2018-02-27 08:16:51.338 1324 ERRORFile
"/usr/lib/python2.7/site-packages/requests/sessions.py", line 502, in request
2018-02-27 08:16:51.338 1324 ERROR resp = self.send(prep, **send_kwargs)
2018-02-27 08:16:51.338 1324 ERRORFile
"/usr/lib/python2.7/site-packages/requests/sessions.py", line 612, in send
2018-02-27 08:16:51.338 1324 ERROR r = adapter.send(request, **kwargs)
2018-02-27 08:16:51.338 1324 ERRORFile
"/usr/lib/python2.7/site-packages/requests/adapters.py", line 504, in send
2018-02-27 08:16:51.338 1324 ERROR raise ConnectionError(e,
request=request)
2018-02-27 08:16:51.338 1324 ERROR ConnectionError:
HTTPSConnectionPool(host='ip9-114-192-132.pok.stglabs.ibm.com', port=9000): Max
retries exceeded with url: / (Caused by SSLError(SSLError("bad handshake:
Error([('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify
failed')],)",),))
This is a regression bug introduced as part of changeset
https://review.openstack.org/#/c/469579/, which was merged way back in
June 2017. As part of this changeset, a new function namely
_check_microversion was introduced, which then makes a cinderclient
call , which finally makes a cinder https REST api call without
passing the certificate. This leads to the problem listed above.
https://github.com/openstack/nova/blob/stable/queens/nova/volume/cinder.py#L75
https://github.com/openstack/nova/blob/stable/queens/nova/volume/cinder.py#L86
https://github.com/openstack/python-cinderclient/blob/stable/queens/cinderclient/client.py#L126
https://github.com/openstack/python-cinderclient/blob/stable/queens/cinderclient/client.py#L109
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1752152/+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 1485578] Re: It is not possible to select AZ for new Cinder volume during the VM creation
Comment #5 is exactly correct. You can't tell nova which cinder AZ to create a volume in if nova is creating the volume. If you need a specific AZ for the volume, you need to pre-create the volume in cinder and then provide that volume to nova during the server create request. It's the same issue with using a non-default volume type, you'd have to pre-create a volume and provide it to nova in that case. ** 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/1485578 Title: It is not possible to select AZ for new Cinder volume during the VM creation Status in OpenStack Dashboard (Horizon): Confirmed Status in OpenStack Compute (nova): Invalid Bug description: Steps To Reproduce: 1. Deploy OpenStack cluster with several Nova availability zones, for example, 'nova1' and 'nova2' and with several Cinder availability zones, for example, 'storage1' and 'storage2' (availability zones for Nova and Cinder should be different). 2. Login to Horizon dashboard and navigate to Project > Instances 3. Click on 'Launch Instance' button 4. Set all required parameters, select Nova AZ 'nova1' for new VM and select Instance Boot Source = "Boot from image (creates new volume)" 5. Click on 'Launch' button Observed Result: Instance will fail with "Failure prepping block device" error (please see attached screenshot horizon_az_bug.png) Expected Result: As a user I expect that Horizon UI will provide me the ability to select the availability zone for new volume if I want to create new volume and boot VM from it. We can't use Nova AZ as availability zone for Cinder volume because these zones are different availability zones (we can have, for example, 1 Nova availability zones and many Cinder availability zone or one Cinder AZ and many Nova AZs - it depends on users needs). To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1485578/+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 1752210] Re: Counter A ERROR when nova creates instance
Do you have the [neutron] section of nova.conf configured in your nova- api service? It's failing to get a token from keystone to talk to neutron, which likely means you have a misconfiguration. ** 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/1752210 Title: Counter A ERROR when nova creates instance Status in OpenStack Compute (nova): Invalid Bug description: [root@controller0 ~]# . demo-openrc [root@controller0 ~]# openstack server create --flavor m1.tiny --image 2af953de-058a-49a9-825d-781d220cd6eb --nic net-id=69d9c6d9-7716-45f1-a8d8-8988b59440af --security-group default demo-instance Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. (HTTP 500) (Request-ID: req-4de93f56-1506-401e-a602-9fa5aa162824) [root@controller0 ~]# tail -n 50 /var/log/nova/nova-api.log |grep ERROR 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions [req-4de93f56-1506-401e-a602-9fa5aa162824 d3eedc4b1e0348f0865b6a8052f75bd1 1ec04ee805f24681a6a37cf0b6e52970 - - -] Unexpected exception in API method 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions Traceback (most recent call last): 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/api/openstack/extensions.py", line 478, in wrapped 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions return f(*args, **kwargs) 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 73, in wrapper 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions return func(*args, **kwargs) 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 73, in wrapper 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions return func(*args, **kwargs) 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/api/openstack/compute/servers.py", line 611, in create 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions **create_kwargs) 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/hooks.py", line 149, in inner 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions rv = f(*args, **kwargs) 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 1587, in create 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions check_server_group_quota=check_server_group_quota) 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 1187, in _create_instance 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions auto_disk_config, reservation_id, max_count) 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 961, in _validate_and_build_base_options 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions pci_request_info, requested_networks) 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 1092, in create_pci_requests_for_sriov_ports 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions neutron = get_client(context, admin=True) 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 237, in get_client 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions auth_token = _ADMIN_AUTH.get_token(_SESSION) 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/keystoneclient/auth/identity/base.py", line 200, in get_token 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions return self.get_access(session).auth_token 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/keystoneclient/auth/identity/base.py", line 240, in get_access 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions self.auth_ref = self.get_auth_ref(session) 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/keystoneclient/auth/identity/v2.py", line 88, in get_auth_ref 2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions authenticated=False, log=False) 2018-02-27 20:50:57.551 1598 ERROR nova.api.ope
[Yahoo-eng-team] [Bug 1757562] [NEW] "Network Mask" field in "Subnet Create" form is not shown even when subnetpool is selected as "Address Source"
Public bug reported: 1. Open "Subnet Create" form or "Network Create" form 2. Go to the "Subnet" tab 3. Select "Allocate Network Address from a pool" as "Network Address Source" [Expected] "Network Mask" field should be specified. [Actual] "Network Mask" field is not shown. ** Affects: horizon Importance: Medium Status: New ** Tags: queens-backport-potential ** Tags added: queens-backport-potential ** Changed in: horizon Importance: Undecided => Medium ** Changed in: horizon Milestone: None => rocky-1 -- 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/1757562 Title: "Network Mask" field in "Subnet Create" form is not shown even when subnetpool is selected as "Address Source" Status in OpenStack Dashboard (Horizon): New Bug description: 1. Open "Subnet Create" form or "Network Create" form 2. Go to the "Subnet" tab 3. Select "Allocate Network Address from a pool" as "Network Address Source" [Expected] "Network Mask" field should be specified. [Actual] "Network Mask" field is not shown. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1757562/+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 1754543] Re: not update request_spec.request_networks after attach or detach interface
The request spec is to track the initial server create request, not to
be a complete mirror of everything that has ever happened to the
instance, like when volumes and ports are attached to it.
I don't see how this is a bug - what end-user issue do you have as a
result of this?
** 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/1754543
Title:
not update request_spec.request_networks after attach or detach
interface
Status in OpenStack Compute (nova):
Invalid
Bug description:
i attach a port to vm ,but request_spec.request_networks did not
update. port_id of request_spec.request_networks is null.
"request_networks": {
"nova_object.version": "1.1",
"nova_object.changes": ["objects"],
"nova_object.name": "NetworkRequestList",
"nova_object.data": {
"objects": [{
"nova_object.version": "1.2",
"nova_object.changes": ["network_id",
"pci_request_id", "tag", "port_id", "address"],
"nova_object.name": "NetworkRequest",
"nova_object.data": {
"network_id":
"90ba0584-b2b7-4f6a-b862-f77864d8626f",
"pci_request_id": null,
"tag": null,
"port_id": null,
"address": null
},
"nova_object.namespace": "nova"
}]
},
"nova_object.namespace": "nova"
},
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1754543/+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 1754782] Re: we skip critical scheduler filters when forcing the host on instance boot
** Changed in: nova Status: New => Opinion -- 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/1754782 Title: we skip critical scheduler filters when forcing the host on instance boot Status in OpenStack Compute (nova): Opinion Bug description: When booting an instance it's possible to force it to be placed on a specific host using the "--availability-zone nova:host" syntax. If you do this, the code at https://github.com/openstack/nova/blob/master/nova/scheduler/host_manager.py#L581 will return early rather than call self.filter_handler.get_filtered_objects() Based on discussions at the PTG with Dan Smith, the simplest solution would be to create a flag similar to RUN_ON_REBUILD which would be applied to the various scheduler filters in a manner analogous to how rebuild is handled now. Presumably we'd want to call something like this during the instance boot code to ensure we hit the existing "if not check_type" at L581: request_spec.scheduler_hints['_nova_check_type'] = ['build'] Then in the various critical filers (NUMATopologyFilter for example, and PciPassthroughFilter, and maybe some others like ComputeFilter) we could define something like "RUN_ON_BUILD = True" to ensure that they run even when forcing a host. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1754782/+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 1754661] Re: Unexpected API Error.
This doesn't make any sense if you're using neutron, but it's obviously trying to use nova-network for some reason. Check our your deployment config and setup. ** 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/1754661 Title: Unexpected API Error. Status in OpenStack Compute (nova): Invalid Bug description: launching an instance in openstack newton = openstack server create --flavor m1.tiny --image cirros --nic net-id=8c1fa730-fe35-4e01-a0cf-774c1f417df3 --security-group default selfservice-instance error== Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. (HTTP 500) (Request-ID: req-3b5ca259-0c97-4dac-bec2-1b19876108cf) nova-api-log== 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 73, in wrapper 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions return func(*args, **kwargs) 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 73, in wrapper 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions return func(*args, **kwargs) 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/api/openstack/compute/servers.py", line 631, in create 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions **create_kwargs) 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/hooks.py", line 154, in inner 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions rv = f(*args, **kwargs) 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 1535, in create 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions check_server_group_quota=check_server_group_quota) 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 1128, in _create_instance 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions reservation_id, max_count) 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 824, in _validate_and_build_base_options 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions requested_networks, max_count) 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 439, in _check_requested_networks 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions max_count) 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/network/api.py", line 391, in validate_networks 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions requested_networks) 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/network/rpcapi.py", line 214, in validate_networks 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions return self.client.call(ctxt, 'validate_networks', networks=networks) 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/client.py", line 428, in call 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions return self.prepare().call(ctxt, method, **kwargs) 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/client.py", line 169, in call 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions retry=self.retry) 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/oslo_messaging/transport.py", line 97, in _send 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions timeout=timeout, retry=retry) 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 584, in send 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions retry=retry) 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 573, in _send 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack.extensions result = self._waiter.wait(msg_id, timeout) 2018-03-09 13:32:31.663 28121 ERROR nova.api.openstack
[Yahoo-eng-team] [Bug 1756083] Re: clout init error when running native scripts at start up
Your scripts look like they are calling 'cloud-init collect' and not
'cloud-init collect-logs'
collect is not a valid command
/usr/bin/cloud-init: error: argument subcommand: invalid choice: 'collect'
(choose from 'init', 'modules', 'single', 'dhclient-hook', 'features',
'analyze', 'devel', 'collect-logs', 'clean', 'status')
** Changed in: cloud-init
Status: New => 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/1756083
Title:
clout init error when running native scripts at start up
Status in cloud-init:
Invalid
Bug description:
AWS AMI ubuntu/images/hvm-ssd/ubuntu-xenial-16.04-amd64-server-*
ubuntu@ip-10-90-130-11:~$ cloud-init collect
usage: /usr/bin/cloud-init [-h] [--version] [--file FILES] [--debug] [--force]
{init,modules,single,dhclient-hook,features,analyze,devel,collect-logs,clean,status}
...
/usr/bin/cloud-init: error: argument subcommand: invalid choice: 'collect'
(choose from 'init', 'modules', 'single', 'dhclient-hook', 'features',
'analyze', 'devel', 'collect-logs', 'clean', 'status')
When cloud init runs and hits my native scripts it err and there is no
Reason, Stdout or Stderr.
These scripts are preforming some string replaces for config files
using 'sed'/
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1756083/+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 1552777] Re: resizing from flavor with swap to one without swap puts instance into Error status
** 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/1552777 Title: resizing from flavor with swap to one without swap puts instance into Error status Status in OpenStack Compute (nova): Fix Released Bug description: In a single-node devstack (current trunk, nova commit 6e1051b7), if you boot an instance with a flavor that has nonzero swap and then resize to a flavor with zero swap it causes an exception. It seems that we somehow neglect to remove the swap file from the instance. 2016-03-03 10:02:41.415 ERROR nova.virt.libvirt.guest [req-dadee404-81c4-46de-9fd5-58de747b3b78 admin alt_demo] Error launching a defined domain with XML: instance-0001 54711b56-fa72-4eac-a5d3-aa29ed128098 http://openstack.org/xmlns/libvirt/nova/1.0";> asdf 2016-03-03 16:02:39 512 1 0 0 1 admin alt_demo 524288 524288 1 1024 OpenStack Foundation OpenStack Nova 13.0.0 03000200-0400-0500-0006-000700080009 54711b56-fa72-4eac-a5d3-aa29ed128098 Virtual Machine hvm /opt/stack/data/nova/instances/54711b56-fa72-4eac-a5d3-aa29ed128098/kernel /opt/stack/data/nova/instances/54711b56-fa72-4eac-a5d3-aa29ed128098/ramdisk root=/dev/vda console=tty0 console=ttyS0 destroy restart destroy /usr/bin/kvm-spice 2016-03-03 10:02:41.417 ERROR nova.compute.manager [req-dadee404-81c4-46de-9fd5-58de747b3b78 admin alt_demo] [instance: 54711b56-fa72-4eac-a5d3-aa29ed128098] Setting instance vm_state to ERROR 2016-03-03 10:02:41.417 TRACE nova.compute.manager [instance: 54711b56-fa72-4eac-a5d3-aa29ed128098] Traceback (most recent call last): 2016-03-03 10:02:41.417 TRACE nova.compute.manager [instance: 54711b56-fa72-4eac-a5d3-aa29ed128098] File "/opt/stack/nova/nova/compute/manager.py", line 3999, in finish_resize 2016-03-03 10:02:41.417 TRACE nova.compute.manager [instance: 54711b56-fa72-4eac-a5d3-aa29ed128098] disk_info, image_meta) 2016-03-03 10:02:41.417 TRACE nova.compute.manager [instance: 54711b56-fa72-4eac-a5d3-aa29ed128098] File "/opt/stack/nova/nova/compute/manager.py", line 3964, in _finish_resize 2016-03-03 10:02:41.417 TRACE nova.compute.manager [instance: 54711b56-fa72-4eac-a5d3-aa29ed128098] old_instance_type) 2016-03-03 10:02:41.417 TRACE nova.compute.manager [instance: 54711b56-fa72-4eac-a5d3-aa29ed128098] File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 204, in __exit__ 2016-03-03 10:02:41.417 TRACE nova.compute.manager [instance: 54711b56-fa72-4eac-a5d3-aa29ed128098] six.reraise(self.type_, self.value, self.tb) 2016-03-03 10:02:41.417 TRACE nova.compute.manager [instance: 54711b56-fa72-4eac-a5d3-aa29ed128098] File "/opt/stack/nova/nova/compute/manager.py", line 3959, in _finish_resize 2016-03-03 10:02:41.417 TRACE nova.compute.manager [instance: 54711b56-fa72-4eac-a5d3-aa29ed128098] block_device_info, power_on) 2016-03-03 10:02:41.417 TRACE nova.compute.manager [instance: 54711b56-fa72-4eac-a5d3-aa29ed128098] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 7202, in finish_migration 2016-03-03 10:02:41.417 TRACE nova.compute.manager [instance: 54711b56-fa72-4eac-a5d3-aa29ed128098] vifs_already_plugged=True) 2016-03-03 10:02:41.417 TRACE nova.compute.manager [instance: 54711b56-fa72-4eac-a5d3-aa29ed128098] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 4862, in _create_domain_and_network 2016-03-03 10:02:41.417 TRACE nova.compute.manager [instance: 54711b56-fa72-4eac-a5d3-aa29ed128098] xml, pause=pause, power_on=power_on) 2016-03-03 10:02:41.417 TRACE nova.compute.manager [instance: 54711b56-fa72-4eac-a5d3-aa29ed128098] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 4793, in _create_domain 2016-03-03 10:02:41.417 TRACE nova.compute.manager [instance: 54711b56-fa72-4eac-a5d3-aa29ed128098] guest.launch(pause=pause) 2016-03-03 10:02:41.417 TRACE nova.compute.manager [instance: 54711b56-fa72-4eac-a5d3-aa29ed128098]
[Yahoo-eng-team] [Bug 1755683] Re: RequestSpec object has only one instance_uuid
Clearly we support creating multiple instances in the same request using
the anti-affinity server group policy and in fact that's the only
reliable way to make sure the scheduler puts them on separate hosts.
So it works, but maybe not how you'd expect. This is the code I'm aware
of that consumers the server group member on the given host after the
filter runs:
https://github.com/openstack/nova/blob/2ec8c49f6cb4a0e7dba217e824c20d9c703d2105/nova/scheduler/filter_scheduler.py#L326
Are you actually hitting some kind of error? If so, please re-phrase
this bug using the end-user workflow of what you're trying to do via the
API and what doesn't work.
If you're trying to hack the GroupAntiAffinityFilter to add your own
code, then this isn't a bug.
** Tags added: scheduler
** 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/1755683
Title:
RequestSpec object has only one instance_uuid
Status in OpenStack Compute (nova):
Invalid
Bug description:
OpenStack Pike.
I create more than one instances on the dashboard. The nova-scheduler will
revice a argument named spec_obj.
select_destinations(self, ctxt,request_spec=None,
filter_properties=None,spec_obj=_sentinel, instance_uuids=None)
spec_obj has a attribute named instance_uuid, the attribute will be
used in GroupAntiAffinityFilter class.
class _GroupAntiAffinityFilter(filters.BaseHostFilter):
"""Schedule the instance on a different host from a set of group
hosts.
"""
RUN_ON_REBUILD = False
def host_passes(self, host_state, spec_obj):
# Only invoke the filter if 'anti-affinity' is configured
policies = (spec_obj.instance_group.policies
if spec_obj.instance_group else [])
if self.policy_name not in policies:
return True
# NOTE(hanrong): Move operations like resize can check the same source
# compute node where the instance is. That case, AntiAffinityFilter
# must not return the source as a non-possible destination.
if spec_obj.instance_uuid in host_state.instances.keys():
return True
group_hosts = (spec_obj.instance_group.hosts
if spec_obj.instance_group else [])
LOG.debug("Group anti affinity: check if %(host)s not "
"in %(configured)s", {'host': host_state.host,
'configured': group_hosts})
if group_hosts:
return host_state.host not in group_hosts
# No groups configured
return True
When I create more than one instances, spec_obj.instance_uuid is
always the same.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1755683/+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 1756845] Re: Queens Devstack instance creation failure "Error: Exceeded maximum number of retries. Exhausted all hosts available for retrying build failures for instance 833e1bf6
*** This bug is a duplicate of bug 1749972 *** https://bugs.launchpad.net/bugs/1749972 Failure during vif plug is this: "set ageing time failed: Numerical result out of range" Failure running os_vif plugin plug method: Failed to plug VIF VIFBridge(active=False,address=fa:16:3e:0a:69:57,bridge_name='qbr41533537-1b',has_traffic_filtering=True,id=41533537-1b6c-4b64-8eff-2c05d281a564,network=Network(9148e3c5-5a24-4ef5-a569-ec7f1301759b),plugin='ovs',port_profile=VIFPortProfileOpenVSwitch,preserve_on_delete=False,vif_name='tap41533537-1b'). Got error: Unexpected error while running command. Mar 19 06:29:33 stack nova-compute[6834]: Command: brctl setageing qbr41533537-1b 0 Mar 19 06:29:33 stack nova-compute[6834]: Exit code: 1 Mar 19 06:29:33 stack nova-compute[6834]: Stdout: u'' Mar 19 06:29:33 stack nova-compute[6834]: Stderr: u'set ageing time failed: Numerical result out of range\n' Sounds like it might be an environmental/kernel/host problem: https://askubuntu.com/questions/1003105/ubuntu-brctl-setageing-0-failed- on-fresh-install https://bugs.launchpad.net/os-vif/+bug/1749972 So looks like this is a duplicate of that bug. ** This bug has been marked a duplicate of bug 1749972 `brctl setageing $bridge 0` fails on Ubuntu 16.04 4.4.0-21-generic -- 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/1756845 Title: Queens Devstack instance creation failure "Error: Exceeded maximum number of retries. Exhausted all hosts available for retrying build failures for instance 833e1bf6-7ea8-413f-94b7-0c87528a8d0a" Status in OpenStack Compute (nova): New Bug description: Description === Devstack Queens cirros instance launch failed with the error "MaxRetriesExceeded: Exceeded maximum number of retries. Exhausted all hosts available for retrying build failures for instance 833e1bf6-7ea8-413f-94b7-0c87528a8d0a." Creation of Network, router.. all went well. Launch instance task failed. Steps to reproduce == Install Devstack from stable/queens branch and launch instance Environment === Ubuntu Server 16.04.4 LTS Devstack stable/queens stack@stack:/opt/devstack$ git log -1 commit bb0c101c0c7352b0fadf0e13d4c47f59437db454 Merge: 661b186 abe9fd8 Author: Zuul Date: Tue Mar 13 02:28:44 2018 + Merge "Cap max microversions for queens" into stable/queens Logs & Configs == nova-compute.log - Mar 19 06:29:32 stack nova-compute[6834]: #033[01;31mERROR os_vif [#033[01;36mNone req-3fb97b01-cbcd-4b95-ac44-87b6afa6ebab #033[00;36mservice nova#033[01;31m] #033[01;35m#033[01;31mFailed to plug vif VIFBridge(active=False,address=fa:16:3e:0a:69:57,bridge_name='qbr41533537-1b',has_traffic_filtering=True,id=41533537-1b6c-4b64-8eff-2c05d281a564,network=Network(9148e3c5-5a24-4ef5-a569-ec7f1301759b),plugin='ovs',port_profile=VIFPortProfileOpenVSwitch,preserve_on_delete=False,vif_name='tap41533537-1b')#033[00m: ProcessExecutionError: Unexpected error while running command. Mar 19 06:29:32 stack nova-compute[6834]: Command: brctl setageing qbr41533537-1b 0 Mar 19 06:29:32 stack nova-compute[6834]: Exit code: 1 Mar 19 06:29:32 stack nova-compute[6834]: Stdout: u'' Mar 19 06:29:32 stack nova-compute[6834]: Stderr: u'set ageing time failed: Numerical result out of range\n' Mar 19 06:29:32 stack nova-compute[6834]: ERROR os_vif #033[01;35m#033[00mTraceback (most recent call last): Mar 19 06:29:32 stack nova-compute[6834]: ERROR os_vif #033[01;35m#033[00m File "/usr/local/lib/python2.7/dist-packages/os_vif/__init__.py", line 77, in plug Mar 19 06:29:32 stack nova-compute[6834]: ERROR os_vif #033[01;35m#033[00m plugin.plug(vif, instance_info) Mar 19 06:29:32 stack nova-compute[6834]: ERROR os_vif #033[01;35m#033[00m File "/usr/local/lib/python2.7/dist-packages/vif_plug_ovs/ovs.py", line 209, in plug Mar 19 06:29:32 stack nova-compute[6834]: ERROR os_vif #033[01;35m#033[00m self._plug_bridge(vif, instance_info) Mar 19 06:29:32 stack nova-compute[6834]: ERROR os_vif #033[01;35m#033[00m File "/usr/local/lib/python2.7/dist-packages/vif_plug_ovs/ovs.py", line 161, in _plug_bridge Mar 19 06:29:32 stack nova-compute[6834]: ERROR os_vif #033[01;35m#033[00m linux_net.ensure_bridge(vif.bridge_name) Mar 19 06:29:32 stack nova-compute[6834]: ERROR os_vif #033[01;35m#033[00m File "/usr/local/lib/python2.7/dist-packages/oslo_privsep/priv_context.py", line 207, in _wrap Mar 19 06:29:32 stack nova-compute[6834]: ERROR os_vif #033[01;35m#033[00m return self.channel.remote_call(name, args, kwargs) Mar 19 06:29:32 stack nova-compute[6834]: ERROR os_vif #033[01;35m#033[00m File "/usr/local/lib/python2.7/dist-packages/oslo_privsep/daemon.py", line 202, in remote_call Mar 19 06:29:32 stack nova-compute[6834]: ERROR os_vif #033[01;35m#
[Yahoo-eng-team] [Bug 1746509] Re: TypeError: Can't upgrade a READER transaction to a WRITER mid-transaction
** This bug is no longer a duplicate of bug 1722404
Database transactions can fail with "TypeError: Can't upgrade a READER
transaction to a WRITER mid-transaction" because of scatter_gather_cells
** Tags added: cells
--
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/1746509
Title:
TypeError: Can't upgrade a READER transaction to a WRITER mid-
transaction
Status in OpenStack Compute (nova):
New
Bug description:
Hi, I was running OPenstack Newton with no nova_cell0 database and
placement-api setup . After migrate to Openstack Pike and correctly setup the
nova_cell0 and placement-api everything is working fine except the openstack
server list on tenant that already exist .
For example :
1. For a new tenant created after the migration at Pike.
nova --os-project-name="New Project" list
+--+-+++-+---+
| ID | Name| Status | Task
State | Power State | Networks |
+--+-+++-+---+
| c41c7e8d-4bc0-4a0f-a9d3-dc719ae2aff0 | SAMPLE_VM | ACTIVE | -
| Running | SAMPLE-SUBNET=192.168.0.8 |
| 3d3d3e10-f326-4a92-9253-1511e738d1cc | SECOND_INSTANCE | ACTIVE | -
| Running | SAMPLE-SUBNET=192.168.0.5 |
+--+-+++-+---+
2. For a old tenant created before the migration at Newton .
nova --os-project-name="InterCon" list
ERROR (ClientException): Unexpected API Error. Please report this at
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.
(HTTP 500) (Request-ID:
req-0dd4ef4d-54c2-4cfd-b8d9-636c5736ef5f)
And here the log related to this error .
2018-01-31 07:45:35.832 2340 DEBUG nova.compute.api
[req-254ac685-f218-4a23-8fa6-9c6a2d48bb07 45bd2d15e8534c469bf08b7db268e8d4
f80e111e5030457a872bee3a4c11ca70 - 8433db4810f947168950770f8c93a4f2
8433db4810f947168950770f8c93a4f2] Searching by: {'deleted': False} get_all
/usr/lib/python2.7/site-packages/nova/compute/api.py:2311
2018-01-31 07:45:35.837 2340 DEBUG oslo_concurrency.lockutils
[req-254ac685-f218-4a23-8fa6-9c6a2d48bb07 45bd2d15e8534c469bf08b7db268e8d4
f80e111e5030457a872bee3a4c11ca70 - 8433db4810f947168950770f8c93a4f2
8433db4810f947168950770f8c93a4f2] Lock "----"
acquired by "nova.context.get_or_set_cached_cell_and_set_connections" :: waited
0.000s inner /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:270
2018-01-31 07:45:35.837 2340 DEBUG oslo_concurrency.lockutils
[req-254ac685-f218-4a23-8fa6-9c6a2d48bb07 45bd2d15e8534c469bf08b7db268e8d4
f80e111e5030457a872bee3a4c11ca70 - 8433db4810f947168950770f8c93a4f2
8433db4810f947168950770f8c93a4f2] Lock "----"
released by "nova.context.get_or_set_cached_cell_and_set_connections" :: held
0.000s inner /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:282
2018-01-31 07:45:35.858 2340 DEBUG nova.compute.api
[req-254ac685-f218-4a23-8fa6-9c6a2d48bb07 45bd2d15e8534c469bf08b7db268e8d4
f80e111e5030457a872bee3a4c11ca70 - 8433db4810f947168950770f8c93a4f2
8433db4810f947168950770f8c93a4f2] Skipping already-collected cell0 list
_get_instances_by_filters_all_cells
/usr/lib/python2.7/site-packages/nova/compute/api.py:2503
2018-01-31 07:45:35.858 2340 DEBUG nova.compute.api
[req-254ac685-f218-4a23-8fa6-9c6a2d48bb07 45bd2d15e8534c469bf08b7db268e8d4
f80e111e5030457a872bee3a4c11ca70 - 8433db4810f947168950770f8c93a4f2
8433db4810f947168950770f8c93a4f2] Listing 1000 instances in cell
ea0a32fb-c148-4d4f-a42d-4e46356ff926 _get_instances_by_filters_all_cells
/usr/lib/python2.7/site-packages/nova/compute/api.py:2506
2018-01-31 07:45:35.859 2340 DEBUG oslo_concurrency.lockutils
[req-254ac685-f218-4a23-8fa6-9c6a2d48bb07 45bd2d15e8534c469bf08b7db268e8d4
f80e111e5030457a872bee3a4c11ca70 - 8433db4810f947168950770f8c93a4f2
8433db4810f947168950770f8c93a4f2] Lock "ea0a32fb-c148-4d4f-a42d-4e46356ff926"
acquired by "nova.context.get_or_set_cached_cell_and_set_connections" :: waited
0.000s inner /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:270
2018-01-31 07:45:35.859 2340 DEBUG oslo_concurrency.lockutils
[req-254ac685-f218-4a23-8fa6-9c6a2d48bb07 45bd2d15e8534c469bf08b7db268e8d4
f80e111e5030457a872bee3a4c11ca70 - 8433db4810f947168950770f8c93a4f2
8433db4810f947168950770f8c93a4f2] Lock "ea0a32fb-c148-4d4f-a42d-4e46356ff926"
released by "nova.context.get_or_set_cached_cell_and_set_connections" :: held
0.000s inner /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:282
2018-01-31 07:45:35.934 2340 DEBU
[Yahoo-eng-team] [Bug 1738379] Re: Install and configure for Ubuntu in horizon
This bug was fixed in the package horizon - 3:13.0.0-0ubuntu1
---
horizon (3:13.0.0-0ubuntu1) bionic; urgency=medium
* New upstream release for OpenStack Queens.
-- Corey Bryant Wed, 28 Feb 2018 14:23:55
-0500
** Changed in: horizon (Ubuntu)
Status: Fix Committed => 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/1738379
Title:
Install and configure for Ubuntu in horizon
Status in OpenStack Dashboard (Horizon):
Fix Released
Status in horizon package in Ubuntu:
Fix Released
Bug description:
horizon timeout at the browser; no obvious errors found on the logs
solution was adding "WSGIApplicationGroup %{GLOBAL}" to
/etc/apache2/conf-enabled/openstack-dashboard.conf
---
Release: 12.0.2.dev10 on 2017-12-13 21:58
SHA: 570460b0b6cb14fba360b0e5e1c28aaa2386ddd2
Source:
https://git.openstack.org/cgit/openstack/horizon/tree/doc/source/install/install-ubuntu.rst
URL: https://docs.openstack.org/horizon/pike/install/install-ubuntu.html
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1738379/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1757513] [NEW] standardattrdescription clobbers existing description API attr
Public bug reported: The commit [1] to use neutron-lib's segment API def surfaced an issue [2] whereupon the standardattrdescription's update of the 'description' attribute clobbers existing defs. For example the segment API def has a 'description' [3] allowing it to be set to 'None'. However the standardattrdescription overwrites that with its own description attribute [4] thereby causing [2]. This is the same reason for the hack in [5]. To me this behavior is odd in general; given an extension may already define its own description attr. A few fixes come to mind: - The standardattrdescription ext can filter out those that already define the 'description' in their API def. This isn't much code. - Extensions wanting to define a 'description' can remove themselves from the HasStandardAttributes (probably less than ideal) and just get it for free from standardattrdescription. I could probably do the work here, just looking for a consensus on direction. [1] https://review.openstack.org/#/c/552140 [2] http://logs.openstack.org/74/553374/2/check/osc-functional-devstack/6321b58/job-output.txt.gz#_2018-03-21_14_43_24_047175 [3] https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/segment.py#L97 [4] https://github.com/openstack/neutron/blob/master/neutron/extensions/standardattrdescription.py#L22 [5] https://review.openstack.org/#/c/552140/4/neutron/tests/unit/extensions/test_segment.py@83 ** Affects: neutron Importance: Undecided Status: New ** Tags: api -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1757513 Title: standardattrdescription clobbers existing description API attr Status in neutron: New Bug description: The commit [1] to use neutron-lib's segment API def surfaced an issue [2] whereupon the standardattrdescription's update of the 'description' attribute clobbers existing defs. For example the segment API def has a 'description' [3] allowing it to be set to 'None'. However the standardattrdescription overwrites that with its own description attribute [4] thereby causing [2]. This is the same reason for the hack in [5]. To me this behavior is odd in general; given an extension may already define its own description attr. A few fixes come to mind: - The standardattrdescription ext can filter out those that already define the 'description' in their API def. This isn't much code. - Extensions wanting to define a 'description' can remove themselves from the HasStandardAttributes (probably less than ideal) and just get it for free from standardattrdescription. I could probably do the work here, just looking for a consensus on direction. [1] https://review.openstack.org/#/c/552140 [2] http://logs.openstack.org/74/553374/2/check/osc-functional-devstack/6321b58/job-output.txt.gz#_2018-03-21_14_43_24_047175 [3] https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/segment.py#L97 [4] https://github.com/openstack/neutron/blob/master/neutron/extensions/standardattrdescription.py#L22 [5] https://review.openstack.org/#/c/552140/4/neutron/tests/unit/extensions/test_segment.py@83 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1757513/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1751385] Re: Primary project choices in AngularJS create user form is populated with keystone roles
It was fixed in https://review.openstack.org/#/c/535723/ as wei.ying commented. ** Changed in: horizon Status: In Progress => Fix Released ** Changed in: horizon Assignee: (unassigned) => Shu Muto (shu-mutou) -- 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/1751385 Title: Primary project choices in AngularJS create user form is populated with keystone roles Status in OpenStack Dashboard (Horizon): Fix Released Bug description: When I open Angular implementation of Create User form, the choices of "Primary Project" is filled with existing keystone roles. "Role" choices is empty. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1751385/+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 1757495] [NEW] Using dvr and centralized routers in same network fails
Public bug reported: Brief overview and reproducing steps: 1. Create tenant network, let's say 10.3.2.0/24. 2. Create centralized HA router. Attach it at 10.3.2.1 3. Boot VM and ping 10.3.2.1 - works. 4. Create distributed router. Attach it at any free IP, e.g. 10.3.2.5 5. Try to ping 10.3.2.1 from VM - fails. Ping 10.3.2.5 - works. I can reproduce this consistently. The setup might be a bit of a corner case: - deployment with openstack kolla. Openvswitch. - openstack pike. neutron 11.0.2 - tenant provider networks are vlan - there are 2 neutron nodes to host HA routers - all compute nodes configured for DVR No errors in logs. On the compute node hosting the VM, I can see dropped packages on integration bridge br-int. ** 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/1757495 Title: Using dvr and centralized routers in same network fails Status in neutron: New Bug description: Brief overview and reproducing steps: 1. Create tenant network, let's say 10.3.2.0/24. 2. Create centralized HA router. Attach it at 10.3.2.1 3. Boot VM and ping 10.3.2.1 - works. 4. Create distributed router. Attach it at any free IP, e.g. 10.3.2.5 5. Try to ping 10.3.2.1 from VM - fails. Ping 10.3.2.5 - works. I can reproduce this consistently. The setup might be a bit of a corner case: - deployment with openstack kolla. Openvswitch. - openstack pike. neutron 11.0.2 - tenant provider networks are vlan - there are 2 neutron nodes to host HA routers - all compute nodes configured for DVR No errors in logs. On the compute node hosting the VM, I can see dropped packages on integration bridge br-int. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1757495/+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 1735588] Re: Mock autospec not used, or not used properly
Reviewed: https://review.openstack.org/539954 Committed: https://git.openstack.org/cgit/openstack/compute-hyperv/commit/?id=d19606a82809f2a909d20b102166880b65d74b1f Submitter: Zuul Branch:master commit d19606a82809f2a909d20b102166880b65d74b1f Author: Claudiu Belu Date: Tue Jan 30 06:06:47 2018 -0800 autospecs os-win utils classes Most of the os-win utils are created through os_win.utilsfactory, which all rely on its function '_get_class' to load and initialize the proper Utils based on the OS version. This commit patches the mention method, returning an autospeced mock for the desired Utils instead. Closes-Bug: #1735588 Change-Id: If0002b2c711aaeaf13273bed9b912fdd9c639a64 ** Changed in: compute-hyperv 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/1735588 Title: Mock autospec not used, or not used properly Status in compute-hyperv: Fix Released Status in networking-hyperv: Fix Released Status in OpenStack Compute (nova): In Progress Status in os-win: Fix Released Status in oslotest: Fix Released Bug description: Description === In typical unit tests, almost all of the dependencies are mocked or patched (mock.patch), without any guarantee that the mocked methods actually exist, or if their signatures are respected (see below). Because of this, actual issues can easily be overlooked and missed, as the unit tests are wrongfully passing. [0] The mock.Mock class accepts a spec as an argument, which only solves half the problem: it only checks if an attribute exists, based on the given spec. It does not guarantee that the given attribute is actually a method, or if its signature is respected [1][2]. Some unit tests may pass the autospec argument, but mock doesn't support it at the moment. mock.patch, mock.patch.object, mock.patch.multiple accept an autospec argument, but because of a bug [3][4], it cannot be used properly. Steps to reproduce == import mock from mock.tests import testmock m = mock.Mock(spec=testmock.Something) # meth has the following signature: # def meth(self, a, b, c, d=None): m.meth() Expected result === TypeError should be raised. Actual result = A mock object is returned. Proposal Bug reports have been issues for the bugs mentioned above, see [1][2][3][4], but until then, the mock library can be patched to include the following changes: - add autospec argument to mock.Mock and mock.MagicMock. Unit test should then pass the autospec argument whenever possible. - fix the mock.patch autospec issue. - enable mock.patch autospec by default, unless otherwise specified. Links = [0] https://review.openstack.org/#/c/461689/ [1] https://github.com/testing-cabal/mock/issues/393 [2] https://bugs.python.org/issue30587 [3] https://github.com/testing-cabal/mock/issues/396 [4] https://bugs.python.org/issue32092 To manage notifications about this bug go to: https://bugs.launchpad.net/compute-hyperv/+bug/1735588/+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 1757482] [NEW] IP address for a router interface allowed outside the allocation range of subnet
Public bug reported: Currently running Queens on Ubuntu 16.04 with the linuxbridge ml2 plugin with vxlan overlays. We have a single, large provider network that we have set to 'shared' and 'external', so people who need to do things that don't work well with NAT can connect their instances directly to the provider network. Our 'allocation range' as defined in our provider subnet is dedicated to tenants, so there should be no conflicts. One of our users connected a neutron router to the provider network (not via the 'external network' option, but rather via the normal 'add interface' option) and neglected to specify an IP address. The neutron router decided that it was now the gateway for the entire provider network and began arp'ing. This seems like it should be disallowed inside of neutron (you shouldn't be able to specify an IP address for a router interface that isn't explicitly part of your allocation range on said subnet). Unless neutron just expect issues like this to be handled by the physical provider infrastructure (spoofing prevention, etc.)? ** Affects: neutron Importance: Undecided Status: New ** Tags: provider router ** Tags added: router ** Tags added: provider -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1757482 Title: IP address for a router interface allowed outside the allocation range of subnet Status in neutron: New Bug description: Currently running Queens on Ubuntu 16.04 with the linuxbridge ml2 plugin with vxlan overlays. We have a single, large provider network that we have set to 'shared' and 'external', so people who need to do things that don't work well with NAT can connect their instances directly to the provider network. Our 'allocation range' as defined in our provider subnet is dedicated to tenants, so there should be no conflicts. One of our users connected a neutron router to the provider network (not via the 'external network' option, but rather via the normal 'add interface' option) and neglected to specify an IP address. The neutron router decided that it was now the gateway for the entire provider network and began arp'ing. This seems like it should be disallowed inside of neutron (you shouldn't be able to specify an IP address for a router interface that isn't explicitly part of your allocation range on said subnet). Unless neutron just expect issues like this to be handled by the physical provider infrastructure (spoofing prevention, etc.)? To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1757482/+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 1750450] Re: ironic: n-cpu fails to recover after losing connection to ironic-api and placement-api
Reviewed: https://review.openstack.org/545479 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=acab8b0067b9ac90ed8c27daf04cfb4f926aa41a Submitter: Zuul Branch:master commit acab8b0067b9ac90ed8c27daf04cfb4f926aa41a Author: Jim Rollenhagen Date: Fri Mar 16 16:33:20 2018 + ironic: stop lying to the RT when ironic is down Returning an empty list of nodes can cause all sorts of crazy behavior, so we instead bubble up a VirtDriverNotReady exception, which the compute manager will ignore. Change-Id: Ib0ec1012b74e9a9e74c8879f3feed5f9332b711f Related-Bug: #1744139 Closes-Bug: #1750450 ** 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/1750450 Title: ironic: n-cpu fails to recover after losing connection to ironic-api and placement-api Status in OpenStack Compute (nova): Fix Released Bug description: The ironic virt driver does some crazy things when the ironic API goes down - it returns [] from get_available_nodes(). When the resource tracker sees this, it immediately attempts to delete all of the compute node records and resource providers for said nodes. If placement is also down at this time, the resource providers will not be properly deleted. When ironic-api and placement-api return, nova will see nodes, create compute_node records for them, and try to create new resource providers (as they are new compute_node records). This will fail with a name conflict, and the nodes will be unusable. This is easy to fix, by raising an exception in get_available_nodes, instead of lying to the resource tracker and returning []. However, this causes nova-compute to fail to start if ironic-api is not available. This may be fine but should have a larger discussion. We've added these hacks over the years for some reason, we should look at the bigger picture and decide how we want to handle these cases. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1750450/+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 1757472] [NEW] Required to define database/connection when running services for nova_api cell
Public bug reported: Services in nova_api cell fail to run if database/connection is not defined. These services should only use api_database/connection. In devstack database/connection is defined with the cell0 DB endpoint. This shouldn't be required because the cell0 is set in nova_api DB. ** Affects: nova Importance: Undecided Assignee: Surya Seetharaman (tssurya) 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/1757472 Title: Required to define database/connection when running services for nova_api cell Status in OpenStack Compute (nova): New Bug description: Services in nova_api cell fail to run if database/connection is not defined. These services should only use api_database/connection. In devstack database/connection is defined with the cell0 DB endpoint. This shouldn't be required because the cell0 is set in nova_api DB. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1757472/+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 1670628] Re: nova-compute will try to re-plug the vif even if it exists for vhostuser port.
** Also affects: os-vif Importance: Undecided Status: New ** No longer affects: nova ** Changed in: os-vif Status: New => Fix Committed ** Changed in: os-vif Importance: Undecided => High ** Changed in: os-vif Assignee: (unassigned) => sahid (sahid-ferdjaoui) ** Also affects: os-vif/pike Importance: Undecided Status: New ** Also affects: os-vif/queens Importance: Undecided Status: New ** Changed in: os-vif/pike Status: New => In Progress ** Changed in: os-vif/queens Status: New => In Progress ** Changed in: os-vif/pike Importance: Undecided => High ** Changed in: os-vif/queens Importance: Undecided => High ** Changed in: os-vif/pike Assignee: (unassigned) => sahid (sahid-ferdjaoui) ** Changed in: os-vif/queens Assignee: (unassigned) => sahid (sahid-ferdjaoui) -- 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/1670628 Title: nova-compute will try to re-plug the vif even if it exists for vhostuser port. Status in os-vif: Fix Committed Status in os-vif pike series: In Progress Status in os-vif queens series: In Progress Bug description: Description === In mitaka version, deploy neutron with ovs-dpdk. If we stop ovs-agent, then re-start the nova-compute,the vm in the host will get network connection failed. Steps to reproduce == deploy mitaka. with neutron, enabled ovs-dpdk, choose one compute node, where vm has network connection. run this in host, 1. #systemctl stop neutron-openvswitch-agent.service 2. #systemctl restart openstack-nova-compute.service then ping $VM_IN_THIS_HOST Expected result === ping $VM_IN_THIS_HOST would would success Actual result = ping $VM_IN_THIS_HOST failed. Environment === Centos7 ovs2.5.1 dpdk 2.2.0 openstack-nova-compute-13.1.1-1 Reason: after some digging, I found that nova-compute will try to plug the vif every time when it booting. Specially for vhostuser port, nova-compute will not check whether it exists as legacy ovs,and it will re-plug the port with vsctl args like "--if-exists del-port vhu". (refer https://github.com/openstack/nova/blob/stable/mitaka/nova/virt/libvirt/vif.py#L679-L683) after recreate the ovs vhostuser port, it will not get the right vlan tag which set from ovs agent. In the test environment, after restart the ovs agent, the agent will set a proper vlan id for the port. and the network connection will be resumed. Not sure it's a bug or config issue, do I miss something? there is also fp_plug type for vhostuser port, how could we specify it? To manage notifications about this bug go to: https://bugs.launchpad.net/os-vif/+bug/1670628/+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 1754634] Re: Image Import call does not honour enabled methods config option
** Also affects: glance/queens Importance: Undecided Status: New ** Changed in: glance/queens Status: New => In Progress ** Changed in: glance/queens Importance: Undecided => High ** Changed in: glance/queens Assignee: (unassigned) => Brian Rosmaita (brian-rosmaita) ** Changed in: glance/queens Importance: High => Critical -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1754634 Title: Image Import call does not honour enabled methods config option Status in Glance: Fix Released Status in Glance queens series: In Progress Bug description: Regardless what is configured import call will always accept all the methods. This means that for example one cannot turn 'web-download' method off if the image import feature is enabled. This can be easily corrected by changing the request de-serializer to check the method in the request against the config option rather than hardcoded list. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1754634/+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 1753550] Re: Status does not update to "Shutoff" when instance shuts down itself
Reviewed: https://review.openstack.org/554703 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=6482165bb1f44f5c98d9361153d737c22c92112d Submitter: Zuul Branch:master commit 6482165bb1f44f5c98d9361153d737c22c92112d Author: Matt Riedemann Date: Tue Mar 20 17:15:42 2018 -0400 Handle EndpointNotFound when building image_ref_url in notifications Change I4e755b9c66ec8bc3af0393e81cffd91c56064717 made the [glance]/api_servers option optional. If not set, we attempt to get the image service endpoint via keystoneauth adapter and the service catalog via the request context. Periodic tasks run without an actual token so there is no way to get the service catalog and the KSA adapter code to get the endpoint raises EndpointNotFound when trying to build the "image_ref_url" entry in the legacy instance notification payload. This change simply handles the EndpointNotFound and sets the image_ref_url to the instance.image_ref, which for non-volume-backed instances is the image id (for volume-backed instances it's an empty string). This doesn't affect versioned notifications since those don't use the "image_ref_url" entry in the payload that is created, they just have an "image_uuid" entry in the versioned notification payload which is populated via instance.image_ref. An upgrade impact release note is added in the case that some consuming service is actually relying on that legacy notification field being a URL and parsing it as such. The thinking here, however, is this is better than not sending the field at all, or setting it to None. Long-term this code all gets replaced with versioned notifications. Change-Id: Ie23a9c922776b028da0720c939846cba233ac472 Closes-Bug: #1753550 ** 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/1753550 Title: Status does not update to "Shutoff" when instance shuts down itself Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) queens series: Triaged Bug description: For instances that shut down themselves, the status remains Active, even though the power state updates to Shutdown. If however the shutdown signal is sent via openstack it does change the status to "SHUTOFF". After creating an instance, the states are: ++-+ | Field | Value | ++-+ | OS-EXT-STS:power_state | Running | | OS-EXT-STS:task_state | None| | OS-EXT-STS:vm_state| active | | status | ACTIVE | ++-+ Using openstack server stop results in: ++--+ | Field | Value| ++--+ | OS-EXT-STS:power_state | Shutdown | | OS-EXT-STS:task_state | None | | OS-EXT-STS:vm_state| stopped | | status | SHUTOFF | ++--+ However logging into the instance and using the poweroff command results in: ++--+ | Field | Value| ++--+ | OS-EXT-STS:power_state | Shutdown | | OS-EXT-STS:task_state | None | | OS-EXT-STS:vm_state| active | | status | ACTIVE | ++--+ This results in being unable to use the openstack server start command on it fails and returns: # openstack server start test_shutdown Cannot 'start' instance 8881bebb-efbd-45e6-a052-7d23b9b63222 while it is in vm_state active (HTTP 409) (Request-ID: req-e473415d-d6e0-4342-b1f6-267efa934dc0) despite the virtual machine being powered off. You can work around this by running openstack server stop, and then openstack server start. This is also an issue for external applications that check the status (and how I noticed it to begin with). This on devstack with commit id: 5d2add74534719c5670b29152964a60e8f23b42b Not sure if the following is useful, but - Using hypervisor libvirt+qemu/kvm: # virsh version Compiled against library: libvirt 3.2.0 Using library: libvirt 3.2.0 Using API: QEMU 3.2.0 Running hypervisor: QEMU 2.9.0 - Using ephemeral storage with ex4 - Neutron with OpenVSwitch To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1753550/+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 1757425] [NEW] Problem with Pip 9.0.2 and Ryu (dependency)
Public bug reported: Hello, While I was following kolla kubernetes guide for containerized Openstack I found a problem concerning Neutron and its dependency Ryu, while using new Pip version (9.0.2). I am creating this issue here because it may affect other users of Neutron. Please find more information on the issues I opened to Pip page and kolla-kubernetes launchpad. * https://bugs.launchpad.net/kolla-kubernetes/+bug/1757140 * https://github.com/pypa/pip/issues/5099 Kind regards. ** 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/1757425 Title: Problem with Pip 9.0.2 and Ryu (dependency) Status in neutron: New Bug description: Hello, While I was following kolla kubernetes guide for containerized Openstack I found a problem concerning Neutron and its dependency Ryu, while using new Pip version (9.0.2). I am creating this issue here because it may affect other users of Neutron. Please find more information on the issues I opened to Pip page and kolla-kubernetes launchpad. * https://bugs.launchpad.net/kolla-kubernetes/+bug/1757140 * https://github.com/pypa/pip/issues/5099 Kind regards. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1757425/+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 1757424] [NEW] allow hiding kvm signature as a flavor extra_spec
Public bug reported: This blueprint intends to add the capability of hiding the kvm signature from guests: https://blueprints.launchpad.net/nova/+spec/add-kvm-hidden-feature However, it is implemented only through an image property. A major reason for this feature is to allow passed-through Nvidia GPUs to work correctly. GPU pci-passthrough is specified on the flavor's extra_specs, without requiring an image with special properties. Therefore, hiding the KVM signature should also be specifiable through the flavor's extra_specs, in order to not require a special image for this use case. ** Affects: nova Importance: Undecided Status: New ** Tags: pci wishlist -- 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/1757424 Title: allow hiding kvm signature as a flavor extra_spec Status in OpenStack Compute (nova): New Bug description: This blueprint intends to add the capability of hiding the kvm signature from guests: https://blueprints.launchpad.net/nova/+spec/add-kvm-hidden-feature However, it is implemented only through an image property. A major reason for this feature is to allow passed-through Nvidia GPUs to work correctly. GPU pci-passthrough is specified on the flavor's extra_specs, without requiring an image with special properties. Therefore, hiding the KVM signature should also be specifiable through the flavor's extra_specs, in order to not require a special image for this use case. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1757424/+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 1757112] Re: wrong variable name in context_processors.py
Reviewed: https://review.openstack.org/554413 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=f588b4ee2e73c754a7565928c47552e159a1666d Submitter: Zuul Branch:master commit f588b4ee2e73c754a7565928c47552e159a1666d Author: Adrian Turjak Date: Tue Mar 20 17:55:52 2018 +1300 Fix wrong setting name for SHOW_KEYSTONE_V2_RC The user links patch didn't use the same setting variable name in context_processors.py, this fixes that. Closes-Bug: #1757112 Change-Id: Ie0e516d82c2c1cdc1c343075393cdf9c336f8e5f ** 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/1757112 Title: wrong variable name in context_processors.py Status in OpenStack Dashboard (Horizon): Fix Released Bug description: In the patch that added user menu links, the variable name for disabling v2 rc files was renamed by accident it seems in the context_processors.py module. https://github.com/openstack/horizon/commit/924239073ec8036265d13a3c6b09d6fa7865147f#diff-5a128d55603c030b687d1321df381ab0L100 vs https://github.com/openstack/horizon/commit/924239073ec8036265d13a3c6b09d6fa7865147f#diff-5a128d55603c030b687d1321df381ab0R91 Because of that the v2 download in the user dropdown wasn't being hidden correctly. The fix is easy. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1757112/+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 1734167] Re: DNS doesn't work in no-cloud as launched by ubuntu
This bug was fixed in the package systemd - 234-2ubuntu12.3 --- systemd (234-2ubuntu12.3) artful; urgency=medium [ Dimitri John Ledkov ] * Fix test-functions failing with Ubuntu units. LP: #1750608 * tests: switch to using ext4 by default, instead of ext3. LP: #1750608 * Fix kdump service not starting, due to systemd not loading dropins. Cherrypick a fix from upstream. (LP: #1708409) * systemd-fsckd: Fix ADT tests to work on s390x too. (LP: #1736955) * netwokrd: add support for RequiredForOnline stanza. (LP: #1737570) * resolved.service: set DefaultDependencies=no (LP: #1734167) * systemd.postinst: enable persistent journal. (LP: #1618188) * core: add support for non-writable unified cgroup hierarchy for container support. Rebase and de-fuzz. (LP: #1734410) * Prevent MemoryDenyWriteExecution policy bypass, by disallowing pkey_mprotect when mprotect is disallowed. CVE-2017-15908 (LP: #1725348) * networkd: enable promote_secondaries on networkd managed dhcp links. This fixes failing to renew DHCP lease, on networkd managed devices. (LP: #1721223) [ Kleber Sacilotto de Souza ] * systemd-rfkill service times out when a new rfkill device is added - rfkill-fix-erroneous-behavior-when-polling-the-udev-.patch: Comparing udev_device_get_sysname(device) and sysname will always return true. We need to check the device received from udev monitor instead. - rfkill-fix-typo.patch: Fix typo in rfkill log message. (LP: #1734908) -- Dimitri John Ledkov Tue, 20 Feb 2018 16:11:58 + ** Changed in: systemd (Ubuntu Artful) Status: Fix Committed => Fix Released ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-15908 -- 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/1734167 Title: DNS doesn't work in no-cloud as launched by ubuntu Status in cloud-init: Confirmed Status in cloud-init package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in cloud-init source package in Zesty: Fix Released Status in systemd source package in Zesty: Fix Released Status in cloud-init source package in Artful: Confirmed Status in systemd source package in Artful: Fix Released Status in systemd source package in Bionic: Fix Released Bug description: [Impact] * resolved does not start early enough in the boot-process preventing DNS resolution to be operational during early boot, for example as required by special early stages of cloud-init, resulting in failure to boot / provision the instance fully. [Test Case] * Boot container or a VM with a nocloud-net data source, and a URL pointing to the datasource as explained below * Observe that boot completes and provisioning is successful * Check that there are no dns-resolution errors in the cloud-init log / boot log [Regression Potential] * starting resolved earlier may prevent it from connecting to dbus, and may require a restart later on when re-triggered over dbus. This is on artful only, as in bionic resolved has gained ability to reconnected to dbus post-start. Backporting that, however, is too large for an SRU as it requires sd-bus changes. [Other Info] * Original bug report. I use no-cloud to test the kernel in CI (I am maintainer of the bcache subsystem), and have been running it successfully under 16.04 cloud images from qemu, using a qemu command that includes: -smbios "type=1,serial=ds=nocloud- net;s=https://raw.githubusercontent.com/mlyle/mlyle/master/cloud- metadata/linuxtst/" As documented here: http://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html Under the new 17.10 cloud images, this doesn't work: the network comes up, but name resolution doesn't work-- /etc/resolv.conf is a symlink to a nonexistent file at this point of the boot and systemd-resolved is not running. When I manually hack /etc/resolv.conf in the cloud image to point to 4.2.2.1 it works fine. I don't know if nameservice not working is by design, but it seems like it should work. The documentation states: "With ds=nocloud-net, the seedfrom value must start with http://, https:// or ftp://"; And https is not going to work for a raw IP address. Related bugs: * bug 1734939: #include fails silently. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1734167/+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 1757407] [NEW] Notification sending sometimes hits the keystone API to get glance endpoints
Public bug reported: During the investigation of another bug [1] we noticed that notification sending could trigger keystone API call if the glance/api_server config is not present in the nova.conf . The notification sending code paths[2][3] calls info_from_instance [4] that leads to the glance client get_api_servers function that falls back to keystone to get the endpoints if the above config is not present. The versioned notifications do not use the glance endpoint information. However even if the notifications/notification_format config options is set to versioned, nova still hits keystone via the instance.exists notification codepath [3] as that path is shared between versioned and unversioned notifications. This leads to an unnecessary REST API call where the result is not used so the caused performance loss is totally unnecessary. [1] https://bugs.launchpad.net/nova/+bug/1753550 [2] https://github.com/openstack/nova/blob/db0747591ce8df1b0ca62aac0648b7154fed1f86/nova/compute/utils.py#L305 [3] https://github.com/openstack/nova/blob/6eccfb7c01b7e984cb18c7b75bd20a589dfdfe3d/nova/notifications/base.py#L212 [4] https://github.com/openstack/nova/blob/6eccfb7c01b7e984cb18c7b75bd20a589dfdfe3d/nova/notifications/base.py#L381 [5] https://github.com/openstack/nova/blob/24379f1822e3ae1d4f7c8398e60af6e52b386c32/nova/image/glance.py#L126 ** Affects: nova Importance: Undecided Status: New ** Tags: notifications ** Tags added: notifications -- 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/1757407 Title: Notification sending sometimes hits the keystone API to get glance endpoints Status in OpenStack Compute (nova): New Bug description: During the investigation of another bug [1] we noticed that notification sending could trigger keystone API call if the glance/api_server config is not present in the nova.conf . The notification sending code paths[2][3] calls info_from_instance [4] that leads to the glance client get_api_servers function that falls back to keystone to get the endpoints if the above config is not present. The versioned notifications do not use the glance endpoint information. However even if the notifications/notification_format config options is set to versioned, nova still hits keystone via the instance.exists notification codepath [3] as that path is shared between versioned and unversioned notifications. This leads to an unnecessary REST API call where the result is not used so the caused performance loss is totally unnecessary. [1] https://bugs.launchpad.net/nova/+bug/1753550 [2] https://github.com/openstack/nova/blob/db0747591ce8df1b0ca62aac0648b7154fed1f86/nova/compute/utils.py#L305 [3] https://github.com/openstack/nova/blob/6eccfb7c01b7e984cb18c7b75bd20a589dfdfe3d/nova/notifications/base.py#L212 [4] https://github.com/openstack/nova/blob/6eccfb7c01b7e984cb18c7b75bd20a589dfdfe3d/nova/notifications/base.py#L381 [5] https://github.com/openstack/nova/blob/24379f1822e3ae1d4f7c8398e60af6e52b386c32/nova/image/glance.py#L126 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1757407/+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
