date:20240305

[Yahoo-eng-team] [Bug 2056276] [NEW] unmaintained/yoga periodic jobs broken

2024-03-05 Thread yatin

Public bug reported:

Couple of jobs failing in unmaintained/yoga periodic pipeline.

https://zuul.openstack.org/buildsets?project=openstack%2Fneutron=unmaintained%2Fyoga=stable%2Fyoga=periodic=0

Before switching to unmaintained/yoga jobs were green:-
https://zuul.openstack.org/buildset/eab6ceae73d7437186cb7432e7ad8897

Currently following jobs broken:-
- devstack-tobiko-neutron
- neutron-ovn-tempest-slow
- neutron-ovs-tempest-slow

All fails with:-
2024-03-04 02:30:28.791273 | controller | + ./stack.sh:main:230 
 :   
SUPPORTED_DISTROS='bullseye|focal|f35|opensuse-15.2|opensuse-tumbleweed|rhel8|rhel9|openEuler-20.03'
2024-03-04 02:30:28.793551 | controller | + ./stack.sh:main:232 
 :   [[ ! jammy =~ 
bullseye|focal|f35|opensuse-15.2|opensuse-tumbleweed|rhel8|rhel9|openEuler-20.03
 ]]
2024-03-04 02:30:28.795963 | controller | + ./stack.sh:main:233 
 :   echo 'WARNING: this script has not been tested on jammy'


builds:- 
https://zuul.openstack.org/builds?job_name=devstack-tobiko-neutron_name=neutron-ovn-tempest-slow_name=neutron-ovs-tempest-slow=openstack%2Fneutron=%09unmaintained%2Fyoga=0

The bug is to track the fixes and also discuss what to do with similar
issues going forward in unmaintained branches?

** Affects: neutron
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2056276

Title:
  unmaintained/yoga periodic jobs broken

Status in neutron:
  New

Bug description:
  Couple of jobs failing in unmaintained/yoga periodic pipeline.

  
https://zuul.openstack.org/buildsets?project=openstack%2Fneutron=unmaintained%2Fyoga=stable%2Fyoga=periodic=0

  Before switching to unmaintained/yoga jobs were green:-
  https://zuul.openstack.org/buildset/eab6ceae73d7437186cb7432e7ad8897

  Currently following jobs broken:-
  - devstack-tobiko-neutron
  - neutron-ovn-tempest-slow
  - neutron-ovs-tempest-slow

  All fails with:-
  2024-03-04 02:30:28.791273 | controller | + ./stack.sh:main:230   
   :   
SUPPORTED_DISTROS='bullseye|focal|f35|opensuse-15.2|opensuse-tumbleweed|rhel8|rhel9|openEuler-20.03'
  2024-03-04 02:30:28.793551 | controller | + ./stack.sh:main:232   
   :   [[ ! jammy =~ 
bullseye|focal|f35|opensuse-15.2|opensuse-tumbleweed|rhel8|rhel9|openEuler-20.03
 ]]
  2024-03-04 02:30:28.795963 | controller | + ./stack.sh:main:233   
   :   echo 'WARNING: this script has not been tested on jammy'

  
  builds:- 
https://zuul.openstack.org/builds?job_name=devstack-tobiko-neutron_name=neutron-ovn-tempest-slow_name=neutron-ovs-tempest-slow=openstack%2Fneutron=%09unmaintained%2Fyoga=0

  The bug is to track the fixes and also discuss what to do with similar
  issues going forward in unmaintained branches?

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2056276/+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 1998789] Re: [SRU] PooledLDAPHandler.result3 does not release pool connection back when an exception is raised

2024-03-05 Thread Launchpad Bug Tracker

This bug was fixed in the package keystone - 2:17.0.1-0ubuntu2

---
keystone (2:17.0.1-0ubuntu2) focal; urgency=medium

  * d/p/lp1998789-pooledldap-conn-release-on-exception.patch: Release
