[Yahoo-eng-team] [Bug 1745873] Re: i18n: on subnet is hard to translate
Reviewed: https://review.openstack.org/538676 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=49fd528b7b814e8e8dab1fb238a79924fbf059b7 Submitter: Zuul Branch:master commit 49fd528b7b814e8e8dab1fb238a79924fbf059b7 Author: Akihiro Motoki Date: Mon Jan 29 05:45:00 2018 +0900 i18n: Allow translator to control the word order (trunk) " on subnet " format in "Parent Port" and "Subports" tabs in "Create Trunk" and "Edit Trunk" form did not allow translators to control the word order because only "on subnet" was marked as translation string and they are concatenated. This commit improves the translation string by using the "translate parameters" feature of Angular gettext. Also "on subnet" in the "Network Ports" tab of "Create Instance" workflow is now marked as translation string. Change-Id: I189897eee8037466ace2b68b8f9be3dc242c4252 Closes-Bug: #1745873 ** 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/1745873 Title: i18n: on subnet is hard to translate Status in OpenStack Dashboard (Horizon): Fix Released Bug description: In "Parent Port" and "Sub Ports" tabs of "Create Trunk" / "Edit Trunk" form, the "IP" column of the port table contains information of the format of " on subnet ", but it is difficult to translate considering the word order because only "on subnet" is marked as translation string. Also, " on subnet " in network ports" tab in the "Create Instance" workflow is not marked as translation string. Angular gettext supports "Translate parameters" feature [1]. By using this, we can support the word order in translation. [1] https://angular-gettext.rocketeer.be/dev-guide/translate-params/ To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1745873/+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 1736332] Re: Image verification returns 500 if invalid 'img_signature_certificate_uuid' is specified
Looks like there's nothing for Glance to do on this. Thanks for doing the research to track down the fix, Abhishek. ** Changed in: glance Status: New => Triaged ** Changed in: glance Importance: Undecided => Medium ** Changed in: glance Status: Triaged => Fix Released ** Changed in: glance Milestone: None => queens-3 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1736332 Title: Image verification returns 500 if invalid 'img_signature_certificate_uuid' is specified Status in Glance: Fix Released Bug description: If image signature verification is enabled then while creating the image if invalid (non-existing) 'img_signature_certificate_uuid' is specified then image creation fails and returns 500 internal server error to the user. The reason is it returns 'ManagedObjectNotFoundError: Key not found, uuid: ' which is not caught. Ideally it should return HTTP 400 bad request to the user. Pre-requisites: 1. Ensure Barbican is enabled 2. Create Keys and Certificate (Reference https://etherpad.openstack.org/p/mitaka-glance-image-signing-instructions#90) 3. Create Signature (Reference https://etherpad.openstack.org/p/mitaka-glance-image-signing-instructions#184) and note down output of 'signature_64' 4. Create context and upload certificate using context (Reference https://etherpad.openstack.org/p/glance-image-signing-create-context) and note down output of 'cert_uuid' Steps to reproduce: 1. Upload Image to Glance, with Signature Metadata img_signature_certificate_uuid = 'fb67edd2-95ef-404b-9af2-910708c6d9b7' (different than noted in Pre-requisites section Point 4) img_signature_hash_method = 'SHA-256' img_signature_key_type = 'RSA-PSS' img_signature = 'ezccBYtJEdj2gOrN09woioHwi2rDVvBsmRI0i+9EYAYdE7E6FV8jzJD9BImcq/m7Dm6yZZPkCUHz+y4HBKeYqK0+otcz921zaeqcKGBvU1t7J9AL0hEgJbWg0RY6RXqDXpsOQrrkrHuna4O+BUOp6sPwb3j2eFYbbsqW6d/obgM=' (Same which is noted in Pre-requisites section Point 4 as 'signature_64') $ glance image-create --property name=cirrosSignedImage_goodSignature --property is-public=true --container-format bare --disk-format qcow2 --property img_signature='ezccBYtJEdj2gOrN09woioHwi2rDVvBsmRI0i+9EYAYdE7E6FV8jzJD9BImcq/m7Dm6yZZPkCUHz+y4HBKeYqK0+otcz921zaeqcKGBvU1t7J9AL0hEgJbWg0RY6RXqDXpsOQrrkrHuna4O+BUOp6sPwb3j2eFYbbsqW6d/obgM=' --property img_signature_certificate_uuid='fb67edd2-95ef-404b- 9af2-910708c6d9b7' --property img_signature_hash_method='SHA-256' --property img_signature_key_type='RSA-PSS' --file cirros-0.3.2-source.tar.gz Actual Output: $ 500 Internal Server Error: The server has either erred or is incapable of performing the requested operation. (HTTP 500) Expected Output: $ 400 HTTP Bad Request: Secret incorrectly specified. (HTTP 400) NOTE: Image remains in queued status forever. ++--+ | Property | Value | ++--+ | checksum | None | | container_format | bare | | created_at | 2017-12-05T06:25:51Z | | disk_format| qcow2 | | id | c78598f5-23ac-46e8-8626-c908b5b830df | | img_signature | ezccBYtJEdj2gOrN09woioHwi2rDVvBsmRI0i+9EYAYdE7E6FV8jzJD9BImcq/m7Dm6yZZPkCUHz+y4H | || BKeYqK0+otcz921zaeqcKGBvU1t7J9AL0hEgJbWg0RY6RXqDXpsOQrrkrHuna4O+BUOp6sPwb3j2eFYb | || bsqW6d/obgM= | | img_signature_certificate_uuid | fb67edd2-95ef-404b-9af2-910708c6d9b9 | | img_signature_hash_method | SHA-256 | | img_signature_key_type | RSA-PSS | | is-public | true | | min_disk | 0 | | min_ram| 0
[Yahoo-eng-team] [Bug 1746404] [NEW] 'auto_associate_default_firewall_group' got an error when new port is created
Public bug reported:
If we create new port(binded somewhere) with following condition, an
Error occurred.
Jan 31 11:30:00 furukawa-verify-devstack neutron-server[25204]: DEBUG
neutron_fwaas.db.firewall.v2.firewall_db_v2 [None
req-f3c0994c-1547-410a-8bf8-b4b459e0dfba None None] get_firewall_group() called
{{(
pid=25213) get_firewall_group
/opt/stack/neutron-fwaas/neutron_fwaas/db/firewall/v2/firewall_db_v2.py:1080}}
Jan 31 11:30:00 furukawa-verify-devstack neutron-server[25204]: ERROR
neutron_lib.callbacks.manager [None req-f3c0994c-1547-410a-8bf8-b4b459e0dfba
None None] Error during notification for neutron_fwaas.s
ervices.firewall.fwaas_plugin_v2.FirewallPluginV2.handle_create_port_event--9223372036854763926
port, after_create: PortNotFound: Port c could not be found.
It was due to as follows:
1. Validation is missing that created port is for VM or not
2. It should be a list of port ID, but string of ID of port
[How to reproduce]
1. Deploy devstack with the latest with q-fwaas-v2
2. Configure following settings
(/etc/neutron/neutron_fwaas.conf)
[fwaas]
auto_associate_default_firewall_group = True
3. Restart q-svc
4. Run following command
$ neutron net-create test
$ neutron subnet-create test 11.11.11.0/24
Then, DHCP port will be created and an error occurred on q-svc. You can
see
$ sudo journalctl -f -u devstack@q-svc.service
** Affects: neutron
Importance: Undecided
Status: New
** Tags: fwaas
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1746404
Title:
'auto_associate_default_firewall_group' got an error when new port is
created
Status in neutron:
New
Bug description:
If we create new port(binded somewhere) with following condition, an
Error occurred.
Jan 31 11:30:00 furukawa-verify-devstack neutron-server[25204]: DEBUG
neutron_fwaas.db.firewall.v2.firewall_db_v2 [None
req-f3c0994c-1547-410a-8bf8-b4b459e0dfba None None] get_firewall_group() called
{{(
pid=25213) get_firewall_group
/opt/stack/neutron-fwaas/neutron_fwaas/db/firewall/v2/firewall_db_v2.py:1080}}
Jan 31 11:30:00 furukawa-verify-devstack neutron-server[25204]: ERROR
neutron_lib.callbacks.manager [None req-f3c0994c-1547-410a-8bf8-b4b459e0dfba
None None] Error during notification for neutron_fwaas.s
ervices.firewall.fwaas_plugin_v2.FirewallPluginV2.handle_create_port_event--9223372036854763926
port, after_create: PortNotFound: Port c could not be found.
It was due to as follows:
1. Validation is missing that created port is for VM or not
2. It should be a list of port ID, but string of ID of port
[How to reproduce]
1. Deploy devstack with the latest with q-fwaas-v2
2. Configure following settings
(/etc/neutron/neutron_fwaas.conf)
[fwaas]
auto_associate_default_firewall_group = True
3. Restart q-svc
4. Run following command
$ neutron net-create test
$ neutron subnet-create test 11.11.11.0/24
Then, DHCP port will be created and an error occurred on q-svc. You
can see
$ sudo journalctl -f -u devstack@q-svc.service
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1746404/+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 1600766] Re: initial dhcp has default hostname of ubuntu
>From Scott's comments and John's comments in the linked bug, this does not seem to be a Juju but cloud-init issue only. ** Changed in: juju Status: Triaged => 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/1600766 Title: initial dhcp has default hostname of ubuntu Status in cloud-init: Confirmed Status in juju: Invalid Status in cloud-init package in Ubuntu: Confirmed Bug description: When using the normal lxd-bridge, using a dnsmasq instance for dhcp, the initial dhcp is always the hostname 'ubuntu', and this is recorded in the dnsmasq's dhcp leases file. Presumably the dhcp is done before the container's hostname is set. A restart or dhcp renew seems to put the correct container name in the leases file. This is a problem when using the dnsmasq for local dns resolving for *.lxd, which is the standard way of doing host dns for containers, as new containers are not dns addressable without a restart or renew. Is there anyway get the correct hostname in the initial dhcp? Or maybe renew after setting the hostname? Related Bugs: * LXC/LXD Issue https://github.com/lxc/lxd/issues/2244 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1600766/+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 1730637] Re: PortBindingFailed_Remote (HTTP 500)
[Expired for OpenStack Compute (nova) because there has been no activity
for 60 days.]
** Changed in: nova
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1730637
Title:
PortBindingFailed_Remote (HTTP 500)
Status in neutron:
Expired
Status in OpenStack Compute (nova):
Expired
Bug description:
Hi all,
Description
===
I am running newton on centos7 and have currently one active instance.
This instance is connected to two vxlan networks(int and vxlannetwork)
and I would like to get it connected to two additonal, vlan and gre.
Networks are created, but after I create the port and try to attach
the interface I get an error. See below.
Steps to reproduce
===
# nova list
+--++++-+---+
| ID | Name | Status | Task State | Power
State | Networks |
+--++++-+---+
| 354caa3d-bddb-4396-ac0a-ef12e06b14e3 | cirros | ACTIVE | - |
Running | int=10.0.0.5; vxlannetwork=10.0.10.12 |
+--++++-+---+
when I create a port on vlan network and try to attach I get the
following error
# neutron net-list
+--+--++
| id | name | subnets
|
+--+--++
| 625914e4-c490-4808-a309-8591c97d62ea | ext |
6dc90b28-4b84-456f-bc95-1b3161c77ab5 10.0.100.0/24 |
| 7974307b-d4e8-4b6b-9354-62ffb0d148e2 | vxlannetwork |
e0494841-73dd-4c35-ad07-b8b7a0ae6fdb 10.0.10.0/24 |
| afd58b60-64c4-4ed3-9da9-c107bf40f593 | vlannetwork |
2549725d-9847-4d03-a9ab-02be5da3907b 10.0.20.0/24 |
| da177468-f3d8-45ef-a9d7-4ad03960dfab | int |
934d2862-bdb0-4369-a290-3e8dae7c 10.0.0.0/24 |
| de00479b-0777-4589-b20c-efe0858a9041 | grenetwork |
e9ad3685-3935-4c5c-bc6a-64d8fe0f09c3 10.0.30.0/24 |
+--+--++
#neutron port-create afd58b60-64c4-4ed3-9da9-c107bf40f593
Created a new port:
+---+--+
| Field | Value
|
+---+--+
| admin_state_up| True
|
| allowed_address_pairs |
|
| binding:host_id |
|
| binding:profile | {}
|
| binding:vif_details | {}
|
| binding:vif_type | unbound
|
| binding:vnic_type | normal
|
| created_at| 2017-11-06T19:00:40Z
|
| description |
|
| device_id |
|
| device_owner |
|
| extra_dhcp_opts |
|
| fixed_ips | {"subnet_id":
"2549725d-9847-4d03-a9ab-02be5da3907b", "ip_address": "10.0.20.9"} |
| id| 2795d640-adfe-417e-a598-68b7336b19fa
|
| mac_address | fa:16:3e:cc:27:f9
|
| name |
|
| network_id| afd58b60-64c4-4ed3-9da9-c107bf40f593
|
| project_id| 2dda4
[Yahoo-eng-team] [Bug 1730637] Re: PortBindingFailed_Remote (HTTP 500)
[Expired for neutron because there has been no activity for 60 days.]
** Changed in: neutron
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1730637
Title:
PortBindingFailed_Remote (HTTP 500)
Status in neutron:
Expired
Status in OpenStack Compute (nova):
Expired
Bug description:
Hi all,
Description
===
I am running newton on centos7 and have currently one active instance.
This instance is connected to two vxlan networks(int and vxlannetwork)
and I would like to get it connected to two additonal, vlan and gre.
Networks are created, but after I create the port and try to attach
the interface I get an error. See below.
Steps to reproduce
===
# nova list
+--++++-+---+
| ID | Name | Status | Task State | Power
State | Networks |
+--++++-+---+
| 354caa3d-bddb-4396-ac0a-ef12e06b14e3 | cirros | ACTIVE | - |
Running | int=10.0.0.5; vxlannetwork=10.0.10.12 |
+--++++-+---+
when I create a port on vlan network and try to attach I get the
following error
# neutron net-list
+--+--++
| id | name | subnets
|
+--+--++
| 625914e4-c490-4808-a309-8591c97d62ea | ext |
6dc90b28-4b84-456f-bc95-1b3161c77ab5 10.0.100.0/24 |
| 7974307b-d4e8-4b6b-9354-62ffb0d148e2 | vxlannetwork |
e0494841-73dd-4c35-ad07-b8b7a0ae6fdb 10.0.10.0/24 |
| afd58b60-64c4-4ed3-9da9-c107bf40f593 | vlannetwork |
2549725d-9847-4d03-a9ab-02be5da3907b 10.0.20.0/24 |
| da177468-f3d8-45ef-a9d7-4ad03960dfab | int |
934d2862-bdb0-4369-a290-3e8dae7c 10.0.0.0/24 |
| de00479b-0777-4589-b20c-efe0858a9041 | grenetwork |
e9ad3685-3935-4c5c-bc6a-64d8fe0f09c3 10.0.30.0/24 |
+--+--++
#neutron port-create afd58b60-64c4-4ed3-9da9-c107bf40f593
Created a new port:
+---+--+
| Field | Value
|
+---+--+
| admin_state_up| True
|
| allowed_address_pairs |
|
| binding:host_id |
|
| binding:profile | {}
|
| binding:vif_details | {}
|
| binding:vif_type | unbound
|
| binding:vnic_type | normal
|
| created_at| 2017-11-06T19:00:40Z
|
| description |
|
| device_id |
|
| device_owner |
|
| extra_dhcp_opts |
|
| fixed_ips | {"subnet_id":
"2549725d-9847-4d03-a9ab-02be5da3907b", "ip_address": "10.0.20.9"} |
| id| 2795d640-adfe-417e-a598-68b7336b19fa
|
| mac_address | fa:16:3e:cc:27:f9
|
| name |
|
| network_id| afd58b60-64c4-4ed3-9da9-c107bf40f593
|
| project_id| 2dda4fa3451947808fe
[Yahoo-eng-team] [Bug 1743725] Re: Verify operation in glance
You need to verify that the credentials you are using do in fact have the correct permissions to create an image. There may be a --debug option to the openstack client you can use to find out where the 401 is occurring and what credentials are being used for the call to the Images API. Check the openstack client documentation for details. ** Changed in: glance Status: New => Invalid ** Converted to question: https://answers.launchpad.net/glance/+question/663866 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1743725 Title: Verify operation in glance Status in Glance: Invalid Bug description: please assist i'm trying to verify glance installation on centos openstack pike but it states... as below [root@controller ~]# openstack image create "cirros" --file cirros-0.3.5-x86_64-disk.img --disk-format qcow2 --container-format bare --public 401 Unauthorized: This server could not verify that you are authorized to access the document you requested. Either you supplied the wrong credentials (e.g., bad password), or your browser does not understand how to supply the credentials required. (HTTP 401) please assist, thanks This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [ ] This doc is inaccurate in this way: __ - [ ] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - Ask OpenStack: http://ask.openstack.org - The mailing list: http://lists.openstack.org - IRC: 'openstack' channel on Freenode --- Release: 15.0.1.dev1 on 'Mon Aug 7 01:28:54 2017, commit 9091d26' SHA: 9091d262afb120fd077bae003d52463f833a4fde Source: https://git.openstack.org/cgit/openstack/glance/tree/doc/source/install/verify.rst URL: https://docs.openstack.org/glance/pike/install/verify.html To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1743725/+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 1746393] [NEW] 'cpu_thread_policy' impacts on emulator threads
Public bug reported: In bug/1744965(https://bugs.launchpad.net/nova/+bug/1744965), it is reported that the way emulator_threads_policy allocates the extra cpu resource for emulator is not optimal. This report reports the bug also stays when `cpu_thread_policy=isolate`. The instance I use for testing is a 3-vcpu VM with `cpu_thread_policy=isolate`; before enable this emulator_threads_policy, I reserve 6 cpu (actually 6 threads since we enable hyper threading) in nova config, vcpu_pin_set=8,10,12,32,34,36 Now when we enable emulator_threads_policy, in stead of adding one more thread to this vcpu pin list in the nova config, I end up adding two more sibling threads (on the same core) vcpu_pin_set=8,10,12,16,32,34,36,40 So I ended up using 2 more threads, but only one of them is used for emulator and the other thread is wasted. ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1746393 Title: 'cpu_thread_policy' impacts on emulator threads Status in OpenStack Compute (nova): New Bug description: In bug/1744965(https://bugs.launchpad.net/nova/+bug/1744965), it is reported that the way emulator_threads_policy allocates the extra cpu resource for emulator is not optimal. This report reports the bug also stays when `cpu_thread_policy=isolate`. The instance I use for testing is a 3-vcpu VM with `cpu_thread_policy=isolate`; before enable this emulator_threads_policy, I reserve 6 cpu (actually 6 threads since we enable hyper threading) in nova config, vcpu_pin_set=8,10,12,32,34,36 Now when we enable emulator_threads_policy, in stead of adding one more thread to this vcpu pin list in the nova config, I end up adding two more sibling threads (on the same core) vcpu_pin_set=8,10,12,16,32,34,36,40 So I ended up using 2 more threads, but only one of them is used for emulator and the other thread is wasted. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1746393/+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 1744160] Re: Change in iso8601 0.1.12 date format breaks parsing with py35
Reviewed: https://review.openstack.org/536182 Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=d24963f7e84b519864ece4fce99f9b0da0204da4 Submitter: Zuul Branch:master commit d24963f7e84b519864ece4fce99f9b0da0204da4 Author: junboli Date: Mon Jan 22 09:28:42 2018 +0800 Handle TZ change in iso8601 >=0.1.12 The iso8601 lib introduced a change such that if running on python 3.2 or later it internally uses the python timezone information instead of its own implementation. This does not change direct date handling, but when converting this value there is a slight difference where now python 2.x will show UTC times as "UTC", but on python 3 they will end up with "UTC+00:00". The to_primitive call for DateTime fields was doing an exact match on "UTC" to determine whether to include "Z" in the resulting string. This updates that handling to recognize either of the new values. Change-Id: Idfefd41e45727a375a5ea296a3348716c43f17b5 Closes-bug: #1744160 ** Changed in: cinder 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/1744160 Title: Change in iso8601 0.1.12 date format breaks parsing with py35 Status in Cinder: Fix Released Status in Glance: In Progress Status in OpenStack Identity (keystone): In Progress Status in Manila: In Progress Status in OpenStack Compute (nova): Fix Released Status in oslo.utils: In Progress Status in oslo.versionedobjects: Fix Released Bug description: New package of iso8601 returns string in the format: '2012-02-14T20:53:07UTC+00:00' instead of: '2012-02-14T20:53:07Z' This is resulting in date string comparison failures and timeutils.parse_isotime errors with: ValueError: Unable to parse date string '2014-08-08T00:00:00UTC+00:00' To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1744160/+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 1746388] Re: allocation candidates with invalid traits negative functional tests are intermittently failing
Nevermind the issue is here:
https://review.openstack.org/#/c/537351/3/nova/api/openstack/placement/util.py
** Changed in: nova
Status: Confirmed => 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/1746388
Title:
allocation candidates with invalid traits negative functional tests
are intermittently failing
Status in OpenStack Compute (nova):
Invalid
Bug description:
Introduced here:
https://review.openstack.org/#/c/535642/4/nova/tests/functional/api/openstack/placement/gabbits
/allocation-candidates.yaml
Seen failing here later in the series:
http://logs.openstack.org/10/539310/1/check/nova-tox-
functional/a6ba562/job-output.txt.gz#_2018-01-30_21_02_40_414709
2018-01-30 21:02:40.414681 | ubuntu-xenial | ==
2018-01-30 21:02:40.414709 | ubuntu-xenial | Failed 2 tests - output below:
2018-01-30 21:02:40.414732 | ubuntu-xenial | ==
2018-01-30 21:02:40.414741 | ubuntu-xenial |
2018-01-30 21:02:40.414822 | ubuntu-xenial |
nova.tests.functional.api.openstack.placement.test_placement_api.allocation-candidates_get_allocation_candidates_with_empty_required_value.test_request
2018-01-30 21:02:40.414901 | ubuntu-xenial |
---
2018-01-30 21:02:40.414910 | ubuntu-xenial |
2018-01-30 21:02:40.414930 | ubuntu-xenial | Captured pythonlogging:
2018-01-30 21:02:40.414949 | ubuntu-xenial | ~~~
2018-01-30 21:02:40.415054 | ubuntu-xenial | 2018-01-30 20:44:44,989 INFO
[nova.api.openstack.placement.requestlog] 127.0.0.1 "GET
/allocation_candidates?resources=VCPU:1,MEMORY_MB:1024,DISK_GB:100&required="
status: 400 len: 351 microversion: 1.17
2018-01-30 21:02:40.415066 | ubuntu-xenial |
2018-01-30 21:02:40.415075 | ubuntu-xenial |
2018-01-30 21:02:40.415092 | ubuntu-xenial | Captured traceback:
2018-01-30 21:02:40.415110 | ubuntu-xenial | ~~~
2018-01-30 21:02:40.415136 | ubuntu-xenial | Traceback (most recent call
last):
2018-01-30 21:02:40.415212 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/nova/.tox/functional/local/lib/python2.7/site-packages/gabbi/case.py",
line 94, in wrapper
2018-01-30 21:02:40.415235 | ubuntu-xenial | func(self)
2018-01-30 21:02:40.415315 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/nova/.tox/functional/local/lib/python2.7/site-packages/gabbi/case.py",
line 143, in test_request
2018-01-30 21:02:40.415335 | ubuntu-xenial | self._run_test()
2018-01-30 21:02:40.415412 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/nova/.tox/functional/local/lib/python2.7/site-packages/gabbi/case.py",
line 550, in _run_test
2018-01-30 21:02:40.415441 | ubuntu-xenial | self._assert_response()
2018-01-30 21:02:40.415522 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/nova/.tox/functional/local/lib/python2.7/site-packages/gabbi/case.py",
line 191, in _assert_response
2018-01-30 21:02:40.415541 | ubuntu-xenial | handler(self)
2018-01-30 21:02:40.415621 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/nova/.tox/functional/local/lib/python2.7/site-packages/gabbi/handlers/base.py",
line 54, in __call__
2018-01-30 21:02:40.415650 | ubuntu-xenial | self.action(test, item,
value=value)
2018-01-30 21:02:40.415729 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/nova/.tox/functional/local/lib/python2.7/site-packages/gabbi/handlers/core.py",
line 26, in action
2018-01-30 21:02:40.415765 | ubuntu-xenial |
test.assert_in_or_print_output(expected, test.output)
2018-01-30 21:02:40.415849 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/nova/.tox/functional/local/lib/python2.7/site-packages/gabbi/case.py",
line 652, in assert_in_or_print_output
2018-01-30 21:02:40.415869 | ubuntu-xenial | self.fail(msg)
2018-01-30 21:02:40.415945 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/nova/.tox/functional/local/lib/python2.7/site-packages/unittest2/case.py",
line 690, in fail
2018-01-30 21:02:40.415972 | ubuntu-xenial | raise
self.failureException(msg)
2018-01-30 21:02:40.416072 | ubuntu-xenial | AssertionError: 'Invalid
query string parameters: Expected 'required' parameter value of the form:
HW_CPU_X86_VMX,CUSTOM_MAGIC.' not found in {
2018-01-30 21:02:40.416094 | ubuntu-xenial | "errors": [
2018-01-30 21:02:40.416107 | ubuntu-xenial | {
2018-01-30 21:02:40.416146 | ubuntu-xenial | "request_id":
"req-8b3d6369-0829-47a8-951f-ebb71dc0e501",
2018-01-30 21:
[Yahoo-eng-team] [Bug 1746202] Re: Invalid query parameter could lead to HTTP 500
** Also affects: manila
Importance: Undecided
Status: New
** Changed in: manila
Assignee: (unassigned) => zhongjun (jun-zhongjun)
--
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/1746202
Title:
Invalid query parameter could lead to HTTP 500
Status in Cinder:
In Progress
Status in Manila:
New
Status in OpenStack Compute (nova):
In Progress
Bug description:
Invalid query parameter could lead to HTTP 500, although Nova used JSON
Schema verification
to check input query params, but query like:
GET /servers?limit=%88 will still lead to HTTP 500, as it failed to parse at
webob which is
pre JSON Schema check.
GET http://10.76.150.18/compute/v2.1/servers/detail?limit=%88
Response:
{
"computeFault": {
"message": "Unexpected API Error. Please report this at
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.\n",
"code": 500
}
}
Traceback:
DEBUG nova.api.openstack.wsgi [None req-ee355759-13c3-4f63-a41f-920d7385878d
admin admin] Calling method 'http://bugs.launchpad.net/nova/ and attach the Nova API lo
Jan 30 17:46:56 kevin-dev devstack@n-api.service[4374]:
Jan 30 17:46:56 kevin-dev devstack@n-api.service[4374]: DEBUG
nova.api.openstack.wsgi [None req-ee355759-13c3-4f63-a41f-920d7385878d admin
admin] Returning 500 to user: Unexpected API Error. Please report this at
http://bugs.launchpad.net/nova/ and attach the Nova API l
Jan 30 17:46:56 kevin-dev devstack@n-api.service[4374]: {{(pid=4377) __call__
/opt/stack/nova/nova/api/openstack/wsgi.py:1079}}
Jan 30 17:46:56 kevin-dev devstack@n-api.service[4374]: INFO
nova.api.openstack.requestlog [None req-ee355759-13c3-4f63-a41f-920d7385878d
admin admin] 10.8.4.18 "GET /compute/v2.1/servers/detail?limit=%89" status: 500
len: 202 microversion: 2.49 time: 0.531050
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1746202/+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 1746388] [NEW] allocation candidates with invalid traits negative functional tests are intermittently failing
Public bug reported:
Introduced here:
https://review.openstack.org/#/c/535642/4/nova/tests/functional/api/openstack/placement/gabbits
/allocation-candidates.yaml
Seen failing here later in the series:
http://logs.openstack.org/10/539310/1/check/nova-tox-functional/a6ba562
/job-output.txt.gz#_2018-01-30_21_02_40_414709
2018-01-30 21:02:40.414681 | ubuntu-xenial | ==
2018-01-30 21:02:40.414709 | ubuntu-xenial | Failed 2 tests - output below:
2018-01-30 21:02:40.414732 | ubuntu-xenial | ==
2018-01-30 21:02:40.414741 | ubuntu-xenial |
2018-01-30 21:02:40.414822 | ubuntu-xenial |
nova.tests.functional.api.openstack.placement.test_placement_api.allocation-candidates_get_allocation_candidates_with_empty_required_value.test_request
2018-01-30 21:02:40.414901 | ubuntu-xenial |
---
2018-01-30 21:02:40.414910 | ubuntu-xenial |
2018-01-30 21:02:40.414930 | ubuntu-xenial | Captured pythonlogging:
2018-01-30 21:02:40.414949 | ubuntu-xenial | ~~~
2018-01-30 21:02:40.415054 | ubuntu-xenial | 2018-01-30 20:44:44,989 INFO
[nova.api.openstack.placement.requestlog] 127.0.0.1 "GET
/allocation_candidates?resources=VCPU:1,MEMORY_MB:1024,DISK_GB:100&required="
status: 400 len: 351 microversion: 1.17
2018-01-30 21:02:40.415066 | ubuntu-xenial |
2018-01-30 21:02:40.415075 | ubuntu-xenial |
2018-01-30 21:02:40.415092 | ubuntu-xenial | Captured traceback:
2018-01-30 21:02:40.415110 | ubuntu-xenial | ~~~
2018-01-30 21:02:40.415136 | ubuntu-xenial | Traceback (most recent call
last):
2018-01-30 21:02:40.415212 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/nova/.tox/functional/local/lib/python2.7/site-packages/gabbi/case.py",
line 94, in wrapper
2018-01-30 21:02:40.415235 | ubuntu-xenial | func(self)
2018-01-30 21:02:40.415315 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/nova/.tox/functional/local/lib/python2.7/site-packages/gabbi/case.py",
line 143, in test_request
2018-01-30 21:02:40.415335 | ubuntu-xenial | self._run_test()
2018-01-30 21:02:40.415412 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/nova/.tox/functional/local/lib/python2.7/site-packages/gabbi/case.py",
line 550, in _run_test
2018-01-30 21:02:40.415441 | ubuntu-xenial | self._assert_response()
2018-01-30 21:02:40.415522 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/nova/.tox/functional/local/lib/python2.7/site-packages/gabbi/case.py",
line 191, in _assert_response
2018-01-30 21:02:40.415541 | ubuntu-xenial | handler(self)
2018-01-30 21:02:40.415621 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/nova/.tox/functional/local/lib/python2.7/site-packages/gabbi/handlers/base.py",
line 54, in __call__
2018-01-30 21:02:40.415650 | ubuntu-xenial | self.action(test, item,
value=value)
2018-01-30 21:02:40.415729 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/nova/.tox/functional/local/lib/python2.7/site-packages/gabbi/handlers/core.py",
line 26, in action
2018-01-30 21:02:40.415765 | ubuntu-xenial |
test.assert_in_or_print_output(expected, test.output)
2018-01-30 21:02:40.415849 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/nova/.tox/functional/local/lib/python2.7/site-packages/gabbi/case.py",
line 652, in assert_in_or_print_output
2018-01-30 21:02:40.415869 | ubuntu-xenial | self.fail(msg)
2018-01-30 21:02:40.415945 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/nova/.tox/functional/local/lib/python2.7/site-packages/unittest2/case.py",
line 690, in fail
2018-01-30 21:02:40.415972 | ubuntu-xenial | raise
self.failureException(msg)
2018-01-30 21:02:40.416072 | ubuntu-xenial | AssertionError: 'Invalid query
string parameters: Expected 'required' parameter value of the form:
HW_CPU_X86_VMX,CUSTOM_MAGIC.' not found in {
2018-01-30 21:02:40.416094 | ubuntu-xenial | "errors": [
2018-01-30 21:02:40.416107 | ubuntu-xenial | {
2018-01-30 21:02:40.416146 | ubuntu-xenial | "request_id":
"req-8b3d6369-0829-47a8-951f-ebb71dc0e501",
2018-01-30 21:02:40.416170 | ubuntu-xenial | "title": "Bad Request",
2018-01-30 21:02:40.416189 | ubuntu-xenial | "status": 400,
2018-01-30 21:02:40.416313 | ubuntu-xenial | "detail": "The server
could not comply with the request since it is either malformed or otherwise
incorrect.\n\n Invalid query string parameters: Expected \"required\" parameter
value of the form: HW_CPU_X86_VMX,CUSTOM_MAGIC. Got: \"\" "
2018-01-30 21:02:40.416330 | ubuntu-xenial | }
2018-01-30 21:02:40.416342 | ubuntu-xenial | ]
2018-01-30 21:02:40.416353 | ubuntu-xenial |
[Yahoo-eng-team] [Bug 1744160] Re: Change in iso8601 0.1.12 date format breaks parsing with py35
Reviewed: https://review.openstack.org/535700 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=11222bbf777a9418b9262bf56a61e5f3aa5f6501 Submitter: Zuul Branch:master commit 11222bbf777a9418b9262bf56a61e5f3aa5f6501 Author: deepak_mourya Date: Fri Jan 19 15:36:18 2018 +0530 Handle TZ change in iso8601 >=0.1.12 The iso8601 lib introduced a change such that if running on python 3.2 or later it internally uses the python timezone information instead of its own implementation. This does not change direct date handling, but when converting this value there is a slight difference where now python 2.x will show UTC times as "UTC", but on python 3 they will end up with "UTC+00:00". The to_primitive call for DateTime fields was doing an exact match on "UTC" to determine whether to include "Z" in the resulting string. This updates that handling to recognize either of the new values Change-Id: I426cf42ddcf6e8aa2d43f286eb76908670cc8d16 Closes-bug: #1744160 ** 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/1744160 Title: Change in iso8601 0.1.12 date format breaks parsing with py35 Status in Cinder: In Progress Status in Glance: In Progress Status in OpenStack Identity (keystone): In Progress Status in Manila: In Progress Status in OpenStack Compute (nova): Fix Released Status in oslo.utils: In Progress Status in oslo.versionedobjects: Fix Released Bug description: New package of iso8601 returns string in the format: '2012-02-14T20:53:07UTC+00:00' instead of: '2012-02-14T20:53:07Z' This is resulting in date string comparison failures and timeutils.parse_isotime errors with: ValueError: Unable to parse date string '2014-08-08T00:00:00UTC+00:00' To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1744160/+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 1746373] [NEW] Placement APIs with missing conflict detection
Public bug reported:
Placement has a few APIs which affect resource provider generation, but
which do not accept the current resource provider generation and
therefore cannot ensure consistency. They are as follows:
DELETE /resource_providers/{u}/inventories
DELETE /resource_providers/{u}/traits
POST /allocations
PUT /allocations/{c}
DELETE /allocations/{c}
As an example of how this is broken:
- X wants to remove all of provider {u}'s inventory in resource class VGPU. He
GETs inventory at generation 1, which happens to contain *only* VGPU.
- Y wants to add some SRIOV_NET_VF inventory to {u}. He GETs inventory at
generation 1, adds the SRIOV_NET_VF inventory, and PUTs it back. The server
increments the generation to 2, and the provider now has both VGPU and
SRIOV_NET_VF inventory.
- X, thinking the provider only has VGPU resource, invokes DELETE
/resource_providers/{u}/inventories, which succeeds, thereby blowing away the
SRIOV_NET_VF inventory.
Note that in the case of DELETE /resource_providers/{u}/inventories and
.../traits, there is an alternative, PUT , which *does* accept
the provider generation.
For the allocations APIs, there is no alternative. Though it could be
argued that it should not be necessary to send generation with the
allocations APIs.
** Affects: nova
Importance: Undecided
Status: New
** Tags: placement
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1746373
Title:
Placement APIs with missing conflict detection
Status in OpenStack Compute (nova):
New
Bug description:
Placement has a few APIs which affect resource provider generation,
but which do not accept the current resource provider generation and
therefore cannot ensure consistency. They are as follows:
DELETE /resource_providers/{u}/inventories
DELETE /resource_providers/{u}/traits
POST /allocations
PUT /allocations/{c}
DELETE /allocations/{c}
As an example of how this is broken:
- X wants to remove all of provider {u}'s inventory in resource class VGPU.
He GETs inventory at generation 1, which happens to contain *only* VGPU.
- Y wants to add some SRIOV_NET_VF inventory to {u}. He GETs inventory at
generation 1, adds the SRIOV_NET_VF inventory, and PUTs it back. The server
increments the generation to 2, and the provider now has both VGPU and
SRIOV_NET_VF inventory.
- X, thinking the provider only has VGPU resource, invokes DELETE
/resource_providers/{u}/inventories, which succeeds, thereby blowing away the
SRIOV_NET_VF inventory.
Note that in the case of DELETE /resource_providers/{u}/inventories
and .../traits, there is an alternative, PUT , which *does*
accept the provider generation.
For the allocations APIs, there is no alternative. Though it could be
argued that it should not be necessary to send generation with the
allocations APIs.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1746373/+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 1746374] [NEW] Report client _delete_inventory violates generation consistency
Public bug reported:
SchedulerReportClient._delete_inventory uses the DELETE
/resource_providers/{u}/inventories API, which does not provide a way to
send the generation down (see related bug [1]), and is therefore subject
to concurrency errors.
Until/unless an alternative becomes available, we should be using PUT
/resource_providers/{u}/inventories with an empty 'inventories' dict,
because that API *does* take the generation in the payload. (If we do
this, we also make moot part of related bug [2].)
Related bugs:
[1] https://bugs.launchpad.net/nova/+bug/1746075
[2] https://bugs.launchpad.net/nova/+bug/1746373
** Affects: nova
Importance: Undecided
Status: New
** Tags: placement
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1746374
Title:
Report client _delete_inventory violates generation consistency
Status in OpenStack Compute (nova):
New
Bug description:
SchedulerReportClient._delete_inventory uses the DELETE
/resource_providers/{u}/inventories API, which does not provide a way
to send the generation down (see related bug [1]), and is therefore
subject to concurrency errors.
Until/unless an alternative becomes available, we should be using PUT
/resource_providers/{u}/inventories with an empty 'inventories' dict,
because that API *does* take the generation in the payload. (If we do
this, we also make moot part of related bug [2].)
Related bugs:
[1] https://bugs.launchpad.net/nova/+bug/1746075
[2] https://bugs.launchpad.net/nova/+bug/1746373
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1746374/+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 1740795] Re: nova lacks debug output for selected page size when hw:mem_page_size is specified
Reviewed: https://review.openstack.org/530662
Committed:
https://git.openstack.org/cgit/openstack/nova/commit/?id=65736fd7d49284efd6c28be21aceb0ba1ea0ec4a
Submitter: Zuul
Branch:master
commit 65736fd7d49284efd6c28be21aceb0ba1ea0ec4a
Author: Andreas Karis
Date: Mon Jan 1 17:31:56 2018 -0500
Add debug output for selected page size
Adds debug output for selected page size when hw:mem_page_size
is specified. This output is especially useful in the case of
hw:mem_page_size=any.
Change-Id: Ie43228dbfa5623f880e9be032d8ebd9d0be42870
Closes-Bug: #1740795
** 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/1740795
Title:
nova lacks debug output for selected page size when hw:mem_page_size
is specified
Status in OpenStack Compute (nova):
Fix Released
Bug description:
nova lacks debug output for selected page size when hw:mem_page_size
is specified
Administrators currently are left completely in the dark as to which
page size is selected by nova and why. This output is especially
useful in the case of hw:mem_page_size=any.
/usr/lib/python2.7/site-packages/nova/virt/hardware.py
~~~
37 MEMPAGES_SMALL = -1
38 MEMPAGES_LARGE = -2
39 MEMPAGES_ANY = -3
(...)
933 def _get_flavor_image_meta(key, flavor, image_meta):
934 """Extract both flavor- and image-based variants of metadata."""
935 flavor_key = ':'.join(['hw', key])
936 image_key = '_'.join(['hw', key])
937
938 flavor_policy = flavor.get('extra_specs', {}).get(flavor_key)
939 image_policy = image_meta.properties.get(image_key)
940
941 return flavor_policy, image_policy
(...)
944 def _numa_get_pagesize_constraints(flavor, image_meta):
945 """Return the requested memory page size
946
947 :param flavor: a Flavor object to read extra specs from
948 :param image_meta: nova.objects.ImageMeta object instance
949
950 :raises: MemoryPageSizeInvalid if flavor extra spec or image
951 metadata provides an invalid hugepage value
952 :raises: MemoryPageSizeForbidden if flavor extra spec request
953 conflicts with image metadata request
954 :returns: a page size requested or MEMPAGES_*
955 """
956
957 def check_and_return_pages_size(request):
958 if request == "any":
959 return MEMPAGES_ANY
960 elif request == "large":
961 return MEMPAGES_LARGE
962 elif request == "small":
963 return MEMPAGES_SMALL
964 else:
965 try:
966 request = int(request)
967 except ValueError:
968 try:
969 request = strutils.string_to_bytes(
970 request, return_int=True) / units.Ki
971 except ValueError:
972 request = 0
973
974 if request <= 0:
975 raise exception.MemoryPageSizeInvalid(pagesize=request)
976
977 return request
978
979 flavor_request, image_request = _get_flavor_image_meta(
980 'mem_page_size', flavor, image_meta)
981
982 if not flavor_request and image_request:
983 raise exception.MemoryPageSizeForbidden(
984 pagesize=image_request,
985 against="")
986
987 if not flavor_request:
988 # Nothing was specified for hugepages,
989 # let's the default process running.
990 return None
991
992 pagesize = check_and_return_pages_size(flavor_request)
993 if image_request and (pagesize in (MEMPAGES_ANY, MEMPAGES_LARGE)):
994 return check_and_return_pages_size(image_request)
995 elif image_request:
996 raise exception.MemoryPageSizeForbidden(
997 pagesize=image_request,
998 against=flavor_request)
999
1000 return pagesize
~~~
If the flavor is set to any, and the image properties are not set, then this
will return:
MEMPAGES_ANY
In the same file, there is the following code:
~~~
620 def _numa_cell_supports_pagesize_request(host_cell, inst_cell):
621 """Determine whether the cell can accept the request.
622
623 :param host_cell: host cell to fit the instance cell onto
624 :param inst_cell: instance cell we want to fit
625
626 :raises: exception.MemoryPageSizeNotSupported if custom page
627 size not supported in host cell
628 :returns: the page size able to be handled by host_cell
629 """
630 avail_pagesize = [page.size_kb for page in host_cell.mempages]
631 avail_pagesize.sort(reverse=True)
632
633
[Yahoo-eng-team] [Bug 1744688] Re: api-ref: wrong parameter type in server-migrations.inc
Reviewed: https://review.openstack.org/536293 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=312327b75989fe0aad209c56671c583e33709303 Submitter: Zuul Branch:master commit 312327b75989fe0aad209c56671c583e33709303 Author: Takashi NATSUME Date: Mon Jan 22 19:01:00 2018 +0900 api-ref: Fix parameter type in server-migrations.inc When the parameter is always 'null', it should be defined as 'none'. So fix the parameter type of the 'force_complete' in "Force Migration Complete Action" API. And add an additional description for the action. Change-Id: Ic0dd390a87d0d5a88d9a08fdaa9e59ee99f6e7c4 Closes-Bug: #1744688 ** 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/1744688 Title: api-ref: wrong parameter type in server-migrations.inc Status in OpenStack Compute (nova): Fix Released Bug description: In "Force Migration Complete Action" API(*1), the 'force_complete' parameter in the request is defined as 'string'. This parameter is always 'null'(*2). In the other APIs, it is defined as 'none' (e.g. "Start Server" API (*3)) in that case. So It should be 'none' as well in "Force Migration Complete Action" API. *1: https://developer.openstack.org/api-ref/compute/#force-migration-complete-action-force-complete-action *2: https://github.com/openstack/nova/blob/a40c00957ef4552681c172913bae1135a1614bbc/nova/api/openstack/compute/schemas/server_migrations.py#L21 *3: https://developer.openstack.org/api-ref/compute/#start-server-os-start-action To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1744688/+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 1746361] [NEW] AttributeError: 'NoneType' object has no attribute 'version'
Public bug reported: When deploying LXD containers using Juju and MAAS, the LXD containers launch with no network connectivity because cloud-init fails with the following stack trace: Cloud-init v. 17.1 running 'init-local' at Tue, 30 Jan 2018 22:12:46 +. Up 1.00 seconds. 2018-01-30 22:12:47,040 - util.py[WARNING]: failed stage init-local failed run of stage init-local Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 638, in status_wrapper ret = functor(name, args) File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 357, in main_init init.apply_network_config(bring_up=bool(mode != sources.DSMODE_LOCAL)) File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 654, in apply_network_config return self.distro.apply_network_config(netcfg, bring_up=bring_up) File "/usr/lib/python3/dist-packages/cloudinit/distros/__init__.py", line 170, in apply_network_config dev_names = self._write_network_config(netconfig) File "/usr/lib/python3/dist-packages/cloudinit/distros/debian.py", line 119, in _write_network_config return self._supported_write_network_config(netconfig) File "/usr/lib/python3/dist-packages/cloudinit/distros/__init__.py", line 86, in _supported_write_network_config renderer.render_network_config(network_config=network_config) File "/usr/lib/python3/dist-packages/cloudinit/net/renderer.py", line 53, in render_network_config network_state=parse_net_config_data(network_config), target=target) File "/usr/lib/python3/dist-packages/cloudinit/net/netplan.py", line 193, in render_network_state content = self._render_content(network_state) File "/usr/lib/python3/dist-packages/cloudinit/net/netplan.py", line 227, in _render_content if network_state.version == 2: AttributeError: 'NoneType' object has no attribute 'version' No /sbin/ifup, assuming that it's a netplan system. Cloud-init v. 17.1 running 'init' at Tue, 30 Jan 2018 22:12:48 +. Up 2.00 seconds. ci-info: +++Net device info+++ ci-info: ++--+---+---+---+---+ ci-info: | Device | Up | Address |Mask | Scope | Hw-Address| ci-info: ++--+---+---+---+---+ ci-info: | eth0: | True | . | . | . | 00:16:3e:8e:77:d5 | ci-info: | eth0: | True | . | . | d | 00:16:3e:8e:77:d5 | ci-info: | lo: | True | 127.0.0.1 | 255.0.0.0 | . | . | ci-info: | lo: | True | . | . | d | . | ci-info: ++--+---+---+---+---+ This problem only seems to affect Juju and MAAS when deploying LXD containers on Ubuntu 17.10 systems (which use Netplan) but not on 16.04.03 LTS systems. ** Affects: cloud-init Importance: Undecided Status: New ** Attachment added: "tarball collected by running cloud-init collect-logs" https://bugs.launchpad.net/bugs/1746361/+attachment/5045866/+files/cloud-init.tar.gz -- 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/1746361 Title: AttributeError: 'NoneType' object has no attribute 'version' Status in cloud-init: New Bug description: When deploying LXD containers using Juju and MAAS, the LXD containers launch with no network connectivity because cloud-init fails with the following stack trace: Cloud-init v. 17.1 running 'init-local' at Tue, 30 Jan 2018 22:12:46 +. Up 1.00 seconds. 2018-01-30 22:12:47,040 - util.py[WARNING]: failed stage init-local failed run of stage init-local Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 638, in status_wrapper ret = functor(name, args) File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 357, in main_init init.apply_network_config(bring_up=bool(mode != sources.DSMODE_LOCAL)) File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 654, in apply_network_config return self.distro.apply_network_config(netcfg, bring_up=bring_up) File "/usr/lib/python3/dist-packages/cloudinit/distros/__init__.py", line 170, in apply_network_config dev_names = self._write_network_config(netconfig) File "/usr/lib/python3/dist-packages/cloudinit/distros/debian.py", line 119, in _write_network_config return self._supported_write_network_config(netconfig) File "/usr/lib/python3/dist-packages/cloudinit/distros/__init__.py", line 86, in _supported_write_network_config renderer.render_network_config(network_config=network_config) File
[Yahoo-eng-team] [Bug 1607313] Re: Inconsistency in data stored in libvirt.xml file
** Also affects: nova/ocata Importance: Undecided Status: New ** Changed in: nova/ocata Status: New => In Progress ** Changed in: nova/ocata Assignee: (unassigned) => Danil Akhmetov (dinobot) ** Changed in: nova/ocata Assignee: Danil Akhmetov (dinobot) => György Szombathelyi (gyurco) ** Changed in: nova/ocata Importance: Undecided => Low -- 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/1607313 Title: Inconsistency in data stored in libvirt.xml file Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) ocata series: In Progress Bug description: Operations involved : nova migrate nova evacuate nova live-migration The above mentioned operations on instances lead to creation of a new instance on a new compute host. It has been observed that the 'owner' information in the libvirt.xml file is populated with the username/projectname(tenantname) of the user performing any of the above operations. For instance, There's an instance 'ins-1' in project/tenant 'pro-1' owned by user 'user01' launched on compute host 'compute-101'. Now, an admin user named 'osadmin' from project 'admin', performs operation `nova live-migration asdfghi123xyz compute-102` * AD-123 (ID if ins-1) This leads to a live migration of ins-1 from compute-101 to compute-102. Now, the file /var/lib/nova/instances/asdfghi123xyz/libvirt.xml in compute-102 will have osadmin admin which ideally should be, user01 pro-1 This inconsistency is seen in all the operations mentioned, i.e. evacuate, migrate, live- migration. Related commands : nova live-migration SERVER HOST_NAME nova evacuate EVACUATED_SERVER_NAME HOST_B nova migrate VM_ID To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1607313/+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 1719362] Re: libvirt: Data corruptor live migrating BFV instance with config disk
** Also affects: nova/ocata Importance: Undecided Status: New ** Also affects: nova/pike Importance: Undecided Status: New ** Changed in: nova/ocata Status: New => In Progress ** Changed in: nova/pike Importance: Undecided => High ** Changed in: nova/pike Status: New => In Progress ** Changed in: nova/ocata Importance: Undecided => High ** Changed in: nova/ocata Assignee: (unassigned) => Matthew Booth (mbooth-9) ** Changed in: nova/pike Assignee: (unassigned) => Matthew Booth (mbooth-9) -- 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/1719362 Title: libvirt: Data corruptor live migrating BFV instance with config disk Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) ocata series: In Progress Status in OpenStack Compute (nova) pike series: In Progress Bug description: When live migrating a BFV instance with a config disk, the API currently requires block migration to be specified due to the local storage requirement. This doesn't make sense on a number of levels. Before calling migrateToURI3() in this case, the libvirt driver filters out all disks which it shouldn't migrate, which is both of them: the config drive because it's read-only and we already copied it with scp, and the root disk because it's a volume. It calls migrateToURI3() with an empty migrate_disks in params, and VIR_MIGRATE_NON_SHARED_INC in flags (because block-migration). There's a quirk in the behaviour of the libvirt python bindings here: it doesn't distinguish between an empty migrate_disks list, and no migrate_disks list. Both use the default behaviour of "block migrate all writable disks". This will include the attached root volume. As the root volume is simultaneously attached to both ends of the migration, one of which is running guest, this a data corruptor. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1719362/+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 1746323] [NEW] Documentation is missing about network_data.json
Public bug reported: Documentation is missing about network_data.json. The only available documentation is from the original spec which is a bit out of sync with the implementation: http://specs.openstack.org/openstack/nova- specs/specs/liberty/implemented/metadata-service-network-info.html For example: links[x]['type'] is in fact the vif model type, not the "vif" constant: https://github.com/openstack/nova/blob/748bb12eb280dcf24c88a778439480ae387467a9/nova/network/model.py#L149 And documentation could benefit from a better description and purpose of each fields. ** Affects: nova Importance: Undecided Status: New ** Tags: doc network ** Tags added: doc ** Tags added: network -- 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/1746323 Title: Documentation is missing about network_data.json Status in OpenStack Compute (nova): New Bug description: Documentation is missing about network_data.json. The only available documentation is from the original spec which is a bit out of sync with the implementation: http://specs.openstack.org/openstack/nova- specs/specs/liberty/implemented/metadata-service-network-info.html For example: links[x]['type'] is in fact the vif model type, not the "vif" constant: https://github.com/openstack/nova/blob/748bb12eb280dcf24c88a778439480ae387467a9/nova/network/model.py#L149 And documentation could benefit from a better description and purpose of each fields. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1746323/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1745380] Re: Cleanup unused params in parameters.yaml of api-ref
Reviewed: https://review.openstack.org/538585 Committed: https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=adefc64f21d8329ae5729d4a450b165728d29a8b Submitter: Zuul Branch:master commit adefc64f21d8329ae5729d4a450b165728d29a8b Author: Sławek Kapłoński Date: Sun Jan 28 10:34:38 2018 +0100 [Api-ref] Cleanup parameters.yaml This commit: * removes all params defined in parameters.yaml which are not used in any .inc file, * rename "type_2" param to "vpn_endpoint_type" as it is easier to understand what it is, * remove "tenant_id" and "tenant_id-request" params and replace them with "project_id-body-optional" and "project_id-request" as both were the same Change-Id: I6acfc28514e3201b6035a6bbfedc08ec8e389899 Closes-Bug: #1745380 ** 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/1745380 Title: Cleanup unused params in parameters.yaml of api-ref Status in neutron: Fix Released Bug description: Today the neutron-lib/api-ref/source/v2/parameters.yaml has a bunch of unused params. For example: name_39 name_41 etc.. Any params in parameters.yaml that's not used in any .inc, is not needed and should be removed from parameters.yaml (it's dead code per say). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1745380/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1746032] Re: By rebuilding twice with the same "forbidden" image one can circumvent scheduler rebuild restrictions
Reviewed: https://review.openstack.org/538961 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=4a2c9a4887a219a6d4dfe83c430b040713fc4109 Submitter: Zuul Branch:master commit 4a2c9a4887a219a6d4dfe83c430b040713fc4109 Author: Matt Riedemann Date: Mon Jan 29 10:50:36 2018 -0500 Rollback instance.image_ref on failed rebuild When rebuilding and changing the image, we run the new image through the scheduler to see if it's valid for the instance on its current compute host. The API saves off the new image ref on the instance before casting to conductor to run through the scheduler. If the scheduler fails, the instance.image_ref was not being rolled back, which meant a user could attempt the rebuild with the same invalid image a second time and the API, seeing the instance.image_ref hasn't changed (even though it's not the actual backing image for the server), will bypass the scheduler and rebuild the instance with that invalid image. This fixes the issue by using the original image ref, passed from API to conductor during rebuild, to reset the instance.image_ref in the case of a failure. Note that there are other things changed on the instance in the API which this patch does not attempt to recover as that's a bigger work item which likely involves substantial refactoring of the code. Closes-Bug: #1746032 Change-Id: I3399a66fe9b1297cd6b0dca440145393ceaef41f ** 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/1746032 Title: By rebuilding twice with the same "forbidden" image one can circumvent scheduler rebuild restrictions Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) newton series: Won't Fix Status in OpenStack Compute (nova) ocata series: In Progress Status in OpenStack Compute (nova) pike series: In Progress Bug description: Description === Since CVE-2017-16239, we call to the scheduler when doing a rebuild with a new image. If the scheduler refuses a rebuild because a filter forbids the new image on the instance's host (for example, IsolatedHostsFilter), at first there was no indication of this in the API (bug 1744325). Currently, with the fix for bug 1744325 merged [1], the instance goes to ERROR to indicate the refused rebuild. However, by rebuilding again with the same "forbidden" image it is possible to circumvent scheduler restrictions. Steps to reproduce == 1. Configure IsolatedHostsFilter: [filter_scheduler] enabled_filters = [...],IsolatedHostsFilter isolated_images = 41d3e5ca-14cf-436c-9413-4826b5c8bdb1 isolated_hosts = ubuntu restrict_isolated_hosts_to_isolated_images = true 2. Have two images, one isolated and one not: $ openstack image list 8d0581a5-ed9d-4b98-a766-a41efbc99929 | centos | active 41d3e5ca-14cf-436c-9413-4826b5c8bdb1 | cirros-0.3.5-x86_64-disk | active cirros is the isolated one 3. Have only one hypervisor (the isolated one): $ openstack hypervisor list ubuntu | QEMU | 192.168.100.194 | up 5. Boot a cirros (isolated) image: $ openstack server create \ --image 41d3e5ca-14cf-436c-9413-4826b5c8bdb1 \ --flavor m1.nano \ cirros-test-expect-success $ openstack server list cirros-test-expect-success | ACTIVE | [...] | cirros-0.3.5-x86_64-disk | m1.nano 6. Rebuild the cirros instance with centos (this should be refused by the scheduler): $ nova --debug rebuild cirros-test-expect-success centos DEBUG (session:722) POST call to compute for http://192.168.100.194/compute/v2.1/servers/d9d98bf7-623e-4587-b82c-06f36abf59cb/action used request id req-c234346a-6e05-47cf-a0cd-45f89d11e15d 8. Observe the instance going to ERROR, but still showing the new centos image : $ nova show cirros-test-expect-success [...] status | ERROR image | centos (8d0581a5-ed9d-4b98-a766-a41efbc99929) [...] 9. Rebuild again with the same centos image: $ nova rebuild cirros-test-expect-success centos 10. The rebuild goes through. Expected result === At step 10, the rebuild should still be refused. Actual result = The rebuild is allowed. Environment === 1. Exact version of OpenStack you are running. See the following Was reported in Red Hat OpenStack 12, affects newton through master. 2. Which hypervisor did you use? libvirt+kvm [1] https://review.openstack.org/#/c/536268/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1746032/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-
[Yahoo-eng-team] [Bug 1266962] Re: Remove set_time_override in timeutils
** Changed in: sahara Status: In Progress => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1266962 Title: Remove set_time_override in timeutils Status in Ceilometer: Fix Released Status in Cinder: Fix Released Status in gantt: New Status in Glance: Fix Released Status in OpenStack Heat: In Progress Status in Ironic: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in keystonemiddleware: In Progress Status in Manila: Fix Released Status in neutron: In Progress Status in OpenStack Compute (nova): Fix Released Status in oslo.messaging: Fix Released Status in oslo.utils: New Status in python-keystoneclient: Fix Released Status in python-novaclient: Fix Released Status in rack: In Progress Status in Sahara: Invalid Status in tuskar: Fix Released Status in zaqar: Fix Released Bug description: set_time_override was written as a helper function to mock utcnow in unittests. However we now use mock or fixture to mock our objects so set_time_override has become obsolete. We should first remove all usage of set_time_override from downstream projects before deleting it from oslo. List of attributes and functions to be removed from timeutils: * override_time * set_time_override() * clear_time_override() * advance_time_delta() * advance_time_seconds() To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1266962/+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 1745398] Re: functional jobs frequently time out
Reviewed: https://review.openstack.org/537933 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=6553a632399d77bb7c31690dd8284992eb6afb92 Submitter: Zuul Branch:master commit 6553a632399d77bb7c31690dd8284992eb6afb92 Author: Balazs Gibizer Date: Thu Jan 25 16:09:28 2018 +0100 Bumping functional test job timeouts Recently we saw frequent job timeouts probably due to the intel kernel patches. So this patch bumps the functional and functional-py35 jobs timeout from 1800 seconds to 3600 seconds. Change-Id: I632e006e1ba62c998955a04421e0e0c6311544cb Closes-Bug: #1745398 ** 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/1745398 Title: functional jobs frequently time out Status in OpenStack Compute (nova): Fix Released Bug description: Recently we see frequent functional test job timeouts most probably due to the intel kernel patches. http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22RUN%20END%20RESULT_TIMED_OUT%5C%22%20AND%20project%3A%5C%22openstack%2Fnova%5C%22%20AND%20build_name%3A%5C %22openstack-tox-functional%5C%22 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1745398/+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 1746302] [NEW] Consider using different (eg: not the same) labels for user and project names.
Public bug reported: This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [ ] This doc is inaccurate in this way: __ - [ ] This is a doc addition request. - [X] I have a fix to the document that I can paste below including example: input and output. On this page, the sample project and user share the same label "demo". And the role is named "user". In the CLI command at the end: $ openstack role add --project demo --user demo user The label "demo" appears twice and the role is called "user". Although each instance of "demo" is preceeded by an --argument that provides /some/ context, it may cause some confusion to some readers as to what this command is actually doing. It could be made much more clear by using different labels for the project, role and user labels. For example: $ openstack role add --project myproject --user myuser myrole --- Release: 12.0.1.dev7 on 2018-01-13 11:19 SHA: e851e0046fcdfd80787d8efdccdf0362fdd7b5db Source: https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/keystone-users-ubuntu.rst URL: https://docs.openstack.org/keystone/pike/install/keystone-users-ubuntu.html ** Affects: keystone Importance: Undecided Status: New ** Tags: doc -- 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/1746302 Title: Consider using different (eg: not the same) labels for user and project names. Status in OpenStack Identity (keystone): New Bug description: This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [ ] This doc is inaccurate in this way: __ - [ ] This is a doc addition request. - [X] I have a fix to the document that I can paste below including example: input and output. On this page, the sample project and user share the same label "demo". And the role is named "user". In the CLI command at the end: $ openstack role add --project demo --user demo user The label "demo" appears twice and the role is called "user". Although each instance of "demo" is preceeded by an --argument that provides /some/ context, it may cause some confusion to some readers as to what this command is actually doing. It could be made much more clear by using different labels for the project, role and user labels. For example: $ openstack role add --project myproject --user myuser myrole --- Release: 12.0.1.dev7 on 2018-01-13 11:19 SHA: e851e0046fcdfd80787d8efdccdf0362fdd7b5db Source: https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/keystone-users-ubuntu.rst URL: https://docs.openstack.org/keystone/pike/install/keystone-users-ubuntu.html To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1746302/+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 1746294] [NEW] Scheduler requests unlimited results from placement
Public bug reported: The scheduler will request an infinitely-large host set from placement during scheduling operations. This may be very large on big clouds and makes for a huge JSON response from placement to scheduler each time a single host needs to be selected. ** Affects: nova Importance: Medium Assignee: Dan Smith (danms) Status: In Progress ** Tags: queens-rc-potential scheduler -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1746294 Title: Scheduler requests unlimited results from placement Status in OpenStack Compute (nova): In Progress Bug description: The scheduler will request an infinitely-large host set from placement during scheduling operations. This may be very large on big clouds and makes for a huge JSON response from placement to scheduler each time a single host needs to be selected. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1746294/+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 1471278] Re: target removal on detaching volume with multi-attach flag
Multi-attach functionality is now implemented in both Cinder and Nova, which should make this bug invalid. In case the symptom appears again the bug shall be re-opened. Blueprint page with more details: https://blueprints.launchpad.net/nova/+spec/multi-attach-volume ** Changed in: nova Status: Incomplete => Invalid ** Changed in: cinder Status: New => Fix Committed -- 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/1471278 Title: target removal on detaching volume with multi-attach flag Status in Cinder: Fix Committed Status in OpenStack Compute (nova): Invalid Bug description: Cinder-volume removes target on detaching volume with multi-attach flag even if the volume still has attachments. This bug has been found during the development of volume-multi-attach support for nova. To reproduce it in devstack: - get multi-attach support for nova: https://review.openstack.org/#/c/153038/ - create a volume with multi-attach flag: cinder create 1 --allow-multiattach - create two instances (host was the same for both vms in our case) - attach volume to the instances - check iscsi target: tgtadm --lld iscsi --mode target --op show - check iscsi session: iscsiadm -m session -P 3 - detach the volume from one of the vms - check iscsi target/session again To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1471278/+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 1699060] Re: Impossible to define policy rule based on domain ID
I agree with Sean. It is worth tackled as a cross project topic. As an individual project, neutron triages this in the same way as nova does. ** Changed in: neutron Status: New => Opinion ** Changed in: neutron Importance: Undecided => Wishlist -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1699060 Title: Impossible to define policy rule based on domain ID Status in Glance: New Status in OpenStack Heat: Triaged Status in Manila: Opinion Status in neutron: Opinion Status in OpenStack Compute (nova): Opinion Status in oslo.policy: New Status in watcher: New Bug description: We have common approach to set rules for each API using policy.json file. And for the moment, it is not possible to use "domain_id" in policy rules, only "project_id" and "user_id". It becomes very important because Keystone API v3 is used more and more. The only service that supports rules with "domain_id" is Keystone itself. As a result we should be able to use following rules: "admin_or_domain_owner": "is_admin:True or domain_id:%(domain_id)s", "domain_owner": "domain_id:%(domain_id)s", like this: "volume:get": "rule:domain_owner", or "volume:get": "rule:admin_or_domain_owner", Right now, we always get 403 error having such rules. Related mail-list thread: https://openstack.nimeyo.com/115438 /openstack-dev-all-policy-rules-for-apis-based-on-domain_id To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1699060/+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 1746217] [NEW] enabled vgpu types example is wrong
Public bug reported: `enabled_vgpu_types` flag has been set in nova.conf to set enabled vgpu type of current host. The example is wrong, it should be [devices] enabled_vgpu_types = ['GRID K100', 'Intel GVT-g', 'MxGPU.2', 'nvidia-11'] Check nova/conf/devices.py to see the example. ** Affects: nova Importance: Undecided Assignee: Naichuan Sun (naichuans) Status: In Progress ** Tags: vgpu ** Description changed: - `enabled_vgpu_types` flag has been set in nova.conf to set enabled vgpu type of current host. The example is wrong, it should be - [devices] - enabled_vgpu_types = ['GRID K100', 'Intel GVT-g', 'MxGPU.2', 'nvidia-11'] + `enabled_vgpu_types` flag has been set in nova.conf to set enabled vgpu type of current host. The example is wrong, it should be + [devices] + enabled_vgpu_types = ['GRID K100', 'Intel GVT-g', 'MxGPU.2', 'nvidia-11'] + Check nova/conf/devices.py to see the example. ** Tags added: vgpu -- 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/1746217 Title: enabled vgpu types example is wrong Status in OpenStack Compute (nova): In Progress Bug description: `enabled_vgpu_types` flag has been set in nova.conf to set enabled vgpu type of current host. The example is wrong, it should be [devices] enabled_vgpu_types = ['GRID K100', 'Intel GVT-g', 'MxGPU.2', 'nvidia-11'] Check nova/conf/devices.py to see the example. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1746217/+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 1746202] Re: Invalid query parameter could lead to HTTP 500
** Also affects: cinder
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1746202
Title:
Invalid query parameter could lead to HTTP 500
Status in Cinder:
New
Status in OpenStack Compute (nova):
In Progress
Bug description:
Invalid query parameter could lead to HTTP 500, although Nova used JSON
Schema verification
to check input query params, but query like:
GET /servers?limit=%88 will still lead to HTTP 500, as it failed to parse at
webob which is
pre JSON Schema check.
GET http://10.76.150.18/compute/v2.1/servers/detail?limit=%88
Response:
{
"computeFault": {
"message": "Unexpected API Error. Please report this at
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.\n",
"code": 500
}
}
Traceback:
DEBUG nova.api.openstack.wsgi [None req-ee355759-13c3-4f63-a41f-920d7385878d
admin admin] Calling method 'http://bugs.launchpad.net/nova/ and attach the Nova API lo
Jan 30 17:46:56 kevin-dev devstack@n-api.service[4374]:
Jan 30 17:46:56 kevin-dev devstack@n-api.service[4374]: DEBUG
nova.api.openstack.wsgi [None req-ee355759-13c3-4f63-a41f-920d7385878d admin
admin] Returning 500 to user: Unexpected API Error. Please report this at
http://bugs.launchpad.net/nova/ and attach the Nova API l
Jan 30 17:46:56 kevin-dev devstack@n-api.service[4374]: {{(pid=4377) __call__
/opt/stack/nova/nova/api/openstack/wsgi.py:1079}}
Jan 30 17:46:56 kevin-dev devstack@n-api.service[4374]: INFO
nova.api.openstack.requestlog [None req-ee355759-13c3-4f63-a41f-920d7385878d
admin admin] 10.8.4.18 "GET /compute/v2.1/servers/detail?limit=%89" status: 500
len: 202 microversion: 2.49 time: 0.531050
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1746202/+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 1746212] [NEW] launch instances in parallel time slow
Public bug reported: Hello, I am using the Pike OpenStack version for ubuntu server 16.04. And the following guide to carry out the installation. https://docs.openstack.org/pike/install/ I have recently installed and updated OpenStack and precisely if I have seen that they have changed the configuration file for nova.conf. I perform autoscaling with the orchestration service (heat) for about 30 instances. I have verified that the execution times when several instances are executed in parallel is quite remarkable and goes from 5 seconds to 10. And for each execution in parallel that value of 10 is multiplied. There is some way to be able to make the execution of the instances in parallel with a shorter time or at least the same as when an instance is executed. I have not seen errors in logs or something like that and it may be some specific nova configuration or something ... Greetings and thanks in advance, ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1746212 Title: launch instances in parallel time slow Status in OpenStack Compute (nova): New Bug description: Hello, I am using the Pike OpenStack version for ubuntu server 16.04. And the following guide to carry out the installation. https://docs.openstack.org/pike/install/ I have recently installed and updated OpenStack and precisely if I have seen that they have changed the configuration file for nova.conf. I perform autoscaling with the orchestration service (heat) for about 30 instances. I have verified that the execution times when several instances are executed in parallel is quite remarkable and goes from 5 seconds to 10. And for each execution in parallel that value of 10 is multiplied. There is some way to be able to make the execution of the instances in parallel with a shorter time or at least the same as when an instance is executed. I have not seen errors in logs or something like that and it may be some specific nova configuration or something ... Greetings and thanks in advance, To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1746212/+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 1746209] [NEW] Ironic virt driver node cache may be missing required fields
Public bug reported: Per the discussion in [1], the ironic nodes added to the node cache in the ironic virt driver may be missing the required field resource_class, as this field is not in _NODE_FIELDS. In practice, this is typically not an issue (possibly never), as the normal code path uses a detailed list to sync all ironic nodes, which contain all fields (including resource_class). However, some code paths use a single node query with the fields limited to _NODE_FIELDS, so this should be changed to include the required resource_class. There are a number of other minor related issues picked up in that discussion, which don't really deserve their own bugs: * Filter the node list in _refresh_cache using _NODE_FIELDS. * Improve unit tests to use representative filtered node objects. * Remove _parse_node_instance_info and associated tests. [1] https://review.openstack.org/#/c/532288/9/nova/virt/ironic/driver.py@79 ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1746209 Title: Ironic virt driver node cache may be missing required fields Status in OpenStack Compute (nova): New Bug description: Per the discussion in [1], the ironic nodes added to the node cache in the ironic virt driver may be missing the required field resource_class, as this field is not in _NODE_FIELDS. In practice, this is typically not an issue (possibly never), as the normal code path uses a detailed list to sync all ironic nodes, which contain all fields (including resource_class). However, some code paths use a single node query with the fields limited to _NODE_FIELDS, so this should be changed to include the required resource_class. There are a number of other minor related issues picked up in that discussion, which don't really deserve their own bugs: * Filter the node list in _refresh_cache using _NODE_FIELDS. * Improve unit tests to use representative filtered node objects. * Remove _parse_node_instance_info and associated tests. [1] https://review.openstack.org/#/c/532288/9/nova/virt/ironic/driver.py@79 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1746209/+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 1746202] [NEW] Invalid query parameter could lead to HTTP 500
You have been subscribed to a public bug:
Invalid query parameter could lead to HTTP 500, although Nova used JSON Schema
verification
to check input query params, but query like:
GET /servers?limit=%88 will still lead to HTTP 500, as it failed to parse at
webob which is
pre JSON Schema check.
GET http://10.76.150.18/compute/v2.1/servers/detail?limit=%88
Response:
{
"computeFault": {
"message": "Unexpected API Error. Please report this at
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.\n",
"code": 500
}
}
Traceback:
DEBUG nova.api.openstack.wsgi [None req-ee355759-13c3-4f63-a41f-920d7385878d
admin admin] Calling method 'http://bugs.launchpad.net/nova/ and attach the Nova API lo
Jan 30 17:46:56 kevin-dev devstack@n-api.service[4374]:
Jan 30 17:46:56 kevin-dev devstack@n-api.service[4374]: DEBUG
nova.api.openstack.wsgi [None req-ee355759-13c3-4f63-a41f-920d7385878d admin
admin] Returning 500 to user: Unexpected API Error. Please report this at
http://bugs.launchpad.net/nova/ and attach the Nova API l
Jan 30 17:46:56 kevin-dev devstack@n-api.service[4374]: {{(pid=4377) __call__
/opt/stack/nova/nova/api/openstack/wsgi.py:1079}}
Jan 30 17:46:56 kevin-dev devstack@n-api.service[4374]: INFO
nova.api.openstack.requestlog [None req-ee355759-13c3-4f63-a41f-920d7385878d
admin admin] 10.8.4.18 "GET /compute/v2.1/servers/detail?limit=%89" status: 500
len: 202 microversion: 2.49 time: 0.531050
** Affects: nova
Importance: Undecided
Assignee: Zhenyu Zheng (zhengzhenyu)
Status: In Progress
--
Invalid query parameter could lead to HTTP 500
https://bugs.launchpad.net/bugs/1746202
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1746202] [NEW] Invalid query parameter could lead to HTTP 500
Public bug reported:
Invalid query parameter could lead to HTTP 500, although Nova used JSON Schema
verification
to check input query params, but query like:
GET /servers?limit=%88 will still lead to HTTP 500, as it failed to parse at
webob which is
pre JSON Schema check.
GET http://10.76.150.18/compute/v2.1/servers/detail?limit=%88
Response:
{
"computeFault": {
"message": "Unexpected API Error. Please report this at
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.\n",
"code": 500
}
}
Traceback:
DEBUG nova.api.openstack.wsgi [None req-ee355759-13c3-4f63-a41f-920d7385878d
admin admin] Calling method 'http://bugs.launchpad.net/nova/ and attach the Nova API lo
Jan 30 17:46:56 kevin-dev devstack@n-api.service[4374]:
Jan 30 17:46:56 kevin-dev devstack@n-api.service[4374]: DEBUG
nova.api.openstack.wsgi [None req-ee355759-13c3-4f63-a41f-920d7385878d admin
admin] Returning 500 to user: Unexpected API Error. Please report this at
http://bugs.launchpad.net/nova/ and attach the Nova API l
Jan 30 17:46:56 kevin-dev devstack@n-api.service[4374]: {{(pid=4377) __call__
/opt/stack/nova/nova/api/openstack/wsgi.py:1079}}
Jan 30 17:46:56 kevin-dev devstack@n-api.service[4374]: INFO
nova.api.openstack.requestlog [None req-ee355759-13c3-4f63-a41f-920d7385878d
admin admin] 10.8.4.18 "GET /compute/v2.1/servers/detail?limit=%89" status: 500
len: 202 microversion: 2.49 time: 0.531050
** Affects: nova
Importance: Undecided
Assignee: Zhenyu Zheng (zhengzhenyu)
Status: New
** Changed in: nova
Assignee: (unassigned) => Zhenyu Zheng (zhengzhenyu)
--
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/1746202
Title:
Invalid query parameter could lead to HTTP 500
Status in OpenStack Compute (nova):
New
Bug description:
Invalid query parameter could lead to HTTP 500, although Nova used JSON
Schema verification
to check input query params, but query like:
GET /servers?limit=%88 will still lead to HTTP 500, as it failed to parse at
webob which is
pre JSON Schema check.
GET http://10.76.150.18/compute/v2.1/servers/detail?limit=%88
Response:
{
"computeFault": {
"message": "Unexpected API Error. Please report this at
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.\n",
"code": 500
}
}
Traceback:
DEBUG nova.api.openstack.wsgi [None req-ee355759-13c3-4f63-a41f-920d7385878d
admin admin] Calling method 'http://bugs.launchpad.net/nova/ and attach the Nova API lo
Jan 30 17:46:56 kevin-dev devstack@n-api.service[4374]:
Jan 30 17:46:56 kevin-dev devstack@n-api.service[4374]: DEBUG
nova.api.openstack.wsgi [None req-ee355759-13c3-4f63-a41f-920d7385878d admin
admin] Returning 500 to user: Unexpected API Error. Please report this at
http://bugs.launchpad.net/nova/ and attach the Nova API l
Jan 30 17:46:56 kevin-dev devstack@n-api.service[4374]: {{(pid=4377) __call__
/opt/stack/nova/nova/api/openstack/wsgi.py:1079}}
Jan 30 17:46:56 kevin-dev devstack@n-api.service[4374]: INFO
nova.api.openstack.requestlog [None req-ee355759-13c3-4f63-a41f-920d7385878d
admin admin] 10.8.4.18 "GET /compute/v2.1/servers/detail?limit=%89" status: 500
len: 202 microversion: 2.49 time: 0.531050
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1746202/+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 1746188] [NEW] Virtlogd recreates console.log file as root:root after live migration
Public bug reported:
Hi,
Description / Steps to reproduce
When instances are launched, they get the following console/serial
configuration :
\n
If I look at the permissions for the console.log I see :
[root@ nova]# ls -l
/var/lib/nova/instances/e53cf7b4-e11a-445f-b4e3-006120e8d800/console.log
-rw---. 1 nova openstack 0 Jan 30 11:09
/var/lib/nova/instances/e53cf7b4-e11a-445f-b4e3-006120e8d800/console.log
[root@ nova]#
If I then live migrate the instance to another host (or complete a
resize operation), virtlogd deletes the console.log and then recreates
it as root:root.
[root@ nova]# ls -l
/var/lib/nova/instances/e53cf7b4-e11a-445f-b4e3-006120e8d800/console.log
-rw---. 1 root root 0 Jan 30 11:14
/var/lib/nova/instances/e53cf7b4-e11a-445f-b4e3-006120e8d800/console.log
[root@ nova]#
This looks to be because when the instance is configured with
append="off", it ends up setting trunc to True in
https://github.com/libvirt/libvirt/blob/93575f345116fe1413f6fe3109227b8be2f416da/src/util/virrotatingfile.c#L260-L265
and deletes the console log before recreating. As virtlogd is running
as root and it doesn't seem to chown anything, it becomes root:root.
The first migration completes successfully but subsequent ones fail due
to permissions errors trying to access the console.log.
If I change virt/libvirt/config.py to set append="on", the log isn't
recreated (but I know have a problem with an ever growing log file).
Expected result
===
Console.log still have nova:openstack ownership
Actual result
=
Console.log has root:root ownership
Environment
===
This is a libvirt + KVM environment on CentOS 7.
nova - 16.0.3
libvirt - 3.2.0-14.el7_4.7
qemu - 2.9.0-16.el7_4.13.1
In /etc/libvirt/qemu.conf, I have the following configured :
user = "nova"
group = "openstack"
dynamic_ownership = 0
SElinux is enabled, and if I set it to permissive and make it error for
that folder, I get records like :
(virtlogd attempting delete)
time->Tue Jan 30 12:43:27 2018
type=PROCTITLE msg=audit(1517276607.013:90227): proctitle="/usr/sbin/virtlogd"
type=PATH msg=audit(1517276607.013:90227): item=1
name="/var/lib/nova/instances/e53cf7b4-e11a-445f-b4e3-006120e8d800/console.log"
inode=1898807 dev=00:27 mode=0100600 ouid=162 ogid=1100 rdev=00:00
obj=system_u:object_r:nfs_t:s0 objtype=DELETE
type=PATH msg=audit(1517276607.013:90227): item=0
name="/var/lib/nova/instances/e53cf7b4-e11a-445f-b4e3-006120e8d800/"
inode=1898806 dev=00:27 mode=040755 ouid=162 ogid=1100 rdev=00:00
obj=system_u:object_r:nfs_t:s0 objtype=PARENT
type=CWD msg=audit(1517276607.013:90227): cwd="/"
type=SYSCALL msg=audit(1517276607.013:90227): arch=c03e syscall=87
success=yes exit=0 a0=7f406c000d30 a1=7f406c000cd9 a2=0 a3=6e6f632f36353935
items=2 ppid=1 pid=25859 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="virtlogd"
exe="/usr/sbin/virtlogd" subj=system_u:system_r:virtlogd_t:s0-s0:c0.c1023
type=AVC msg=audit(1517276607.013:90227): avc: denied { unlink } for
pid=25859 comm="virtlogd" name="console.log" dev="0:39" ino=1898807
scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:nfs_t:s0 tclass=file
type=AVC msg=audit(1517276607.013:90227): avc: denied { remove_name } for
pid=25859 comm="virtlogd" name="console.log" dev="0:39" ino=1898807
scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:nfs_t:s0 tclass=dir
type=AVC msg=audit(1517276607.013:90227): avc: denied { write } for
pid=25859 comm="virtlogd" name="e53cf7b4-e11a-445f-b4e3-006120e8d8006"
dev="0:39" ino=1898806 scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:nfs_t:s0 tclass=dir
(virtlogd attempting create)
time->Tue Jan 30 12:43:27 2018
type=PROCTITLE msg=audit(1517276607.018:90231): proctitle="/usr/sbin/virtlogd"
type=PATH msg=audit(1517276607.018:90231): item=1
name="/var/lib/nova/instances/e53cf7b4-e11a-445f-b4e3-006120e8d800/console.log"
inode=1898807 dev=00:27 mode=0100600 ouid=0 ogid=99 rdev=00:00
obj=system_u:object_r:nfs_t:s0 objtype=NORMAL
type=PATH msg=audit(1517276607.018:90231): item=0
name="/var/lib/nova/instances/e53cf7b4-e11a-445f-b4e3-006120e8d800/"
inode=1898806 dev=00:27 mode=040755 ouid=162 ogid=1100 rdev=00:00
obj=system_u:object_r:nfs_t:s0 objtype=PARENT
type=CWD msg=audit(1517276607.018:90231): cwd="/"
type=SYSCALL msg=audit(1517276607.018:90231): arch=c03e syscall=2
success=yes exit=15 a0=7f406c000d30 a1=80441 a2=180 a3=7f406c000d90 items=2
ppid=1 pid=25859 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="virtlogd"
exe="/usr/sbin/virtlogd" subj=system_u:system_r:virtlogd_t:s0-s0:c0.c1023
type=AVC msg=audit(1517276607.018:90231): avc: denied { create } for
pid=25859 comm="virtlogd" name="console.log"
scontext=system_u:s
[Yahoo-eng-team] [Bug 1746184] [NEW] Table of networks or routers does't support pagination
Public bug reported: The neutron service support the pagination for networks and routers. But the horizon does not support it. ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1746184 Title: Table of networks or routers does't support pagination Status in OpenStack Dashboard (Horizon): New Bug description: The neutron service support the pagination for networks and routers. But the horizon does not support it. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1746184/+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
