[Yahoo-eng-team] [Bug 1786744] Re: Cloud-init inject hostname should support dot and without .novalocal
[Expired for cloud-init because there has been no activity for 60 days.]
** Changed in: cloud-init
Status: Incomplete => Expired
--
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/1786744
Title:
Cloud-init inject hostname should support dot and without .novalocal
Status in cloud-init:
Expired
Bug description:
Description of problem:
Cloud-init inject hostname should support dot and without .novalocal.
Version-Release number of selected component (if applicable):
cloud-init 0.7.9
How reproducible:
100%
Steps to Reproduce:
1.create a RHEL7.5/7.4 instance specified the hostname with OpenStack API
2.login VM with hostnamectl to check the hostname
Actual results:
API: hostname=ecs-rhel7.4-instance > VM: hostname=ecs-rhel7.novanoval
API: hostname=ecs-rhel74-instance > VM: ecs-rhel74-instance.novanoval
Expected results:
The VM hostname is the same as specified in OpenStack API or ECS Console.
Additional info:
# diff __init__.py
usr/lib/python2.7/site-packages/cloudinit/sources/__init__.py
205c205
< toks = lhost.split(".novalocal")
---
> toks = lhost.split(".")
209c209
< #domain = '.'.join(toks[1:])
---
> domain = '.'.join(toks[1:])
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1786744/+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 1793391] Re: Subnet update with the subnet's current segment_id fail with: NoUpdateSubnetWhenMultipleSegmentsOnNetwork
Reviewed: https://review.openstack.org/603921
Committed:
https://git.openstack.org/cgit/openstack/neutron/commit/?id=3b5373b4efffc4213bf8753680c9ed3cc305b0d4
Submitter: Zuul
Branch:master
commit 3b5373b4efffc4213bf8753680c9ed3cc305b0d4
Author: Harald Jensås
Date: Wed Sep 19 15:36:27 2018 +0200
Allow update request with current segment_id
If the segment_id in the update request equals the segment_id
already associated with the subnet being updated, there is no
need for further update related segment validations.
Closes-Bug: #1793391
Change-Id: I65cd5b92b219c14dd07ae72457af243756c4ed02
** 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/1793391
Title:
Subnet update with the subnet's current segment_id fail with:
NoUpdateSubnetWhenMultipleSegmentsOnNetwork
Status in neutron:
Fix Released
Bug description:
When the update request contains segment_id and the provided
segment_id is equal to the id currently on the subnet, the update
request will fail if any of the checks in _validate_segment fail with
NoUpdateSubnetWhenMultipleSegmentsOnNetwork or
SubnetsNotAllAssociatedWithSegments.
[stack@heat-devstack ~]$ openstack network segment list --network testnet
+--+--+--+--+-+
| ID | Name | Network
| Network Type | Segment |
+--+--+--+--+-+
| 14ec1077-7836-45ec-9ce1-1bc45c670321 | net1 |
51394a06-75ce-401b-b46b-ebb2b34688b5 | flat | None|
| 884c98bb-22eb-4006-872b-966344d5bf8f | net2 |
51394a06-75ce-401b-b46b-ebb2b34688b5 | flat | None|
+--+--+--+--+-+
[stack@heat-devstack ~]$ openstack subnet list --network testnet
+--+-+--+-+
| ID | Name| Network
| Subnet |
+--+-+--+-+
| f21edda9-519e-4003-94f1-855c44a52cf8 | subnet1 |
51394a06-75ce-401b-b46b-ebb2b34688b5 | 10.100.100.0/24 |
+--+-+--+-+
[stack@heat-devstack ~]$ openstack subnet show subnet1
+---+--+
| Field | Value|
+---+--+
| allocation_pools | 10.100.100.2-10.100.100.254 |
| cidr | 10.100.100.0/24 |
| created_at| 2018-09-19T20:37:13Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip| 10.100.100.1 |
| host_routes | |
| id| f21edda9-519e-4003-94f1-855c44a52cf8 |
| ip_version| 4|
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | subnet1 |
| network_id| 51394a06-75ce-401b-b46b-ebb2b34688b5 |
| project_id| fee5807fd59146bc973f89ce2a7c70bd |
| revision_number | 2|
| segment_id| 14ec1077-7836-45ec-9ce1-1bc45c670321 |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at| 2018-09-19T20:40:54Z |
+---+--+
Actual result:
--
[stack@heat-devstack ~]$ curl -g -i -X PUT
http://192.168.122.222:9696/v2.0/subnets/f21edda9-519e-4003-94f1-855c44a52cf8
-H "Content-Type: application/json" -H "X-Auth-Token: $(openstack token issue
-f value -c id)" -d '{"subnet": {"segment_id":
"14ec1077-7836-45ec-9ce1-1bc45c670321"}}'
HTTP/1.1 400 Bad Request
Content-Type: application/json
Content-Length: 277
X-Openstack-Request-Id: req-999a512f-f49d-407a-bc8c-a7b9f3cb38a7
Date: Wed, 19 Sep 2018 20:43:27 GMT
{"NeutronError": {"message": "The network '51394a06-75ce-401b-b46b-
ebb2b34688b5' has multiple segments, it is only poss
[Yahoo-eng-team] [Bug 1792077] Re: problem specifying multiple "bus=scsi" block devices on nova boot
** Also affects: nova/ocata Importance: Undecided Status: New ** Also affects: nova/rocky Importance: Undecided Status: New ** Also affects: nova/queens Importance: Undecided Status: New ** Also affects: nova/pike 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/1792077 Title: problem specifying multiple "bus=scsi" block devices on nova boot Status in OpenStack Compute (nova): In Progress Status in OpenStack Compute (nova) ocata series: New Status in OpenStack Compute (nova) pike series: New Status in OpenStack Compute (nova) queens series: New Status in OpenStack Compute (nova) rocky series: New Bug description: I'm using devstack stable/rocky on ubuntu 16.04. When running this command nova boot --flavor m1.small --nic net-name=public --block-device source=image,id=24e8e922-2687-48b5-a895-3134a650e00f,dest=volume,size=2,bootindex=0,shutdown=remove,bus=scsi --block-device source=blank,dest=volume,size=2,bootindex=1,shutdown=remove,bus=scsi --poll twovol the instance fails to boot with the error: libvirtError: unsupported configuration: Found duplicate drive address for disk with target name 'sda' controller='0' bus='0' target='0' unit='0' For some background information, this works: nova boot --flavor m1.small --nic net-name=public --block-device source=image,id=24e8e922-2687-48b5-a895-3134a650e00f,dest=volume,size=2,bootindex=0,shutdown=remove,bus=scsi --poll onevol It also works if I have two block devices but don't specify "bus=scsi": nova boot --flavor m1.small --nic net-name=public --block-device source=image,id=24e8e922-2687-48b5-a895-3134a650e00f,dest=volume,size=2,bootindex=0,shutdown=remove --block-device source=blank,dest=volume,size=2,bootindex=1,shutdown=remove --poll twovolnoscsi This maps to the following XML: Sep 12 05:05:22 devstack nova-compute[3062]: Sep 12 05:05:22 devstack nova-compute[3062]: Sep 12 05:05:22 devstack nova-compute[3062]: Sep 12 05:05:22 devstack nova-compute[3062]: Sep 12 05:05:22 devstack nova-compute[3062]: Sep 12 05:05:22 devstack nova-compute[3062]: f16cb93d-7bf0-4da7-a804-b9539d64576a Sep 12 05:05:22 devstack nova-compute[3062]: Sep 12 05:05:22 devstack nova-compute[3062]: Sep 12 05:05:22 devstack nova-compute[3062]: Sep 12 05:05:22 devstack nova-compute[3062]: Sep 12 05:05:22 devstack nova-compute[3062]: Sep 12 05:05:22 devstack nova-compute[3062]: 7d5de2b0-cb66-4607-a5f5-60fd40db51c3 Sep 12 05:05:22 devstack nova-compute[3062]: In the failure case, the nova-compute logs include the following interesting bits. Note the additional '' lines in the XML. Sep 12 04:48:43 devstack nova-compute[3062]: ERROR nova.virt.libvirt.guest [None req-a7c5f15c-1e44-4cd1-bf57-45b819676b20 admin admin] Error defining a guest with XML: Sep 12 04:48:43 devstack nova-compute[3062]: Sep 12 04:48:43 devstack nova-compute[3062]: Sep 12 04:48:43 devstack nova-compute[3062]: Sep 12 04:48:43 devstack nova-compute[3062]: Sep 12 04:48:43 devstack nova-compute[3062]: Sep 12 04:48:43 devstack nova-compute[3062]: 08561cc0-5cf2-4eb7-a3f9-956f945e6c24 Sep 12 04:48:43 devstack nova-compute[3062]: Sep 12 04:48:43 devstack nova-compute[3062]: Sep 12 04:48:43 devstack nova-compute[3062]: Sep 12 04:48:43 devstack nova-compute[3062]: Sep 12 04:48:43 devstack nova-compute[3062]: Sep 12 04:48:43 devstack nova-compute[3062]: Sep 12 04:48:43 devstack nova-compute[3062]: 007fac3d-8800-4f45-9531-e3bab5c86a1e Sep 12 04:48:43 devstack nova-compute[3062]: Sep 12 04:48:43 devstack nova-compute[3062]: Sep 12 04:48:43 devstack nova-compute[3062]: : libvirtError: unsupported configuration: Found duplicate drive address for disk with target name 'sda' controller='0' bus='0' target='0' unit='0' Sep 12 04:48:43 devstack nova-compute[3062]: ERROR nova.virt.libvirt.driver [None req-a7c5f15c-1e44-4cd1-bf57-45b819676b20 admin admin] [instance: cf4f2c6f-7391-4a49-8f40-5e5cda98f78b] Failed to start libvirt guest: libvirtError: unsupported configuration: Found duplicate drive address for disk with target name 'sda' controller='0' bus='0' target='0' unit='0' Here is the libvirtd log in the failure case: 2018-09-12 04:48:43.312+: 16889: error : virDomainDefCheckDuplicateDriveAddresses:5747 : unsupported configuration: Found duplicate drive address for disk with target name 'sda' controller='0' bus='0' target='0' unit='0' To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1792077/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to
[Yahoo-eng-team] [Bug 1797580] Re: NoValidHost during live migration after cold migrating to a specified host
Reviewed: https://review.openstack.org/610098 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=ce3af5e33ae6843411e611e81c6ca1c21e0f1e09 Submitter: Zuul Branch:master commit ce3af5e33ae6843411e611e81c6ca1c21e0f1e09 Author: Matt Riedemann Date: Fri Oct 12 12:03:41 2018 -0400 Don't persist RequestSpec.requested_destination The RequestSpec.requested_destination, similar to the retry field, is per-request/operation, and persisting it can caues issues when subsequent move requests. For example, if you cold migrate a server to a specific host and then live migrate that server without specifying a host, the requested target host from the cold migrate is sent to the scheduler for the live migration, but since that is where the instance is already running, it's rejected with NoValidHost. This is a similar issue to the need to call RequestSpec.reset_forced_destinations() in all move operations in conductor. However, rather than try to whack this mole in every place the request spec is sent to the scheduler, like reset_forced_destinations() is used, we simply don't need to persist the requested_destination field since it's just a vehicle to tell the scheduler which host we want. The related functional regression test is updated to show the bug is now fixed. Change-Id: I2a78f0754c63381c57e7e1c610d0938b6df0f537 Closes-Bug: #1797580 ** 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/1797580 Title: NoValidHost during live migration after cold migrating to a specified host Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) queens series: In Progress Status in OpenStack Compute (nova) rocky series: In Progress Bug description: I recreated this with a 2-node devstack in stein created yesterday. 1. create a server 2. cold migrate the server to the other host and specify the host: nova migrate --host 3. confirm the resize 4. live migrate the server w/o specifying a host so the scheduler has to pick one At this point, you get a NoValidHost error because the scheduler is restricted to the current host on which the instance is running because of the requested_destination field that is persisted in the request spec from step 2: http://paste.openstack.org/show/731972/ The problem is when cold migrating a server with a specified target host, compute API stores that on the request spec and sends it to the conductor to tell the scheduler which host to use: https://github.com/openstack/nova/blob/20bc0136d0665bafdcd379f19389a0a5ea7bf310/nova/compute/api.py#L3565 But that request spec requested_destination field gets persisted and then when you live migrate, it's re-used but since the server is already on that host, we get NoValidHost since you can't live migrate to the same host. This is a regression in Queens: https://review.openstack.org/#/c/408955/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1797580/+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 1798787] Re: Installation help documentation is incorrect
Yeah looking at this page in queens you see the nova-consoleauth service being installed and started: https://docs.openstack.org/nova/queens/install/controller-install- ubuntu.html But not in Rocky: https://docs.openstack.org/nova/rocky/install/controller-install- ubuntu.html That is because of this change: https://review.openstack.org/#/c/557489/ So we probably want to remove the nova-consoleauth mention from the verify page if we don't tell you to install/start it: https://docs.openstack.org/nova/rocky/install/verify.html ** Tags added: consoleauth docs ** Changed in: nova Status: New => Triaged ** Changed in: nova Importance: Undecided => Medium ** Summary changed: - Installation help documentation is incorrect + Installation help documentation is incorrect - verify & nova-consoleauth ** Also affects: nova/rocky Importance: Undecided Status: New ** Changed in: nova/rocky Status: New => Triaged ** Changed in: nova/rocky Importance: Undecided => Medium -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1798787 Title: Installation help documentation is incorrect - verify & nova- consoleauth Status in OpenStack Compute (nova): Triaged Status in OpenStack Compute (nova) rocky series: Triaged Bug description: About Openstack's Documentation for Rocky document in Compute service – nova installation for Rocky --> Verify operation, normally executed by document, will display one less nova-consoleauth in step 2, so execute openstack compute service list You need to start nova- consoleauth before the operation, as follows: systemctl enable openstack-nova-consoleauth.service systemctl start openstack-nova-consoleauth.service To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1798787/+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 1687593] Re: Create OAUTH request token gives 401 error when request url is admin endpoint
Newton is not maintained. Marked as wont fix. ** Changed in: keystone/newton Status: In Progress => Won't Fix ** Changed in: keystone/ocata Status: In Progress => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1687593 Title: Create OAUTH request token gives 401 error when request url is admin endpoint Status in OpenStack Identity (keystone): Fix Committed Status in OpenStack Identity (keystone) newton series: Won't Fix Status in OpenStack Identity (keystone) ocata series: Won't Fix Status in python-keystoneclient: In Progress Bug description: Create request token API returns 401 error when the request URL is admin endpoint. Error scenario: URL used to generate OAUTH signature and for POST request is Keystone admin endpoint http:///identity_admin/v3/OS-OAUTH1/request_token Working scenario: When the URL used to generate OAUTH signature is public endpoint, then the response is 201. http:///identity/v3/OS-OAUTH1/request_token Endpoints in devstack for identity: ocata@ocata-VirtualBox:~/devstack$ openstack endpoint list | grep identity | 549f73e17b0e471e95176bb508561bb3 | RegionOne | keystone | identity | True| internal | http://192.168.56.101/identity| | 739cda51666f4ab197241beac5c5c14c | RegionOne | keystone | identity | True| admin | http://192.168.56.101/identity_admin | | a0eb39c0ecff46c3b61bc6184c42bc13 | RegionOne | keystone | identity | True| public| http://192.168.56.101/identity Steps to reproduce the problem: Run the python script in the below link (by changing the necessary credentials and IP address) https://pastebin.com/AqL9674n If #L38 is modified to public endpoint (http:///identity/v3/OS-OAUTH1/request_token), the status code is 201. Seems like Keystone code verifies the OAUTH signature using Public endpoint irrespective of the request URL. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1687593/+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 1797815] Re: DeprecationWarning: decodestring() is a deprecated alias, use decodebytes()
Reviewed: https://review.openstack.org/610401
Committed:
https://git.openstack.org/cgit/openstack/nova/commit/?id=ece8043ffe9e7df96366a295024e353af41d5fdb
Submitter: Zuul
Branch:master
commit ece8043ffe9e7df96366a295024e353af41d5fdb
Author: Takashi NATSUME
Date: Mon Oct 15 09:00:16 2018 +0900
Fix deprecated base64.decodestring warning
Replace base64.decodestring with
oslo_serialization.base64.decode_as_bytes.
Change-Id: Ifce0e8d9633f33f12040a1d5a2235cbcb673a436
Closes-Bug: #1797815
** 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/1797815
Title:
DeprecationWarning: decodestring() is a deprecated alias, use
decodebytes()
Status in OpenStack Compute (nova):
Fix Released
Bug description:
When executing 'tox -e py35', the following deprecation warning is shown.
It should be fixed.
{0}
nova.tests.unit.api.openstack.compute.test_serversV21.ServersControllerCreateTest.test_create_instance_with_none_allowd_for_v20_compat_mode
[4.981822s] ... ok
Captured stderr:
(snipped...)
b'/tmp/nova/nova/api/validation/validators.py:61: DeprecationWarning:
decodestring() is a deprecated alias, use decodebytes()'
b' base64.decodestring(instance)'
b''
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1797815/+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 1798846] Re: Install and configure in keystone
The port number is correct. 35357 was specific to the v2.0 API, which was officially removed in Queens[0]. All API calls are made over 5000. [0] https://docs.openstack.org/releasenotes/keystone/queens.html#other- notes ** Changed in: keystone Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1798846 Title: Install and configure in keystone Status in OpenStack Identity (keystone): Invalid 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: - [x] This doc is inaccurate in this way: __Port number for admin url is 5000 should be 35357 in the command below: # keystone-manage bootstrap --bootstrap-password ADMIN_PASS \ --bootstrap-admin-url http://controller:5000/v3/ \ --bootstrap-internal-url http://controller:5000/v3/ \ --bootstrap-public-url http://controller:5000/v3/ \ --bootstrap-region-id RegionOne - [ ] 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: 13.0.2.dev4 on 2018-10-19 08:45 SHA: 31a0818c1a425e9135f230b537707b2193714fad Source: https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/keystone-install-ubuntu.rst URL: https://docs.openstack.org/keystone/queens/install/keystone-install-ubuntu.html To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1798846/+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 1798846] [NEW] Install and configure in keystone
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: - [x] This doc is inaccurate in this way: __Port number for admin url is 5000 should be 35357 in the command below: # keystone-manage bootstrap --bootstrap-password ADMIN_PASS \ --bootstrap-admin-url http://controller:5000/v3/ \ --bootstrap-internal-url http://controller:5000/v3/ \ --bootstrap-public-url http://controller:5000/v3/ \ --bootstrap-region-id RegionOne - [ ] 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: 13.0.2.dev4 on 2018-10-19 08:45 SHA: 31a0818c1a425e9135f230b537707b2193714fad Source: https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/keystone-install-ubuntu.rst URL: https://docs.openstack.org/keystone/queens/install/keystone-install-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/1798846 Title: Install and configure in keystone 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: - [x] This doc is inaccurate in this way: __Port number for admin url is 5000 should be 35357 in the command below: # keystone-manage bootstrap --bootstrap-password ADMIN_PASS \ --bootstrap-admin-url http://controller:5000/v3/ \ --bootstrap-internal-url http://controller:5000/v3/ \ --bootstrap-public-url http://controller:5000/v3/ \ --bootstrap-region-id RegionOne - [ ] 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: 13.0.2.dev4 on 2018-10-19 08:45 SHA: 31a0818c1a425e9135f230b537707b2193714fad Source: https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/keystone-install-ubuntu.rst URL: https://docs.openstack.org/keystone/queens/install/keystone-install-ubuntu.html To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1798846/+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 1798832] [NEW] Horizon exposes internal IP addresses via keystone/svc-catalog API
Public bug reported: Example url: https:///api/keystone/svc-catalog/ Different application responses contain resource links which disclose internal IP addresses. Threat actors could learn valuable information and plan further attacks on disclosed systems. Horizon should avoid including internal IP addresses in application responses ** Affects: horizon Importance: Undecided Assignee: Oleksiy Petrenko (enacero) Status: In Progress ** Changed in: horizon Assignee: (unassigned) => Oleksiy Petrenko (enacero) ** Changed in: horizon Status: New => In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1798832 Title: Horizon exposes internal IP addresses via keystone/svc-catalog API Status in OpenStack Dashboard (Horizon): In Progress Bug description: Example url: https:///api/keystone/svc-catalog/ Different application responses contain resource links which disclose internal IP addresses. Threat actors could learn valuable information and plan further attacks on disclosed systems. Horizon should avoid including internal IP addresses in application responses To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1798832/+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 1798806] [NEW] Race condition between RT and scheduler
Public bug reported:
The HostState object which is used by the scheduler is using the 'stats'
property of the compute node to derive its own values, e.g. :
self.stats = compute.stats or {}
self.num_instances = int(self.stats.get('num_instances', 0))
self.num_io_ops = int(self.stats.get('io_workload', 0))
self.failed_builds = int(self.stats.get('failed_builds', 0))
These values are used for both filtering and weighing compute hosts.
However, the 'stats' property of the compute node is cleared during the
periodic update_available_resources() and populated again. The clearing
occurs in RT._copy_resources() and it preserves only the old value of
'failed_builds'. This creates a race condition between RT and scheduler
which may result into populating wrong values for 'num_io_ops' and
'num_instances' into the HostState object and thus leading to incorrect
scheduling decisions.
** Affects: nova
Importance: High
Assignee: Radoslav Gerganov (rgerganov)
Status: In Progress
** Tags: 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/1798806
Title:
Race condition between RT and scheduler
Status in OpenStack Compute (nova):
In Progress
Bug description:
The HostState object which is used by the scheduler is using the
'stats' property of the compute node to derive its own values, e.g. :
self.stats = compute.stats or {}
self.num_instances = int(self.stats.get('num_instances', 0))
self.num_io_ops = int(self.stats.get('io_workload', 0))
self.failed_builds = int(self.stats.get('failed_builds', 0))
These values are used for both filtering and weighing compute hosts.
However, the 'stats' property of the compute node is cleared during
the periodic update_available_resources() and populated again. The
clearing occurs in RT._copy_resources() and it preserves only the old
value of 'failed_builds'. This creates a race condition between RT and
scheduler which may result into populating wrong values for
'num_io_ops' and 'num_instances' into the HostState object and thus
leading to incorrect scheduling decisions.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1798806/+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 1798805] [NEW] Nova scheduler schedules VMs on nodes where nova-compute is down
Public bug reported: Description === After stopping the nova-compute service on a node, powering on VMs that were in a shutoff state, but assigned to the compute node where the compute service is no longer running, are powered on the host where the nova-compute service is stopped, causing the VM task state to be set to a bad state of "powering-on" forever. Steps to reproduce == Example: Disable the nova-compute service on host compute001 VM001 was previously running on this host, but is now shut down Power on VM001 nova-scheduler schedules VM001 on compute001 Expected result === The scheduler filter ComputeFilter should see that compute001 is not "operational and enabled", as described here: https://docs.openstack.org/ocata/config-reference/compute/schedulers.html#computefilter and "not" schedule this VM on host compute001. Actual result = compute001 is chosen to power on VM001, leaving it in a bad task state of "powering-on" forever. Environment === stable/rocky using Kolla-Ansible 7.0.0.0rc3devXX and Kolla 7.0.0.0rc3devXX. CentOS 7.5 with latest updates Kernel: Linux 4.18.14-1.el7.elrepo.x86_64 Hypervisor: KVM Storage: Ceph Networking: DVR ** 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/1798805 Title: Nova scheduler schedules VMs on nodes where nova-compute is down Status in OpenStack Compute (nova): New Bug description: Description === After stopping the nova-compute service on a node, powering on VMs that were in a shutoff state, but assigned to the compute node where the compute service is no longer running, are powered on the host where the nova-compute service is stopped, causing the VM task state to be set to a bad state of "powering-on" forever. Steps to reproduce == Example: Disable the nova-compute service on host compute001 VM001 was previously running on this host, but is now shut down Power on VM001 nova-scheduler schedules VM001 on compute001 Expected result === The scheduler filter ComputeFilter should see that compute001 is not "operational and enabled", as described here: https://docs.openstack.org/ocata/config-reference/compute/schedulers.html#computefilter and "not" schedule this VM on host compute001. Actual result = compute001 is chosen to power on VM001, leaving it in a bad task state of "powering-on" forever. Environment === stable/rocky using Kolla-Ansible 7.0.0.0rc3devXX and Kolla 7.0.0.0rc3devXX. CentOS 7.5 with latest updates Kernel: Linux 4.18.14-1.el7.elrepo.x86_64 Hypervisor: KVM Storage: Ceph Networking: DVR To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1798805/+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 1798796] [NEW] libvirt: Use VIR_MIGRATE_TLS to get QEMU's native TLS support for migration and NBD
Public bug reported: Make Nova's libvirt driver use libvirt's VIR_MIGRATE_TLS, which will transport a Nova instance's migration and NBD data streams via QEMU's native TLS. Rationale - >From a downstream bug description by Dan Berrangé: "The default QEMU migration transport runs a clear text TCP connection between the two QEMU servers. It is possible to tunnel the migration connection over libvirtd's secure connection but this imposes a significant performance penalty. It is also not possible to tunnel the NBD connection use for block migration at all. "As a step towards securing the management network we need to have Nova configure QEMU to use native TLS support on its migration and NBD data transports, without any tunnelling." Minimum version requirements for this feature to work: QEMU == 2.9 libvirt == v.4.4.0 * * * Broader context and background here: https://lists.gnu.org/archive/html/qemu-devel/2015-02/msg00529.html RFC: Universal encryption on QEMU I/O channels ** Affects: nova Importance: Medium Assignee: Kashyap Chamarthy (kashyapc) Status: New ** Tags: libvirt ** Tags added: libvirt ** Changed in: nova Importance: Undecided => Medium ** Changed in: nova Assignee: (unassigned) => Kashyap Chamarthy (kashyapc) -- 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/1798796 Title: libvirt: Use VIR_MIGRATE_TLS to get QEMU's native TLS support for migration and NBD Status in OpenStack Compute (nova): New Bug description: Make Nova's libvirt driver use libvirt's VIR_MIGRATE_TLS, which will transport a Nova instance's migration and NBD data streams via QEMU's native TLS. Rationale - From a downstream bug description by Dan Berrangé: "The default QEMU migration transport runs a clear text TCP connection between the two QEMU servers. It is possible to tunnel the migration connection over libvirtd's secure connection but this imposes a significant performance penalty. It is also not possible to tunnel the NBD connection use for block migration at all. "As a step towards securing the management network we need to have Nova configure QEMU to use native TLS support on its migration and NBD data transports, without any tunnelling." Minimum version requirements for this feature to work: QEMU == 2.9 libvirt == v.4.4.0 * * * Broader context and background here: https://lists.gnu.org/archive/html/qemu-devel/2015-02/msg00529.html RFC: Universal encryption on QEMU I/O channels To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1798796/+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 1797939] Re: Example in section "Create system-scoped token" is wrong
Reviewed: https://review.openstack.org/611685 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=33295032d95d0e85d68ea28a348d12b4e980a723 Submitter: Zuul Branch:master commit 33295032d95d0e85d68ea28a348d12b4e980a723 Author: Magnus Lööf Date: Thu Oct 18 19:51:57 2018 +0200 Fix example for getting system scoped token Previously, the example for getting a system scoped token read `--os-system` which does not work. Change-Id: Ic7d6e089f0c28e026192e83b56b487180bca09e3 Closes-Bug: 1797939 Signed-off-by: Magnus Lööf ** Changed in: keystone Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1797939 Title: Example in section "Create system-scoped token" is wrong Status in OpenStack Identity (keystone): Fix Released 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: - [x] This doc is inaccurate in this way: The example for Create system-scoped token says to use `--os-system` argument to the `openstack` cli tool. This does not work in: ``` $ openstack --version openstack 3.16.1 ``` ``` $ openstack --help | grep system [--os-system-scope ] --os-system-scope With password: Scope for system operations With v3oidcauthcode: Scope for system operations With v3oidcpassword: Scope for system operations With v3password: Scope for system operations With v3oidcaccesstoken: Scope for system operations With token: Scope for system operations With v3oidcclientcredentials: Scope for system operations With v3token: Scope for system operations With v3totp: Scope for system operations With v3applicationcredential: Scope for system operations ... ``` Also, I cannot figure out how to actually do what the example suggest: issue a token scoped to the system, which is what I want to remove this deprecation warning in the logs: ``` /usr/lib/python2.7/site-packages/oslo_policy/policy.py:896: UserWarning: Policy identity:list_domains failed scope check. The token used to make the request was project scoped but the policy requires ['system'] scope. This behavior may change in the future where using the intended scope is required warnings.warn(msg) ``` - [ ] 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: on 2018-10-09 13:15 SHA: 86cc778774bc6a561911be05075b4e3cdf6ef2b0 Source: https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/admin/identity-tokens.rst URL: https://docs.openstack.org/keystone/rocky/admin/identity-tokens.html To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1797939/+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 1798787] [NEW] 安装帮助文档有误
Public bug reported: 关于openstack的Documentation for Rocky文档中Compute service – nova installation for Rocky --> Verify operation 中，正常按文档执行 ，会在第2步少显示一个nova-consoleauth，所以在执行openstack compute service list 操作之前需要启动nova-consoleauth，具体执行如下： systemctl enable openstack-nova-consoleauth.service systemctl start openstack-nova-consoleauth.service ** 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/1798787 Title: 安装帮助文档有误 Status in OpenStack Compute (nova): New Bug description: 关于openstack的Documentation for Rocky文档中Compute service – nova installation for Rocky --> Verify operation 中，正常按文档执行 ，会在第2步少显示一个nova-consoleauth，所以在执行openstack compute service list 操作之前需要启动nova-consoleauth，具体执行如下： systemctl enable openstack-nova-consoleauth.service systemctl start openstack-nova-consoleauth.service To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1798787/+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 1798744] Re: Openstack limit list --project giving error
you can add this cli filter support in openstackclient ** Project changed: keystone => python-openstackclient -- 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/1798744 Title: Openstack limit list --project giving error Status in python-openstackclient: New Bug description: when doing openstack limit list --project xyz_id, CLI raising error unrecognized arguments, whereas in api-ref document [1], user can pass project_id as query param. [1] https://developer.openstack.org/api-ref/identity/v3/index.html To manage notifications about this bug go to: https://bugs.launchpad.net/python-openstackclient/+bug/1798744/+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 1798689] Re: Fullstack test test_create_one_default_qos_policy_per_project failed
All such issues were only spotted in one patch https://review.openstack.org/#/c/610280/ and it looks for me that it could be related to the change from this patch. I don't think we have any issue with this test in fullstack jobs for now. ** Changed in: neutron Status: New => Incomplete ** Changed in: neutron Status: Incomplete => 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/1798689 Title: Fullstack test test_create_one_default_qos_policy_per_project failed Status in neutron: Invalid Bug description: * Job: neutron-fullstack-python36 * Failed tests: test_create_one_default_qos_policy_per_project, test_create_two_default_qos_policies_per_project, test_update_default_status, test_update_default_status_conflict * Example failure: http://logs.openstack.org/80/610280/8/check/neutron-fullstack-python36/9811ceb/logs/testr_results.html.gz * Sample trace: http://paste.openstack.org/show/732449/ * Logstash: http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22ValueError%3A%20Field%20%60project_id'%20cannot%20be%20None%5C%22 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1798689/+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 1798744] [NEW] Openstack limit list --project giving error
Public bug reported: when doing openstack limit list --project xyz_id, CLI raising error unrecognized arguments, whereas in api-ref document [1], user can pass project_id as query param. [1] https://developer.openstack.org/api-ref/identity/v3/index.html ** Affects: keystone Importance: Undecided Assignee: Vishakha Agarwal (vishakha.agarwal) Status: New ** Changed in: keystone Assignee: (unassigned) => Vishakha Agarwal (vishakha.agarwal) -- 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/1798744 Title: Openstack limit list --project giving error Status in OpenStack Identity (keystone): New Bug description: when doing openstack limit list --project xyz_id, CLI raising error unrecognized arguments, whereas in api-ref document [1], user can pass project_id as query param. [1] https://developer.openstack.org/api-ref/identity/v3/index.html To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1798744/+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