pooled ldap connection back to pool when an exception is thrown
by ldap methods (LP: #1998789).

 -- Mustafa Kemal GILOR   Wed, 04 Oct 2023
12:29:32 +0300

** Changed in: keystone (Ubuntu Focal)
   Status: Fix Committed => 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/1998789

Title:
  [SRU] PooledLDAPHandler.result3 does not release pool connection back
  when an exception is raised

Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive antelope series:
  Fix Released
Status in Ubuntu Cloud Archive ussuri series:
  Fix Released
Status in Ubuntu Cloud Archive victoria series:
  Fix Released
Status in Ubuntu Cloud Archive wallaby series:
  Fix Released
Status in Ubuntu Cloud Archive xena series:
  Fix Released
Status in Ubuntu Cloud Archive yoga series:
  Fix Released
Status in Ubuntu Cloud Archive zed series:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in keystone package in Ubuntu:
  Fix Released
Status in keystone source package in Focal:
  Fix Released
Status in keystone source package in Jammy:
  Fix Released
Status in keystone source package in Lunar:
  Fix Released

Bug description:
  [Impact]

  This SRU is a backport of
  https://review.opendev.org/c/openstack/keystone/+/866723 to the
  respective Ubuntu and UCA releases. The patch is merged to the all
  respective upstream branches (master & stable/[u,v,w,x,y,z]).

  This SRU intends to fix a denial-of-service bug that happens when
  keystone uses pooled ldap connections. In pooled ldap connection mode,
  keystone borrows a connection from the pool, do the LDAP operation and
  release it back to the pool. But, if an exception or error happens
  while the LDAP connection is still borrowed, Keystone fails to release
  the connection back to the pool, hogging it forever. If this happens
  for all the pooled connections, the connection pool will be exhausted
  and Keystone will no longer be able to perform LDAP operations.

  The fix corrects this behavior by allowing the connection to release
  back to the pool even if an exception/error happens during the LDAP
  operation.

  [Test Case]

  - Deploy an LDAP server of your choice
  - Fill it with many data so the search takes more than 
`pool_connection_timeout` seconds
  - Define a keystone domain with the LDAP driver with following options:

  [ldap]
  use_pool = True
  page_size = 100
  pool_connection_timeout = 3
  pool_retry_max = 3
  pool_size = 10

  - Point the domain to the LDAP server
  - Try to login to the OpenStack dashboard, or try to do anything that uses 
the LDAP user
  - Observe the /var/log/apache2/keystone_error.log, it should contain 
ldap.TIMEOUT() stack traces followed by `ldappool.MaxConnectionReachedError` 
stack traces

  To confirm the fix, repeat the scenario and observe that the
  "/var/log/apache2/keystone_error.log" does not contain
  `ldappool.MaxConnectionReachedError` stack traces and LDAP operation
  in motion is successful (e.g. OpenStack Dashboard login)

  [Regression Potential]
  The patch is quite trivial and should not affect any deployment in a negative 
way. The LDAP pool functionality can be disabled by setting "use_pool=False" in 
case of any regression.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1998789/+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 2025056] Re: Router ports without IP addresses shouldn't be allowed to deletion using port's API directly

2024-03-05 Thread Brian Haley

Patches merged, will close.

** 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/2025056

Title:
  Router ports without IP addresses shouldn't be allowed to deletion
  using port's API directly

Status in neutron:
  Fix Released

Bug description:
  Long time ago there was bug https://bugs.launchpad.net/neutron/+bug/1104337 
and as fix for this bug there was patch 
https://review.opendev.org/c/openstack/neutron/+/20424 proposed. This patch 
allowed to remove router ports without fixed IPs directly using "port delete" 
command.
  But it may cause error 500 if port really belongs to an existing router. 
Steps to reproduce the issue:

  1. Create network (external) and do NOT create subnet for it,
  2. Create router,
  3. Set network from p. 1 as external gateway for the router,
  4. Try to delete external gateway's port using "openstack port delete" 
command - it will fail with error 500. Stacktrace in neutron server log is as 
below:

  2023-06-22 05:41:06.672 16 DEBUG neutron.db.l3_db 
[req-a261d22f-9243-4b22-8d40-a5e7bcd63453 abd0fab2837040f383c986b6a723fbec 
39e32a986a4d4f42bce967634a308f99 - default default] Port 
9978f00d-4be2-474d-89a7-07d9b1e797df has owner network:router_gateway, but no 
IP address, so it can be deleted prevent_l3_port_deletion 
/usr/lib/python3.9/site-packages/neutron/db/l3_db.py:1675
  2023-06-22 05:41:07.085 16 DEBUG neutron.plugins.ml2.plugin 
[req-a261d22f-9243-4b22-8d40-a5e7bcd63453 abd0fab2837040f383c986b6a723fbec 
39e32a986a4d4f42bce967634a308f99 - default default] Calling delete_port for 
9978f00d-4be2-474d-89a7-07d9b1e797df owned by network:router_gateway 
delete_port /usr/lib/python3.9/site-packages/neutron/plugins/ml2/plugin.py:2069
  2023-06-22 05:41:07.360 16 ERROR neutron.pecan_wsgi.hooks.translation 
