[Yahoo-eng-team] [Bug 1823703] Re: Wrong version URL when Glance is deployed behind proxy with vhost
Reviewed: https://review.opendev.org/650879 Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=33626369e591b03eb75c44b5c45c7969c7cb40e9 Submitter: Zuul Branch:master commit 33626369e591b03eb75c44b5c45c7969c7cb40e9 Author: Vlad Gusev Date: Mon Apr 8 15:49:16 2019 +0300 Use application_url in API version document This handles the possible vhost in Glance API path correctly (like https://cloud.example.com/image) contrary to host_url. Change-Id: If86d805ddc46944e3aa2785aa5d775fe15b8468c Closes-Bug: #1823703 ** Changed in: glance Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1823703 Title: Wrong version URL when Glance is deployed behind proxy with vhost Status in Glance: Fix Released Bug description: When Glance is deployed behind SSL terminating proxy, for example, as https://cloud.example.com/image the href returned in version doc is missing the vhost - https://cloud.example.com/v2 How to reproduce: 1. Run Glance behind proxy with vhost as https://cloud.example.com/image and pass host, X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Prefix headers 2. Remove DEFAULT/public_endpoint option from the config 3. Enable HTTPProxyToWSGI: oslo_middleware/enable_proxy_headers_parsing=True 4. curl https://cloud.example.com/image Actual result: https://cloud.example.com/v2/ in all hrefs Expected result: https://cloud.example.com/image/v2/ in all hrefs Glance version: Queens To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1823703/+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 1861723] Re: Glance is listening on TCP socket before store initialization
** Changed in: glance Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1861723 Title: Glance is listening on TCP socket before store initialization Status in Glance: Fix Released Bug description: When multiple backends is being used with rbd backend, Glance tries to get fsid of the cluster using rados library. If even one of the rbd backends is unavailable, glance-api wsgi fails to start properly, but continue listening on the tcp socket and not responding at any request until the timeout. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1861723/+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 1871032] [NEW] OVN migration scripts doesn't work with SSL-only deployment
Public bug reported: Based on comments in review: https://review.opendev.org/#/c/702247/7/tools/ovn_migration/migrate-to- ovn.yml@108 Looks like we don't support migration to OVN for TripleO deployments, while SSL-only deployment is specified. This needs investigation. ** Affects: neutron Importance: Undecided Status: New ** Tags: ovn ** Tags added: ovn -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1871032 Title: OVN migration scripts doesn't work with SSL-only deployment Status in neutron: New Bug description: Based on comments in review: https://review.opendev.org/#/c/702247/7/tools/ovn_migration/migrate- to-ovn.yml@108 Looks like we don't support migration to OVN for TripleO deployments, while SSL-only deployment is specified. This needs investigation. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1871032/+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 1870302] Re: [VPNaaS]: test_migrations_sync failed with alembic 1.4.2
Reviewed: https://review.opendev.org/716838
Committed:
https://git.openstack.org/cgit/openstack/neutron-vpnaas/commit/?id=f1856ab2cc01fa6ab7547ed0dfed1d5ffad26dca
Submitter: Zuul
Branch:master
commit f1856ab2cc01fa6ab7547ed0dfed1d5ffad26dca
Author: Dongcan Ye
Date: Thu Apr 2 04:01:56 2020 +
Fix the endpoint_type column name and order
Closes-Bug: #1870302
Change-Id: I35ccfe1db992837585c5c1bd62db5770fbd9c9ca
** 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/1870302
Title:
[VPNaaS]: test_migrations_sync failed with alembic 1.4.2
Status in neutron:
Fix Released
Bug description:
Neutron vpnaas functional gate failed with alembic 1.4.2.
2020-04-02 02:16:49.526046 | controller |
neutron_vpnaas.tests.functional.common.test_migrations_sync.TestModelsMigrationsMysql.test_models_sync
2020-04-02 02:16:49.526063 | controller |
--
2020-04-02 02:16:49.526079 | controller |
2020-04-02 02:16:49.526094 | controller | Captured traceback:
2020-04-02 02:16:49.526110 | controller | ~~~
2020-04-02 02:16:49.526126 | controller | Traceback (most recent call
last):
2020-04-02 02:16:49.526142 | controller |
2020-04-02 02:16:49.526157 | controller | File
"/home/zuul/src/opendev.org/openstack/neutron-vpnaas/.tox/dsvm-functional-sswan/lib/python3.6/site-packages/neutron/tests/base.py",
line 182, in func
2020-04-02 02:16:49.526174 | controller | return f(self, *args, **kwargs)
2020-04-02 02:16:49.526189 | controller |
2020-04-02 02:16:49.526205 | controller | File
"/home/zuul/src/opendev.org/openstack/neutron-vpnaas/.tox/dsvm-functional-sswan/lib/python3.6/site-packages/oslo_db/sqlalchemy/test_migrations.py",
line 598, in test_models_sync
2020-04-02 02:16:49.526221 | controller | "Models and migration scripts
aren't in sync:\n%s" % msg)
2020-04-02 02:16:49.526245 | controller |
2020-04-02 02:16:49.526263 | controller | File
"/home/zuul/src/opendev.org/openstack/neutron-vpnaas/.tox/dsvm-functional-sswan/lib/python3.6/site-packages/unittest2/case.py",
line 690, in fail
2020-04-02 02:16:49.526279 | controller | raise self.failureException(msg)
2020-04-02 02:16:49.526295 | controller |
2020-04-02 02:16:49.526310 | controller | AssertionError: Models and
migration scripts aren't in sync:
2020-04-02 02:16:49.526325 | controller | [ [ ( 'modify_type',
2020-04-02 02:16:49.526341 | controller | None,
2020-04-02 02:16:49.526356 | controller | 'vpn_endpoint_groups',
2020-04-02 02:16:49.526371 | controller | 'endpoint_type',
2020-04-02 02:16:49.526386 | controller | { 'existing_comment': None,
2020-04-02 02:16:49.526402 | controller | 'existing_nullable': False,
2020-04-02 02:16:49.526417 | controller | 'existing_server_default':
False},
2020-04-02 02:16:49.526432 | controller | ENUM('subnet', 'cidr',
'vlan', 'network', 'router'),
2020-04-02 02:16:49.526447 | controller | Enum('subnet', 'cidr',
'network', 'vlan', 'router', name='vpn_endpoint_type'))]]
2020-04-02 02:16:49.526463 | controller |
2020-04-02 02:16:49.526478 | controller |
2020-04-02 02:16:49.526494 | controller |
neutron_vpnaas.tests.functional.common.test_migrations_sync.TestModelsMigrationsPostgresql.test_models_sync
2020-04-02 02:16:49.526510 | controller |
---
2020-04-02 02:16:49.526525 | controller |
2020-04-02 02:16:49.526540 | controller | Captured traceback:
2020-04-02 02:16:49.526555 | controller | ~~~
2020-04-02 02:16:49.526570 | controller | Traceback (most recent call
last):
2020-04-02 02:16:49.526585 | controller |
2020-04-02 02:16:49.526600 | controller | File
"/home/zuul/src/opendev.org/openstack/neutron-vpnaas/.tox/dsvm-functional-sswan/lib/python3.6/site-packages/neutron/tests/base.py",
line 182, in func
2020-04-02 02:16:49.526616 | controller | return f(self, *args, **kwargs)
2020-04-02 02:16:49.526631 | controller |
2020-04-02 02:16:49.526647 | controller | File
"/home/zuul/src/opendev.org/openstack/neutron-vpnaas/.tox/dsvm-functional-sswan/lib/python3.6/site-packages/oslo_db/sqlalchemy/test_migrations.py",
line 598, in test_models_sync
2020-04-02 02:16:49.526663 | controller | "Models and migration scripts
aren't in sync:\n%s" % msg)
2020-04-02 02:16:49.526678 | controller |
2020-04-02 02:16:49.526694 | controller | File
"/home/zuul/src/opendev.org/openstack/neutron-vpnaas/.tox/dsvm-functional-sswan/lib/python3.6/site-packages/unittest2/case.py",
line 690, in fail
2020-04-02 02:16:49.526723 |
[Yahoo-eng-team] [Bug 1870385] Re: AcceleratorServerTest.test_create_server_with_error fails intermittently
Reviewed: https://review.opendev.org/717070
Committed:
https://git.openstack.org/cgit/openstack/nova/commit/?id=a85e6e07cfa34725922d5d31dbe6956797e9b3f2
Submitter: Zuul
Branch:master
commit a85e6e07cfa34725922d5d31dbe6956797e9b3f2
Author: Balazs Gibizer
Date: Thu Apr 2 17:47:20 2020 +0200
Stabilize functional tests
If a driver.spawn fails without triggering a re-schedule then the
placement cleanup and the compute build failure counter update
happens after every externally observable change (instance
state change, instance fault recording, notification sending) in
the finally block of _locked_do_build_and_run_instance() call.
We have couple of functional tests that assert either the placement
cleanup or the state of the build counter. These tests are unstable as
the test races with the compute manager code. As there are no externally
visible change to wait for this patch introduces some retry to
these tests to stabilize them.
Closes-Bug: #1870385
Change-Id: I68369e7fa7630a212f4b20fc09f4c40796934bb9
** 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/1870385
Title:
AcceleratorServerTest.test_create_server_with_error fails
intermittently
Status in OpenStack Compute (nova):
Fix Released
Bug description:
The AcceleratorServerTest.test_create_server_with_error functional
test is unstable on the gate.
Traceback (most recent call last):
File
"/home/zuul/src/opendev.org/openstack/nova/nova/tests/functional/test_servers.py",
line 8004, in test_create_server_with_error
self._check_no_allocs_usage(server_uuid)
File
"/home/zuul/src/opendev.org/openstack/nova/nova/tests/functional/test_servers.py",
line 7943, in _check_no_allocs_usage
self.assertEqual(allocs, {})
File
"/home/zuul/src/opendev.org/openstack/nova/.tox/functional-py36/lib/python3.6/site-packages/testtools/testcase.py",
line 415, in assertEqual
self.assertThat(observed, matcher, message)
File
"/home/zuul/src/opendev.org/openstack/nova/.tox/functional-py36/lib/python3.6/site-packages/testtools/testcase.py",
line 502, in assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: !=:
reference = {'20feee24-6050-496b-8ad8-906dd2cc30fc': {'generation': 3,
'resources': {'DISK_GB': 20,
'MEMORY_MB': 2048,
'VCPU': 2}},
'678fe533-5851-4766-89a9-e1bb6fcfadd9': {'generation': 3,
'resources': {'FPGA': 1}}}
actual= {}
https://0b0e867dded4f80d6512-217ff60ed5d3b708136ee1404afca04a.ssl.cf5.rackcdn.com/716141/2/check/nova-tox-functional-py36/88a8970/testr_results.html
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1870385/+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 1697925] Re: as a tenant user not able to create a subnetpool associating with a shared address scope
*** This bug is a duplicate of bug 1862968 *** https://bugs.launchpad.net/bugs/1862968 Reviewed: https://review.opendev.org/709122 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=eb6104c0ac61216234ea958f2fd322e70b8e4bec Submitter: Zuul Branch:master commit eb6104c0ac61216234ea958f2fd322e70b8e4bec Author: Igor Malinovskiy Date: Mon Feb 17 15:01:28 2020 +0200 Allow sharing of address scopes via RBAC mechanism Neutron-lib api ref: https://review.opendev.org/#/c/707407/ Client: https://review.opendev.org/#/c/709124/ Tempest tests: https://review.opendev.org/#/c/711610/ Change-Id: I74bedae4de4eb25e5427ecb129543885a020a0a8 Depends-On: https://review.opendev.org/712633 Partial-Bug: #1862968 Closes-Bug: #1697925 ** 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/1697925 Title: as a tenant user not able to create a subnetpool associating with a shared address scope Status in neutron: Fix Released Bug description: 1. created a "--shared" addresscope from admin tenant . 2. From a user tenant, as a normal user I am trying to create a subnetpool associating with the addresscope created in step 1. this operation fails , root@controller01:~# neutron address-scope-show cc21d772-a9b4-41c4-b48d-16c19bb828c6 ++--+ | Field | Value| ++--+ | id | cc21d772-a9b4-41c4-b48d-16c19bb828c6 | | ip_version | 4| | name | test-addr-scope | | project_id | f3e6f186351c441ea49c74e24360289c | |> shared | True | | tenant_id | f3e6f186351c441ea49c74e24360289c | ++--+ root@controller01:~# neutron subnetpool-create --pool-prefix 172.80.0.0/16 --default-prefixlen 24 selfservice --address-scope test-addr-scope Illegal subnetpool association: subnetpool cannot be associated with address scope cc21d772-a9b4-41c4-b48d-16c19bb828c6. Neutron server returns request_ids: ['req-2be55467-9e18-47a6-a9c2-9c3fe39f7190'] But as far as I understand we do support shared addresscopes. Please let me know if you want more info To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1697925/+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 1871096] [NEW] when only a negation is specified for cpu_*_sets we should assume all cpus are vaild and subtract the negated cpus
Public bug reported:
when using the cpu_share_set cpu_dedicated_set or
vcpu_pin_set(deprecated) it would be nice to be able to use a ter
syntax.
currently we support negated ranges
so on a 4 core host you can set
^0-1,0-3 and the result will be {2,3}
it would be nice to be able to just set "^0-1" and have the same effect
note that if we made this change we would have to preserve backwards
compatiabliyt
and it may be of limited use due to the fact we now have two ranages
cpu_share_set and cpu_dedicated_set
it would still allow you to do this however
cpu_share_set=1-10 cpu_dedicated_set=^0-10
to reserve core 0 for the os and core 1-10 for shared cpus and the rest for
dedicated cpus.
** Affects: nova
Importance: Wishlist
Status: Triaged
** Tags: config numa
--
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/1871096
Title:
when only a negation is specified for cpu_*_sets we should assume all
cpus are vaild and subtract the negated cpus
Status in OpenStack Compute (nova):
Triaged
Bug description:
when using the cpu_share_set cpu_dedicated_set or
vcpu_pin_set(deprecated) it would be nice to be able to use a ter
syntax.
currently we support negated ranges
so on a 4 core host you can set
^0-1,0-3 and the result will be {2,3}
it would be nice to be able to just set "^0-1" and have the same
effect
note that if we made this change we would have to preserve backwards
compatiabliyt
and it may be of limited use due to the fact we now have two ranages
cpu_share_set and cpu_dedicated_set
it would still allow you to do this however
cpu_share_set=1-10 cpu_dedicated_set=^0-10
to reserve core 0 for the os and core 1-10 for shared cpus and the rest for
dedicated cpus.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1871096/+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 1871138] Re: Horizon taking a long time to compress static assets
This affects Stein deploy jobs and Train upgrade jobs (due to Stein images). ** Changed in: kolla-ansible/stein Importance: Undecided => High ** Changed in: kolla-ansible/train Importance: Undecided => High ** Also affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1871138 Title: Horizon taking a long time to compress static assets Status in OpenStack Dashboard (Horizon): New Status in kolla-ansible: New Status in kolla-ansible stein series: New Status in kolla-ansible train series: New Bug description: Currently in Kolla Ansible CI we are hitting an issue where accessing the dashboard times out. We have a timeout of 100s. The container is up and running, with no errors. Checking the ps logs, we can see the CPU is 100% performing static asset compression: root 31399 31333 31399 99.1 3.7 336828 302972 /var/lib/kolla/venv/bin/python /var/lib/kolla/venv/bin/manage.py compress --force I did some binary-chopping of Python packages between the Stein and Train centos-source-horizon images. The culprit seems to be PyScss 1.3.7. In the train image it is 1.3.4. On my laptop, this ~doubles the time required for static asset compression from 35s to 1m10s. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1871138/+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 1871138] Re: Horizon taking a long time to compress static assets
** Changed in: kolla-ansible/train Status: New => Triaged ** Changed in: kolla-ansible/stein Status: New => Triaged ** Changed in: kolla-ansible Status: New => Triaged ** Changed in: kolla-ansible Status: Triaged => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1871138 Title: Horizon taking a long time to compress static assets Status in OpenStack Dashboard (Horizon): New Status in kolla-ansible: Invalid Status in kolla-ansible stein series: Triaged Status in kolla-ansible train series: Triaged Bug description: Currently in Kolla Ansible CI we are hitting an issue where accessing the dashboard times out. We have a timeout of 100s. The container is up and running, with no errors. Checking the ps logs, we can see the CPU is 100% performing static asset compression: root 31399 31333 31399 99.1 3.7 336828 302972 /var/lib/kolla/venv/bin/python /var/lib/kolla/venv/bin/manage.py compress --force I did some binary-chopping of Python packages between the Stein and Train centos-source-horizon images. The culprit seems to be PyScss 1.3.7. In the train image it is 1.3.4. On my laptop, this ~doubles the time required for static asset compression from 35s to 1m10s. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1871138/+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 1870313] Re: "send_ip_addr_adv_notif" can't use eventlet when called from "keepalived_state_change"
Reviewed: https://review.opendev.org/716944 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=21935365f29cce3fa95f032d9778786519461521 Submitter: Zuul Branch:master commit 21935365f29cce3fa95f032d9778786519461521 Author: Rodolfo Alonso Hernandez Date: Thu Apr 2 11:00:35 2020 + "keepalived_state_change" needs to use threading to send arping "keepalived_state_change" monitor does not use eventlet but normal Python threads. When "send_ip_addr_adv_notif" is called from inside the monitor, the arping command is never sent because the eventlet thread does not start. In order to be able to be called from this process, this method should also have an alternative implementation using "threading". "TestMonitorDaemon.test_new_fip_sends_garp" is also modified to actually test the GARP sent. The test was originally implemented with only one interface in the monitored namespace. "keepalived_state_change" sends a GARP when a new IP address is added in a interface other than the monitored one. That's why this patch creates a new interface and sets it as the monitor interface. When a new IP address is added to the other interface, the monitor populates it by sending a GARP through the modified interface [1]. [1] https://github.com/openstack/neutron/blob/8ee34655b8757086c03feecfda100333f47ed810/neutron/agent/l3/keepalived_state_change.py#L90 Change-Id: Ib69e21b4645cef71db07595019fac9af77fefaa1 Closes-Bug: #1870313 ** 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/1870313 Title: "send_ip_addr_adv_notif" can't use eventlet when called from "keepalived_state_change" Status in neutron: Fix Released Bug description: "keepalived_state_change" monitor does not use eventlet but normal Python threads. When "send_ip_addr_adv_notif" is called from inside the monitor, the arping command is never sent because the eventlet thread does not start. In order to be able to be called from this process, this method should also have an alternative implementation using "threading". This should have been captured by "TestMonitorDaemon.test_new_fip_sends_garp", but there is a problem in the implementation of this test. This test created two namespaces with a veth interface connecting both. The "keepalived_state_change" monitor is set to capture the events in the first namespace and the interface created inside. The test expects the monitor to send a GARP when a new IP address is added to the monitored interface. But this agent does not send a GARP from the monitored interface if a new IP address is set but from any other interface in this namespace [1]. This test use to pass because when the "ip neigh" is checked the second time, the "expected_ip" address is in the second namespace ARP table. This is because when the test asserts there is no ping and then sets the IP address on the interface, the last ping is replied by the interface: http://paste.openstack.org/show/791516/ This will, not intentionally, populate the ARP table in the second namespace but the GARP was not sent by the "keepalived_state_change" monitor. [1] https://github.com/openstack/neutron/blob/8ee34655b8757086c03feecfda100333f47ed810/neutron/agent/l3/keepalived_state_change.py#L90 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1870313/+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 1871138] Re: Horizon taking a long time to compress static assets
Affects kolla - flaky images. ** Also affects: kolla Importance: Undecided Status: New ** Also affects: kolla/stein Importance: Undecided Status: New ** Also affects: kolla/train Importance: Undecided Status: New ** Changed in: kolla/stein Status: New => Triaged ** Changed in: kolla Status: New => Invalid ** Changed in: kolla/train Status: New => Triaged ** Changed in: kolla Importance: Undecided => High ** Changed in: kolla/stein Importance: Undecided => High ** Changed in: kolla/train Importance: Undecided => High -- 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/1871138 Title: Horizon taking a long time to compress static assets Status in OpenStack Dashboard (Horizon): New Status in kolla: Invalid Status in kolla stein series: Triaged Status in kolla train series: Triaged Status in kolla-ansible: Invalid Status in kolla-ansible stein series: Triaged Status in kolla-ansible train series: Triaged Bug description: Currently in Kolla Ansible CI we are hitting an issue where accessing the dashboard times out. We have a timeout of 100s. The container is up and running, with no errors. Checking the ps logs, we can see the CPU is 100% performing static asset compression: root 31399 31333 31399 99.1 3.7 336828 302972 /var/lib/kolla/venv/bin/python /var/lib/kolla/venv/bin/manage.py compress --force I did some binary-chopping of Python packages between the Stein and Train centos-source-horizon images. The culprit seems to be PyScss 1.3.7. In the train image it is 1.3.4. On my laptop, this ~doubles the time required for static asset compression from 35s to 1m10s. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1871138/+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 1869768] Re: devstack failed when Q_AGENT=ovn
** 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/1869768 Title: devstack failed when Q_AGENT=ovn Status in neutron: Invalid Bug description: I tried stacking many times using the ovn-local.conf.sample (Q_AGENT=ovn), but I got a lot of errors, 2020-03-26 23:17:04.905 | ERROR: networking-ovn 7.0.0.0rc2.dev85 requires Babel!=2.4.0,>=2.3.4, which is not installed. 2020-03-26 23:17:04.905 | ERROR: networking-ovn 7.0.0.0rc2.dev85 requires futurist>=1.2.0, which is not installed. 2020-03-26 23:17:04.905 | ERROR: networking-ovn 7.0.0.0rc2.dev85 requires netaddr>=0.7.18, which is not installed. 2020-03-26 23:17:04.905 | ERROR: networking-ovn 7.0.0.0rc2.dev85 requires neutron-lib>=1.28.0, which is not installed. 2020-03-26 23:17:04.905 | ERROR: networking-ovn 7.0.0.0rc2.dev85 requires octavia-lib>=1.3.1, which is not installed. 2020-03-26 23:17:04.905 | ERROR: networking-ovn 7.0.0.0rc2.dev85 requires oslo.config>=5.2.0, which is not installed. 2020-03-26 23:17:04.905 | ERROR: networking-ovn 7.0.0.0rc2.dev85 requires ovs>=2.8.0, which is not installed. 2020-03-26 23:17:04.905 | ERROR: networking-ovn 7.0.0.0rc2.dev85 requires ovsdbapp>=0.17.0, which is not installed. 2020-03-26 23:17:04.906 | ERROR: networking-ovn 7.0.0.0rc2.dev85 requires pyOpenSSL>=17.1.0, which is not installed. in the end, it says “Neutron did not start”. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1869768/+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 1871239] [NEW] ovn-octavia-provider is not using load balancing algorithm source-ip-port
Public bug reported:
When using the ovn-octavia-provider, OVN is not honoring the
SOURCE_IP_PORT pool load balancing algorithm. The ovn-octavia-provider
only supports the SOURCE_IP_PORT load balancing algorithm.
The following test was created for the SOURCE_IP_PORT algorithm in tempest:
octavia_tempest_plugin.tests.scenario.v2.test_traffic_ops.TrafficOperationsScenarioTest.test_source_ip_port_tcp_traffic
Available in this patch: https://review.opendev.org/#/c/714004/
The test run shows that OVN is randomly distributing the connections
from the same source IP and port across the backend member servers. One
server is configured to return '1' and the other '5'.
Loadbalancer response totals: {'1': 12, '5': 8}
It should be seeing a result of:
Loadbalancer response totals: {'1': 20}
The attached files provide:
ovn-provider.pcap -- A pcap file capturing the test run.
ovn-tempest-output.txt -- The tempest console output.
tempest.log -- The tempest framework log from the test run.
** Affects: neutron
Importance: Undecided
Status: New
** Tags: ovn-octavia-provider
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1871239
Title:
ovn-octavia-provider is not using load balancing algorithm source-ip-
port
Status in neutron:
New
Bug description:
When using the ovn-octavia-provider, OVN is not honoring the
SOURCE_IP_PORT pool load balancing algorithm. The ovn-octavia-provider
only supports the SOURCE_IP_PORT load balancing algorithm.
The following test was created for the SOURCE_IP_PORT algorithm in tempest:
octavia_tempest_plugin.tests.scenario.v2.test_traffic_ops.TrafficOperationsScenarioTest.test_source_ip_port_tcp_traffic
Available in this patch: https://review.opendev.org/#/c/714004/
The test run shows that OVN is randomly distributing the connections
from the same source IP and port across the backend member servers.
One server is configured to return '1' and the other '5'.
Loadbalancer response totals: {'1': 12, '5': 8}
It should be seeing a result of:
Loadbalancer response totals: {'1': 20}
The attached files provide:
ovn-provider.pcap -- A pcap file capturing the test run.
ovn-tempest-output.txt -- The tempest console output.
tempest.log -- The tempest framework log from the test run.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1871239/+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 1866817] Re: Invalid input for field 'roles/0/id': 'role_admin' does not match '^[a-zA-Z0-9-]+$'
> seems to work fine on train region but fails on rocky region
The user in your rocky region does not have the image_viewer,
role_viewer, or role_admin roles assigned. Assign those roles to the
user on the project and it will work.
> I would like to harden my ec2 keystone policy, like restricting number
of credentials to be created, credentials validation, credentials TTL,
etc. Is this right forum to raise a new ticket or can i mail an expert
directly ?
See the documentation on using application credentials for how to set a
TTL/expiration:
https://docs.openstack.org/keystone/latest/user/application_credentials.html
and the configuration options for application credentials for how to set
a limit on them:
https://docs.openstack.org/keystone/latest/configuration/config-
options.html#application-credential
If you still have questions, you can email openstack-
disc...@lists.openstack.org and include [keystone] in the subject line,
or reach out on the freenode IRC network in the #openstack-keystone
channel.
** Changed in: keystone
Status: Incomplete => 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/1866817
Title:
Invalid input for field 'roles/0/id': 'role_admin' does not match
'^[a-zA-Z0-9-]+$'
Status in OpenStack Identity (keystone):
Invalid
Bug description:
Hi,
Please suggest how to fix the below error:
i get this error when i execute for roles image_viewer, role_admin,
role_viewer only, works fine with other roles.
openstack application credential create --role image_viewer --secret
test iv Invalid input for field 'roles/0/id': 'image_viewer' does not
match '^[a-zA-Z0-9-]+$'
Failed validating 'pattern' in
schema['properties']['roles']['items']['properties']['id']:
{'maxLength': 64, 'minLength': 1, 'pattern': '^[a-zA-Z0-9-]+$',
'type': 'string'}
On instance['roles'][0]['id']: 'image_viewer' (HTTP 400) (Request-ID:
req-92bd08a5-d151-41ca-b564-e8e981dd0539) openstack application
credential create --role role_admin --secret test iv 0 ↵ Invalid input
for field 'roles/0/id': 'role_admin' does not match '^[a-zA-Z0-9-]+$'
Failed validating 'pattern' in
schema['properties']['roles']['items']['properties']['id']:
{'maxLength': 64, 'minLength': 1, 'pattern': '^[a-zA-Z0-9-]+$',
'type': 'string'}
On instance['roles'][0]['id']: 'role_admin' (HTTP 400) (Request-ID:
req-d2388261-bd0d-4b02-9342-5d9ec32ceb6f)
The request ID shows the same data, this is an old bug in nova:
https://bugs.launchpad.net/nova/+bug/1491325
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1866817/+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 1871287] [NEW] server tags API policy is allowed for everyone even policy defaults is admin_or_owner
Public bug reported: server tags API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/717425 This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/cd16ae25c865f25dbb313976b3d8ef9372db80af/nova/api/openstack/compute/server_tags.py#L88 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/cd16ae25c865f25dbb313976b3d8ef9372db80af/nova/policies/server_tags.py#L27 ** Affects: nova Importance: Undecided Status: New ** Tags: policy ** Tags added: policy -- 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/1871287 Title: server tags API policy is allowed for everyone even policy defaults is admin_or_owner Status in OpenStack Compute (nova): New Bug description: server tags API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/717425 This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/cd16ae25c865f25dbb313976b3d8ef9372db80af/nova/api/openstack/compute/server_tags.py#L88 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/cd16ae25c865f25dbb313976b3d8ef9372db80af/nova/policies/server_tags.py#L27 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1871287/+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