[req-a261d22f-9243-4b22-8d40-a5e7bcd63453 abd0fab2837040f383c986b6a723fbec 
39e32a986a4d4f42bce967634a308f99 - default default] DELETE failed.: 
oslo_db.exception.DBReferenceError: (pymysql.err.IntegrityError) (1451, 'Cannot 
delete or update a parent row: a foreign key constraint fails 
(`ovs_neutron`.`routers`, CONSTRAINT `routers_ibfk_1` FOREIGN KEY 
(`gw_port_id`) REFERENCES `ports` (`id`))')
  [SQL: DELETE FROM ports WHERE ports.id = %(id)s]
  [parameters: {'id': '9978f00d-4be2-474d-89a7-07d9b1e797df'}]
  (Background on this error at: http://sqlalche.me/e/13/gkpj)
  2023-06-22 05:41:07.360 16 ERROR neutron.pecan_wsgi.hooks.translation 
Traceback (most recent call last):
  2023-06-22 05:41:07.360 16 ERROR neutron.pecan_wsgi.hooks.translation   File 
"/usr/lib64/python3.9/site-packages/sqlalchemy/engine/base.py", line 1276, in 
_execute_context
  2023-06-22 05:41:07.360 16 ERROR neutron.pecan_wsgi.hooks.translation 
self.dialect.do_execute(
  2023-06-22 05:41:07.360 16 ERROR neutron.pecan_wsgi.hooks.translation   File 
"/usr/lib64/python3.9/site-packages/sqlalchemy/engine/default.py", line 609, in 
do_execute
  2023-06-22 05:41:07.360 16 ERROR neutron.pecan_wsgi.hooks.translation 
cursor.execute(statement, parameters)
  2023-06-22 05:41:07.360 16 ERROR neutron.pecan_wsgi.hooks.translation   File 
"/usr/lib/python3.9/site-packages/pymysql/cursors.py", line 163, in execute
  2023-06-22 05:41:07.360 16 ERROR neutron.pecan_wsgi.hooks.translation 
result = self._query(query)
  2023-06-22 05:41:07.360 16 ERROR neutron.pecan_wsgi.hooks.translation   File 
"/usr/lib/python3.9/site-packages/pymysql/cursors.py", line 321, in _query
  2023-06-22 05:41:07.360 16 ERROR neutron.pecan_wsgi.hooks.translation 
conn.query(q)
  2023-06-22 05:41:07.360 16 ERROR neutron.pecan_wsgi.hooks.translation   File 
"/usr/lib/python3.9/site-packages/pymysql/connections.py", line 505, in query
  2023-06-22 05:41:07.360 16 ERROR neutron.pecan_wsgi.hooks.translation 
self._affected_rows = self._read_query_result(unbuffered=unbuffered)
  2023-06-22 05:41:07.360 16 ERROR neutron.pecan_wsgi.hooks.translation   File 
"/usr/lib/python3.9/site-packages/pymysql/connections.py", line 724, in 
_read_query_result
  2023-06-22 05:41:07.360 16 ERROR neutron.pecan_wsgi.hooks.translation 
result.read()
  2023-06-22 05:41:07.360 16 ERROR neutron.pecan_wsgi.hooks.translation   File 
"/usr/lib/python3.9/site-packages/pymysql/connections.py", line 1069, in read
  2023-06-22 05:41:07.360 16 ERROR neutron.pecan_wsgi.hooks.translation 
first_packet = self.connection._read_packet()
  2023-06-22 05:41:07.360 16 ERROR neutron.pecan_wsgi.hooks.translation   File 
"/usr/lib/python3.9/site-packages/pymysql/connections.py", line 676, in 
_read_packet
  2023-06-22 05:41:07.360 16 ERROR neutron.pecan_wsgi.hooks.translation 
packet.raise_for_error()
  2023-06-22 05:41:07.360 16 ERROR neutron.pecan_wsgi.hooks.translation   File 
"/usr/lib/python3.9/site-packages/pymysql/protocol.py", line 223, in 
raise_for_error
  2023-06-22

[Yahoo-eng-team] [Bug 1999154] Re: ovs/ovn source deployment broken with ovs_branch=master

2024-03-05 Thread Brian Haley

Seems fixed, closing.

** Changed in: neutron
   Status: Confirmed => 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/1999154

Title:
  ovs/ovn source deployment broken with ovs_branch=master

Status in neutron:
  Fix Released

Bug description:
  Since [1] jobs running with OVS_BRANCH=master are broken, fails as below:-
  utilities/ovn-dbctl.c: In function ‘do_dbctl’:
  utilities/ovn-dbctl.c:724:9: error: too few arguments to function 
‘ctl_context_init_command’
724 | ctl_context_init_command(ctx, c);
| ^~~~
  In file included from utilities/ovn-dbctl.c:23:
  /opt/stack/ovs/lib/db-ctl-base.h:249:6: note: declared here
249 | void ctl_context_init_command(struct ctl_context *, struct 
ctl_command *,
|  ^~~~
  make[1]: *** [Makefile:2352: utilities/ovn-dbctl.o] Error 1
  make[1]: *** Waiting for unfinished jobs
  make[1]: Leaving directory '/opt/stack/ovn'
  make: *** [Makefile:1548: all] Error 2
  + lib/neutron_plugins/ovn_agent:compile_ovn:1 :   exit_trap

  Failure builds example:-
  - https://zuul.opendev.org/t/openstack/build/3a900a1cfe824746ac8ffc6a27fc8ec4
  - https://zuul.opendev.org/t/openstack/build/7d862338d6194a4fb3a34e8c3c67f532
  - https://zuul.opendev.org/t/openstack/build/ae092f4985af41908697240e3f64f522

  
  Until OVN repo[2] get's updated to work with ovs master we have to pin ovs to 
working version to get these experimental jobs back to green.

  [1] 
https://github.com/openvswitch/ovs/commit/b8bf410a5c94173da02279b369d75875c4035959
  [2] https://github.com/ovn-org/ovn

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1999154/+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 2008912] Re: "_validate_create_network_callback" failing with 'NoneType' object has no attribute 'qos_policy_id'

2024-03-05 Thread Brian Haley

Change merged, will close this.

** 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/2008912

Title:
  "_validate_create_network_callback" failing with 'NoneType' object has
  no attribute 'qos_policy_id'

Status in neutron:
  Fix Released

Bug description:
  Logs:
  
https://e138a887655b8fda005f-ea1d911c7c7db668a9aa6765a743313b.ssl.cf5.rackcdn.com/874133/2/check/neutron-
  tempest-plugin-openvswitch-enforce-scope-new-
  defaults/7e5cbf9/controller/logs/screen-q-svc.txt

  Error (snippet): https://paste.opendev.org/show/bYMju0ckz5GK5BYq0yhN/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2008912/+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 2022914] Re: [neutron-api] remove leader_only for maintenance worker

2024-03-05 Thread Brian Haley

Patches have merged, will close.

** 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/2022914

Title:
  [neutron-api] remove leader_only for maintenance worker

Status in neutron:
  Fix Released

Bug description:
  Currently if you want to connect the neutron-api to the souhtbound
  database you cannot use relays, because the maintenance worker has a
  condition set that it requires a leader_only connection.

  This leader_only collection is not necessary since the maintenance
  tasks of the neutron-api are only getting information from the
  souhtbound and are not pushing information into the souhtbound
  database.

  If you adjust the neutron-api to use relays, it will log something
  like "relay database, cannot be leader" every time the maintenance
  task should run.

  I would expect to be able to set the southbound connection for the
  neutron-api to use the relays.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2022914/+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 1897928] Re: TestOvnDbNotifyHandler test cases failing due to missing attribute "_RowEventHandler__watched_events"

2024-03-05 Thread Brian Haley

Seems to have been fixed with
https://review.opendev.org/c/openstack/neutron/+/820911 will close this
bug.

** 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/1897928

Title:
  TestOvnDbNotifyHandler test cases failing due to missing attribute
  "_RowEventHandler__watched_events"

Status in neutron:
  Fix Released

Bug description:
  Some 
neutron.tests.unit.plugins.ml2.drivers.ovn.mech_driver.ovsdb.test_ovsdb_monitor.TestOvnDbNotifyHandler
 test cases are failing:
  * test_shutdown
  * test_watch_and_unwatch_events

  The error [1] is caused because of a missing attribute: 
AttributeError: 'OvnDbNotifyHandler' object has no attribute 
'_RowEventHandler__watched_events'

  
  
[1]https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_bec/periodic/opendev.org/openstack/neutron/master/openstack-tox-py36-with-ovsdbapp-master/becf062/testr_results.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1897928/+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 1701410] Re: different behavior when deleting with request body (no BadRequest with core resources in case of pecan)

2024-03-05 Thread Brian Haley

I am going to close this as it is over 6 years old and no one has
stepped forward to fix it, so it's just not a priority. Please re-open
if necessary.

** Changed in: neutron
   Status: Confirmed => Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1701410

Title:
  different behavior when deleting with request body (no BadRequest with
  core resources in case of pecan)

Status in neutron:
  Won't Fix

Bug description:
  In master environment, it is different behavior when we try to delete with
  request body.  I fixed it in [1] but 
CORE_RESOURCE(network/subnet/port/subnetpool) doesn't pass this code in case of 
web_framework = pecan in /etc/neutron/neutron.conf

  [1]
  https://github.com/openstack/neutron/blame/master/neutron/api/v2/base.py#L555

  [FloatingIP, Router]
  $ source ~/devstack/openrc admin admin; export TOKEN=`openstack token issue | 
grep ' id ' | get_field 2`
  $ curl -i -X DELETE -d '{"floatingip":{"description": "aaa"}}' -H 
"content-type:application/json" -H 'accept:application/json' -H 
"x-auth-token:$TOKEN" 
192.168.122.33:9696/v2.0/floatingips/f4e9b845-4472-4806-bd7a-bec8f7618af2
  HTTP/1.1 400 Bad Request
  Content-Length: 113
  Content-Type: application/json
  X-Openstack-Request-Id: req-deaffdb3-7c13-4604-89d0-78fbcc184ef5
  Date: Fri, 30 Jun 2017 00:56:56 GMT

  {"NeutronError": {"message": "Request body is not supported in
  DELETE.", "type": "HTTPBadRequest", "detail": ""}}

  $ curl -i -X DELETE -d '{"router": {"name": "aaa"}}' -H 
"content-type:application/json" -H 'accept:application/json' -H 
"x-auth-token:$TOKEN" 
192.168.122.33:9696/v2.0/routers/1d0ea30e-c481-4be3-a548-a659d9e3787c
  HTTP/1.1 400 Bad Request
  Content-Length: 113
  Content-Type: application/json
  X-Openstack-Request-Id: req-a2f9babb-4eb3-471e-9b42-ccfe722c44f0
  Date: Fri, 30 Jun 2017 01:44:40 GMT

  {"NeutronError": {"message": "Request body is not supported in
  DELETE.", "type": "HTTPBadRequest", "detail": ""}}

  [Core resources: Network/Subnet/Port/Subnetpool]
  $ source ~/devstack/openrc admin admin; export TOKEN=`openstack token issue | 
grep ' id ' | get_field 2`
  $ curl -i -X DELETE -d '{"network":{"name": ""}}' -H 
"content-type:application/json" -H 'accept:application/json' -H 
"x-auth-token:$TOKEN" 
192.168.122.33:9696/v2.0/networks/1fb94931-dabe-49dc-bce4-68c8bafea8b0

  HTTP/1.1 204 No Content
  Content-Length: 0
  X-Openstack-Request-Id: req-7e838c38-e6cd-46c3-8703-c93f5bb4a503
  Date: Fri, 30 Jun 2017 01:32:12 GMT

  $ curl -i -X DELETE -d '{"subnet": {"name": "aaa"}}' -H "content-
  type:application/json" -H 'accept:application/json' -H "x-auth-
  token:$TOKEN"
  192.168.122.33:9696/v2.0/subnets/a18fb191-2a89-4193-80d1-5330a8052d64

  HTTP/1.1 204 No Content
  Content-Length: 0
  X-Openstack-Request-Id: req-901476cf-7e87-4b7c-ab20-209b81d2eb25
  Date: Fri, 30 Jun 2017 01:37:01 GMT

  $ curl -i -X DELETE -d '{"port": {"name": "aaa"}}' -H "content-
  type:application/json" -H 'accept:application/json' -H "x-auth-
  token:$TOKEN"
  192.168.122.33:9696/v2.0/ports/47f2c36a-7461-4c1a-a23e-931d5aee3f9c

  HTTP/1.1 204 No Content
  Content-Length: 0
  X-Openstack-Request-Id: req-48452706-6309-42c2-ac80-f0f4e387060e
  Date: Fri, 30 Jun 2017 01:37:33 GMT

  $ curl -i -X DELETE -d '{"subnetpool": {"description": "aaa"}}' -H
  "content-type:application/json" -H 'accept:application/json' -H
  "x-auth-token:$TOKEN"
  192.168.122.33:9696/v2.0/subnetpools/e0e09ffc-a4af-4cf0-ac2e-7a8b1475cef6

  HTTP/1.1 204 No Content
  Content-Length: 0
  X-Openstack-Request-Id: req-9601a3ae-74a0-49ca-9f99-02ad624ceacb
  Date: Fri, 30 Jun 2017 06:24:58 GMT

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1701410/+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 2056230] [NEW] clouds.yaml file documentation is misleading

2024-03-05 Thread Chris

Public bug reported:

The cloud.yaml.template at
https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/api_access/templates/api_access/clouds.yaml.template
states that if I only have one cloud I don't need to set OS_CLOUD or
--os_cloud=...
I found this to be incorrect. I needed to set OS_CLOUD even with a single cloud
listed in ~/.config/openstack/clouds.yaml. Its possible I'm using it wrong. Its
possible I'm using an outdated client, but I wasted 30minutes banging my head
against this and it would be nice if we could save someone else the same wasted
30 minutes.

** 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/2056230

Title:
clouds.yaml file documentation is misleading

Status in OpenStack Dashboard (Horizon):
New

Bug description:
The cloud.yaml.template at
https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/api_access/templates/api_access/clouds.yaml.template
states that if I only have one cloud I don't need to set OS_CLOUD or
--os_cloud=...
I found this to be incorrect. I needed to set OS_CLOUD even with a single
cloud listed in ~/.config/openstack/clouds.yaml. Its possible I'm using it
wrong. Its possible I'm using an outdated client, but I wasted 30minutes
banging my head against this and it would be nice if we could save someone else
the same wasted 30 minutes.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/2056230/+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 1865453] Re: neutron.tests.functional.plugins.ml2.drivers.ovn.mech_driver.test_mech_driver.TestVirtualPorts.test_virtual_port_created_before fails randomly

2024-03-05 Thread Brian Haley

** Changed in: neutron
 Assignee: Adil Ishaq (iradvisor) => (unassigned)

** Changed in: identity-management
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1865453

Title:
  
neutron.tests.functional.plugins.ml2.drivers.ovn.mech_driver.test_mech_driver.TestVirtualPorts.test_virtual_port_created_before
  fails randomly

Status in Identity Management:
  Invalid
Status in neutron:
  Confirmed

Bug description:
  Sometimes we see random failures of the test:

  
neutron.tests.functional.plugins.ml2.drivers.ovn.mech_driver.test_mech_driver.TestVirtualPorts.test_virtual_port_created_before

  
  
neutron.tests.functional.plugins.ml2.drivers.ovn.mech_driver.test_mech_driver.TestVirtualPorts.test_virtual_port_created_beforetesttools.testresult.real._StringException:
 Traceback (most recent call last):
File 
"/home/zuul/src/opendev.org/openstack/neutron/.tox/dsvm-functional/lib/python3.6/site-packages/mock/mock.py",
 line 1330, in patched
  return func(*args, **keywargs)
File "/home/zuul/src/opendev.org/openstack/neutron/neutron/tests/base.py", 
line 182, in func
  return f(self, *args, **kwargs)
File 
"/home/zuul/src/opendev.org/openstack/neutron/neutron/tests/functional/plugins/ml2/drivers/ovn/mech_driver/test_mech_driver.py",
 line 280, in test_virtual_port_created_before
  ovn_vport.options[ovn_const.LSP_OPTIONS_VIRTUAL_PARENTS_KEY])
File 
"/home/zuul/src/opendev.org/openstack/neutron/.tox/dsvm-functional/lib/python3.6/site-packages/testtools/testcase.py",
 line 417, in assertIn
  self.assertThat(haystack, Contains(needle), message)
File 
"/home/zuul/src/opendev.org/openstack/neutron/.tox/dsvm-functional/lib/python3.6/site-packages/testtools/testcase.py",
 line 498, in assertThat
  raise mismatch_error
  testtools.matchers._impl.MismatchError: 
'88c0378b-71bd-454b-a0df-8c70b57d257a' not in 
'49043b88-554f-48d0-888d-eeaa749e752f'

To manage notifications about this bug go to:
https://bugs.launchpad.net/identity-management/+bug/1865453/+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

35 matches

Mail list logo