[Yahoo-eng-team] [Bug 1669875] Re: identify openstack vmware platform
** Changed in: nova Status: Confirmed => Fix Released -- 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/1669875 Title: identify openstack vmware platform Status in cloud-init: Fix Released Status in OpenStack Compute (nova): Fix Released Bug description: We need a way to identify locally that we are running on openstack when inside a guest of VmWare. Related bugs: https://bugs.launchpad.net/cloud-init/+bugs?field.tag=dsid-nova To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1669875/+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 1425974] Re: SSH on instance does'nt return the shell
[Expired for Ubuntu because there has been no activity for 60 days.] ** Changed in: ubuntu Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1425974 Title: SSH on instance does'nt return the shell Status in neutron: Expired Status in Ubuntu: Expired Bug description: I've installed Openstack Juno (fresh install, two weeks ago). The ping from any network to instances works, but I have an issue with SSH (from any host). I tried with and without SSH keys, and that's the same problem. I tried with Cirros and Ubuntu14.04 instances. The ssh command seems working, but the host never returns the shell prompt... : root@networkc:~# ssh -vvv user@192.168.60.X OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 192.168.60.X [192.168.60.X] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: identity file /root/.ssh/id_ecdsa-cert type -1 debug1: identity file /root/.ssh/id_ed25519 type -1 debug1: identity file /root/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 pat OpenSSH_6.6.1* compat 0x0400 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent On the instance, 'netstat -laputen' notifies that a new connection is established, and then : Proto Recv-Q Sens-QAdresse locale Adresse distante Etat User tcp 01648 192.168.60.X:22 10.X.X.X 0777/sshd [accepted] At the end, my host displays "Connection timed out". I suppose it's a Neutron problem (connection speed or other...). I tried to use the Network Namespace of the concerned instance, but I had the same problem. EDIT : With KVM (and default network), the same Qcow2 image has not this problem. I think, it's not a SSH program issue. I can SSH correctly only to the instances connected on the physical network. Even from an instance with both network, this instance is only SSH-reachable from his external IP... To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1425974/+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 1425974] Re: SSH on instance does'nt return the shell
[Expired for neutron because there has been no activity for 60 days.] ** Changed in: neutron Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1425974 Title: SSH on instance does'nt return the shell Status in neutron: Expired Status in Ubuntu: Expired Bug description: I've installed Openstack Juno (fresh install, two weeks ago). The ping from any network to instances works, but I have an issue with SSH (from any host). I tried with and without SSH keys, and that's the same problem. I tried with Cirros and Ubuntu14.04 instances. The ssh command seems working, but the host never returns the shell prompt... : root@networkc:~# ssh -vvv user@192.168.60.X OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 192.168.60.X [192.168.60.X] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: identity file /root/.ssh/id_ecdsa-cert type -1 debug1: identity file /root/.ssh/id_ed25519 type -1 debug1: identity file /root/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 pat OpenSSH_6.6.1* compat 0x0400 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent On the instance, 'netstat -laputen' notifies that a new connection is established, and then : Proto Recv-Q Sens-QAdresse locale Adresse distante Etat User tcp 01648 192.168.60.X:22 10.X.X.X 0777/sshd [accepted] At the end, my host displays "Connection timed out". I suppose it's a Neutron problem (connection speed or other...). I tried to use the Network Namespace of the concerned instance, but I had the same problem. EDIT : With KVM (and default network), the same Qcow2 image has not this problem. I think, it's not a SSH program issue. I can SSH correctly only to the instances connected on the physical network. Even from an instance with both network, this instance is only SSH-reachable from his external IP... To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1425974/+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 1850736] [NEW] MemoryPageSizeInvalid: Invalid memory page size
Public bug reported: 1st step: I install openstack via comand of "packstack --answer- file=answer.cfg --debug", my openstack version is liberty. 2nd step: Generate publicExtnet neutron via command of "net-create --tenant-id * publicExtnet --provider:network_type vlan --provider:physical_network physnet0 --provider:segmentation_id 500 --router:external=True" 3rd step: update cinder quota via command of "cinder quota-update --volumes 100 *" 4th step: update neutron quota via command of "nova quota-update --instances 50 ***" 5th step: update neutron quota via command of "neutron quota-update --network 50" 6th step: glance image-create --name --disk-format qcow2 --container-format bare --file ./image/*** heat stack-create -f flavors/flavors.hot.yaml -e flavors/flavors.env.yaml flavors heat stack-create -f networks/networks.hot.yaml -e networks/networks.env.yaml networks Create zone openstack volume create --size 100 --property attached_mode='rw' --property readonly='False' backup 7th step: heat stack-create -f servers/servers.hot.yaml -e servers/servers.env.yaml -Pf net=../jsondata/net.json -Pf net_id=../jsondata/net_id.json -P public_net=no_value ** Affects: nova Importance: Undecided Status: New ** Attachment added: "nova-api.log" https://bugs.launchpad.net/bugs/1850736/+attachment/5301586/+files/nova-api.log -- 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/1850736 Title: MemoryPageSizeInvalid: Invalid memory page size Status in OpenStack Compute (nova): New Bug description: 1st step: I install openstack via comand of "packstack --answer- file=answer.cfg --debug", my openstack version is liberty. 2nd step: Generate publicExtnet neutron via command of "net-create --tenant-id * publicExtnet --provider:network_type vlan --provider:physical_network physnet0 --provider:segmentation_id 500 --router:external=True" 3rd step: update cinder quota via command of "cinder quota-update --volumes 100 *" 4th step: update neutron quota via command of "nova quota-update --instances 50 ***" 5th step: update neutron quota via command of "neutron quota-update --network 50" 6th step: glance image-create --name --disk-format qcow2 --container-format bare --file ./image/*** heat stack-create -f flavors/flavors.hot.yaml -e flavors/flavors.env.yaml flavors heat stack-create -f networks/networks.hot.yaml -e networks/networks.env.yaml networks Create zone openstack volume create --size 100 --property attached_mode='rw' --property readonly='False' backup 7th step: heat stack-create -f servers/servers.hot.yaml -e servers/servers.env.yaml -Pf net=../jsondata/net.json -Pf net_id=../jsondata/net_id.json -P public_net=no_value To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1850736/+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 1850735] [NEW] time.sleep(10) in server group func tests
Public bug reported: In the server group functional tests in nova/tests/functional/test_server_group.py there are several places where time.sleep(10) is called in order to make sure a stopped compute service is considered "down" by the nova compute API. Instead of sleeping, we can set the service as "forced_down" to get the desired "down" compute service status and avoid unnecessary delays in these tests. ** Affects: nova Importance: Undecided Assignee: melanie witt (melwitt) Status: In Progress ** Tags: testing -- 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/1850735 Title: time.sleep(10) in server group func tests Status in OpenStack Compute (nova): In Progress Bug description: In the server group functional tests in nova/tests/functional/test_server_group.py there are several places where time.sleep(10) is called in order to make sure a stopped compute service is considered "down" by the nova compute API. Instead of sleeping, we can set the service as "forced_down" to get the desired "down" compute service status and avoid unnecessary delays in these tests. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1850735/+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 1754104] Re: install guide: keystone_authtoken/auth_url shows incorrect port
** Changed in: cinder Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1754104 Title: install guide: keystone_authtoken/auth_url shows incorrect port Status in Cinder: Fix Released Status in Glance: Fix Released Status in Glance queens series: Fix Released Status in OpenStack Heat: In Progress Status in Manila: Fix Released Status in OpenStack Object Storage (swift): 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 code shown for the keystone_authtoken needs an update regarding the ports for queens. Following the guides, keystone only listens on port 5000 instead of 5000 & 35357 - [ ] This is a doc addition request. - [x] I have a fix to the document that I can paste below including example: input and output. Input: [keystone_authtoken] # ... auth_uri = http://controller:5000 auth_url = http://controller:35357 memcached_servers = controller:11211 auth_type = password project_domain_name = default user_domain_name = default project_name = service username = glance password = GLANCE_PASS output: [keystone_authtoken] # ... auth_uri = http://controller:5000 auth_url = http://controller:5000 memcached_servers = controller:11211 auth_type = password project_domain_name = default user_domain_name = default project_name = service username = glance password = GLANCE_PASS 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: 16.0.1.dev1 on 'Thu Mar 1 07:26:57 2018, commit 968f4ae' SHA: 968f4ae9ce244d9372cb3e8f45acea9d557f317d Source: https://git.openstack.org/cgit/openstack/glance/tree/doc/source/install/install-ubuntu.rst URL: https://docs.openstack.org/glance/queens/install/install-ubuntu.html To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1754104/+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 1850694] [NEW] shelve doesn't handle UnexpectedTaskStateError
Public bug reported:
Description
===
Shelving a server expects its task state to be None. If it's not None
(for example, if attempting to shelve a server that's already being
shelved), we get a UnexpectedTaskStateError from the database layer and
return a 500 to the user. A 409 would be more appropriate.
Steps to reproduce
==
1. Send multiple shelve requests in quick succession.
Expected result
===
The initial request should be accepted, the rest should return 409.
Actual result
=
Error 500 for all requests except the first.
Environment
===
This was reported on OSP13 (Queens) originally [1].
Logs & Configs
==
2019-05-28 03:18:48.530 26 INFO nova.osapi_compute.wsgi.server
[req-1437e513-3e32-4243-8f5d-1a7e17c111df 3ff59a48497842e7a716a03a17e5bf8b
493b17f3b02b4f9ea6e71b1ae4c5ac5d - e4c6faf4dfb04f2da40c0595f1a424c7
e4c6faf4dfb04f2da40c0595f1a424c7] 10.101.4.137,10.101.4.1 "POST
/v2.1/493b17f3b02b4f9ea6e71b1ae4c5ac5d/servers/f905b880-9caa-465e-93c5-fffe9192c825/action
HTTP/1.1" status: 500 len: 622 time: 0.1237578
2019-05-28 03:18:48.529 26 INFO nova.api.openstack.wsgi
[req-1437e513-3e32-4243-8f5d-1a7e17c111df 3ff59a48497842e7a716a03a17e5bf8b
493b17f3b02b4f9ea6e71b1ae4c5ac5d - e4c6faf4dfb04f2da40c0595f1a424c7
e4c6faf4dfb04f2da40c0595f1a424c7] HTTP exception thrown: Unexpected API Error.
Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API
log if possible.
2019-05-28 03:18:48.529 26 DEBUG nova.api.openstack.wsgi
[req-1437e513-3e32-4243-8f5d-1a7e17c111df 3ff59a48497842e7a716a03a17e5bf8b
493b17f3b02b4f9ea6e71b1ae4c5ac5d - e4c6faf4dfb04f2da40c0595f1a424c7
e4c6faf4dfb04f2da40c0595f1a424c7] Returning 500 to user: Unexpected API Error.
Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API
log if possible.
__call__
/usr/lib/python2.7/site-packages/nova/api/openstack/wsgi.py:1064
2019-05-28 03:18:48.523 26 ERROR nova.api.openstack.wsgi
[req-1437e513-3e32-4243-8f5d-1a7e17c111df 3ff59a48497842e7a716a03a17e5bf8b
493b17f3b02b4f9ea6e71b1ae4c5ac5d - e4c6faf4dfb04f2da40c0595f1a424c7
e4c6faf4dfb04f2da40c0595f1a424c7] Unexpected exception in API method:
UnexpectedTaskStateError: Conflict updating instance
f905b880-9caa-465e-93c5-fffe9192c825. Expected: {'task_state': [None]}. Actual:
{'task_state': u'shelving'}
2019-05-28 03:18:48.523 26 ERROR nova.api.openstack.wsgi Traceback (most recent
call last):
2019-05-28 03:18:48.523 26 ERROR nova.api.openstack.wsgi File
"/usr/lib/python2.7/site-packages/nova/api/openstack/wsgi.py", line 788, in
wrapped
2019-05-28 03:18:48.523 26 ERROR nova.api.openstack.wsgi return f(*args,
**kwargs)
2019-05-28 03:18:48.523 26 ERROR nova.api.openstack.wsgi File
"/usr/lib/python2.7/site-packages/nova/api/openstack/compute/shelve.py", line
43, in _shelve
2019-05-28 03:18:48.523 26 ERROR nova.api.openstack.wsgi
self.compute_api.shelve(context, instance)
2019-05-28 03:18:48.523 26 ERROR nova.api.openstack.wsgi File
"/usr/lib/python2.7/site-packages/nova/compute/api.py", line 204, in inner
2019-05-28 03:18:48.523 26 ERROR nova.api.openstack.wsgi return
function(self, context, instance, *args, **kwargs)
2019-05-28 03:18:48.523 26 ERROR nova.api.openstack.wsgi File
"/usr/lib/python2.7/site-packages/nova/compute/api.py", line 152, in inner
2019-05-28 03:18:48.523 26 ERROR nova.api.openstack.wsgi return f(self,
context, instance, *args, **kw)
2019-05-28 03:18:48.523 26 ERROR nova.api.openstack.wsgi File
"/usr/lib/python2.7/site-packages/nova/compute/api.py", line 3518, in shelve
2019-05-28 03:18:48.523 26 ERROR nova.api.openstack.wsgi
instance.save(expected_task_state=[None])
2019-05-28 03:18:48.523 26 ERROR nova.api.openstack.wsgi File
"/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py", line 226, in
wrapper
2019-05-28 03:18:48.523 26 ERROR nova.api.openstack.wsgi return fn(self,
*args, **kwargs)
2019-05-28 03:18:48.523 26 ERROR nova.api.openstack.wsgi File
"/usr/lib/python2.7/site-packages/nova/objects/instance.py", line 826, in save
2019-05-28 03:18:48.523 26 ERROR nova.api.openstack.wsgi
columns_to_join=_expected_cols(expected_attrs))
2019-05-28 03:18:48.523 26 ERROR nova.api.openstack.wsgi File
"/usr/lib/python2.7/site-packages/nova/db/api.py", line 890, in
instance_update_and_get_original
2019-05-28 03:18:48.523 26 ERROR nova.api.openstack.wsgi expected=expected)
2019-05-28 03:18:48.523 26 ERROR nova.api.openstack.wsgi File
"/usr/lib/python2.7/site-packages/nova/db/sqlalchemy/api.py", line 169, in
wrapper
2019-05-28 03:18:48.523 26 ERROR nova.api.openstack.wsgi return f(*args,
**kwargs)
2019-05-28 03:18:48.523 26 ERROR nova.api.openstack.wsgi File
"/usr/lib/python2.7/site-packages/oslo_db/api.py", line 147, in wrapper
2019-05-28 03:18:48.523 26 ERROR nova.api.openstack.wsgi ectxt.value =
e.inner_exc
2019-05-28 03:18:48.523 26 ERROR nova.api.openstack.wsgi
[Yahoo-eng-team] [Bug 1850682] [NEW] functional tests in rocky randomly fail with "Build of instance was re-scheduled: Cannot modify readonly field uuid"
Public bug reported: Seen here: https://561c74891cdc1994ef28-bf4df36ee9e72417a89c120068385812.ssl.cf2.rackcdn.com/690721/4/check /nova-tox-functional/5b7bec9/testr_results.html.gz >From logstash this is probably the earliest patch to hit it: https://review.opendev.org/#/c/687563/ http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22was %20re- scheduled%3A%20Cannot%20modify%20readonly%20field%20uuid%5C%22%20AND%20tags%3A%5C%22console%5C%22=7d Without something like this https://review.opendev.org/#/c/669545/ we can't tell where the original error is coming from though. ** Affects: nova Importance: Undecided Status: Confirmed ** Tags: compute gate-failure serviceability testing ** Changed in: nova Status: New => Confirmed -- 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/1850682 Title: functional tests in rocky randomly fail with "Build of instance was re-scheduled: Cannot modify readonly field uuid" Status in OpenStack Compute (nova): Confirmed Bug description: Seen here: https://561c74891cdc1994ef28-bf4df36ee9e72417a89c120068385812.ssl.cf2.rackcdn.com/690721/4/check /nova-tox-functional/5b7bec9/testr_results.html.gz From logstash this is probably the earliest patch to hit it: https://review.opendev.org/#/c/687563/ http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22was %20re- scheduled%3A%20Cannot%20modify%20readonly%20field%20uuid%5C%22%20AND%20tags%3A%5C%22console%5C%22=7d Without something like this https://review.opendev.org/#/c/669545/ we can't tell where the original error is coming from though. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1850682/+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 1593155] Re: over_committed_disk_size is wrong for sparse flat files
*** This bug is a duplicate of bug 1764489 *** https://bugs.launchpad.net/bugs/1764489 ** This bug has been marked a duplicate of bug 1764489 Preallocated disks are deducted twice from disk_available_least when using preallocated_images = space -- 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/1593155 Title: over_committed_disk_size is wrong for sparse flat files Status in OpenStack Compute (nova): In Progress Bug description: The libvirt driver creates flat disks as sparse by default. However, it always returns over_committed_disk_size=0 for flat disks in _get_instance_disk_info(). This incorrect data ends up being reported to the scheduler in the libvirt driver's get_available_resource() via _get_disk_over_committed_size_total(). _get_instance_disk_info() should use allocated blocks, not file size, when calculating over_commited_disk_size for flat disks. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1593155/+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 1663456] Re: Field 'updated_at' always 'None' when show aggregate
This could probably be considered the same as bug 1719561.
** Changed in: nova
Status: Opinion => Confirmed
** Changed in: nova
Importance: Wishlist => Low
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1663456
Title:
Field 'updated_at' always 'None' when show aggregate
Status in OpenStack Compute (nova):
Confirmed
Bug description:
Description
===
When i got detailed info of one host aggregate with CLI `openstack aggregate
show`,
the field 'updated_at' always was 'None'.
Steps to reproduce
==
* Create one host aggregate with CLI `openstack aggregate create t-sh`
* Set some properties for the aggregate with CLI `openstack aggregate set
--zone tztz --property foo=bar agg-sh`
* Get detailed info of the aggregate with CLI `openstack aggregate show
agg-sh`
Expected result
===
| updated_at| 2017-02-10T03:27:25.535045 |
Actual result
=
| updated_at| None |
Environment
===
1. nova version
[root@controller nova]# git log
commit 50d402821be7476eb58ccd791c50d8ed801e85eb
Author: Matt Riedemann
Date: Wed Feb 8 10:23:14 2017 -0500
Consider startup scenario in _get_compute_nodes_in_db
2. Which hypervisor did you use?
devstack + libvirt + kvm
Logs
==
Enable --debug in openstack command.
* Set some properties for the aggregate with '--debug'.
RESP BODY: {"aggregate": {"name": "agg-sh", "availability_zone": "tztz",
"deleted": false, "created_at": "2017-02-10T03:26:21.00", "updated_at":
"2017-02-10T03:27:25.535045", "hosts": [], "deleted_at": null, "id": 4,
"metadata": {"foo": "bar", "availability_zone": "tztz"}}}
Note: field 'updated_at' has valid value.
* Get detailed info with '--debug'
RESP BODY: {"aggregates": [{"name": "agg-1", "availability_zone": "tz1",
"deleted": false, "created_at": "2017-02-10T02:09:47.00", "updated_at":
null, "hosts": ["controller"], "deleted_at": null, "id": 1, "metadata":
{"color": "green", "foo": "bar", "availability_zone": "tz1"}}, {"name":
"agg-a", "availability_zone": "tz2", "deleted": false, "created_at":
"2017-02-10T02:39:15.00", "updated_at": null, "hosts": [], "deleted_at":
null, "id": 2, "metadata": {"foo": "tar", "availability_zone": "tz2"}},
{"name": "t-sh", "availability_zone": "tz3", "deleted": false, "created_at":
"2017-02-10T02:39:24.00", "updated_at": null, "hosts": [], "deleted_at":
null, "id": 3, "metadata": {"color": "blue", "hello": "world",
"availability_zone": "tz3"}}, {"name": "agg-sh", "availability_zone": "tztz",
"deleted": false, "created_at": "2017-02-10T03:26:21.00", "updated_at":
null, "hosts": [], "deleted_at": null, "id": 4, "metadata": {"foo": "bar",
"availability_zone": "tztz"}}]}
Note: field 'updated_at' is null.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1663456/+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 1663456] Re: Field 'updated_at' always 'None' when show aggregate
** Changed in: nova
Importance: Medium => Wishlist
** Changed in: nova
Status: In Progress => Opinion
** Changed in: nova
Assignee: Vishakha Agarwal (vishakha.agarwal) => (unassigned)
--
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/1663456
Title:
Field 'updated_at' always 'None' when show aggregate
Status in OpenStack Compute (nova):
Confirmed
Bug description:
Description
===
When i got detailed info of one host aggregate with CLI `openstack aggregate
show`,
the field 'updated_at' always was 'None'.
Steps to reproduce
==
* Create one host aggregate with CLI `openstack aggregate create t-sh`
* Set some properties for the aggregate with CLI `openstack aggregate set
--zone tztz --property foo=bar agg-sh`
* Get detailed info of the aggregate with CLI `openstack aggregate show
agg-sh`
Expected result
===
| updated_at| 2017-02-10T03:27:25.535045 |
Actual result
=
| updated_at| None |
Environment
===
1. nova version
[root@controller nova]# git log
commit 50d402821be7476eb58ccd791c50d8ed801e85eb
Author: Matt Riedemann
Date: Wed Feb 8 10:23:14 2017 -0500
Consider startup scenario in _get_compute_nodes_in_db
2. Which hypervisor did you use?
devstack + libvirt + kvm
Logs
==
Enable --debug in openstack command.
* Set some properties for the aggregate with '--debug'.
RESP BODY: {"aggregate": {"name": "agg-sh", "availability_zone": "tztz",
"deleted": false, "created_at": "2017-02-10T03:26:21.00", "updated_at":
"2017-02-10T03:27:25.535045", "hosts": [], "deleted_at": null, "id": 4,
"metadata": {"foo": "bar", "availability_zone": "tztz"}}}
Note: field 'updated_at' has valid value.
* Get detailed info with '--debug'
RESP BODY: {"aggregates": [{"name": "agg-1", "availability_zone": "tz1",
"deleted": false, "created_at": "2017-02-10T02:09:47.00", "updated_at":
null, "hosts": ["controller"], "deleted_at": null, "id": 1, "metadata":
{"color": "green", "foo": "bar", "availability_zone": "tz1"}}, {"name":
"agg-a", "availability_zone": "tz2", "deleted": false, "created_at":
"2017-02-10T02:39:15.00", "updated_at": null, "hosts": [], "deleted_at":
null, "id": 2, "metadata": {"foo": "tar", "availability_zone": "tz2"}},
{"name": "t-sh", "availability_zone": "tz3", "deleted": false, "created_at":
"2017-02-10T02:39:24.00", "updated_at": null, "hosts": [], "deleted_at":
null, "id": 3, "metadata": {"color": "blue", "hello": "world",
"availability_zone": "tz3"}}, {"name": "agg-sh", "availability_zone": "tztz",
"deleted": false, "created_at": "2017-02-10T03:26:21.00", "updated_at":
null, "hosts": [], "deleted_at": null, "id": 4, "metadata": {"foo": "bar",
"availability_zone": "tztz"}}]}
Note: field 'updated_at' is null.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1663456/+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 1850642] Re: Cloud init unable to find the metadata service but can CURL it
** This bug is no longer a duplicate of bug 1821102 Cloud-init should not setup ephemeral ipv4 if apply_network_config is False for OpenStack -- 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/1850642 Title: Cloud init unable to find the metadata service but can CURL it Status in cloud-init: New Bug description: In a tripleo Rocky deployment I am seeing the behaviour bellow. In the bootup logs I see that the metadata service could not be reached. File "/usr/lib/python2.7/site-packages/cloudinit/sources/DataSourceOpenStack.py", line 177, in _crawl_metadata 'No active metadata service found') However the service is curlable from inside the VM and I am also seeing some requests in the metadata-service in Openstack. Furthemore I am getting SSH keys inserted so I believe this might be a false warning. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1850642/+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 1850642] Re: Cloud init unable to find the metadata service but can CURL it
*** This bug is a duplicate of bug 1821102 ***
https://bugs.launchpad.net/bugs/1821102
The logs do contain that bug, but I'm not sure that's the failure here.
Looking at the cloud-init logs, we can see the Ephemeral DHCP start and
obtain an lease, but the end point does not respond:
2019-10-30 13:28:41,516 - dhcp.py[DEBUG]: Received dhcp lease on eth0 for
136.156.90.74/255.255.254.0
2019-10-30 13:28:41,516 - __init__.py[DEBUG]: Attempting setup of ephemeral
network on eth0 with 136.156.90.74/23 brd 136.156.91.255
2019-10-30 13:28:41,516 - util.py[DEBUG]: Running command ['ip', '-family',
'inet', 'addr', 'add', '136.156.90.74/23', 'broadcast', '136.156.91.255',
'dev', 'eth0'] with allowed return codes [0] (shell=False, capture=True)
2019-10-30 13:28:41,519 - util.py[DEBUG]: Running command ['ip', '-family',
'inet', 'link', 'set', 'dev', 'eth0', 'up'] with allowed return codes [0]
(shell=False, capture=True)
2019-10-30 13:28:41,522 - util.py[DEBUG]: Running command ['ip', 'route',
'show', '0.0.0.0/0'] with allowed return codes [0] (shell=False, capture=True)
2019-10-30 13:28:41,525 - util.py[DEBUG]: Running command ['ip', '-4', 'route',
'add', '136.156.91.254', 'dev', 'eth0', 'src', '136.156.90.74'] with allowed
return codes [0] (shell=False, capture=True)
2019-10-30 13:28:41,527 - util.py[DEBUG]: Running command ['ip', '-4', 'route',
'add', 'default', 'via', '136.156.91.254', 'dev', 'eth0'] with allowed return
codes [0] (shell=False, capture=True)
2019-10-30 13:29:21,573 - util.py[DEBUG]: Resolving URL: http://169.254.169.254
took 40.044 seconds
2019-10-30 13:29:21,574 - url_helper.py[DEBUG]: [0/1] open
'http://169.254.169.254/openstack' with {'url':
'http://169.254.169.254/openstack', 'headers': {'User-Agent':
'Cloud-Init/18.5'}, 'allow_redirects': True, 'method': 'GET', 'timeout': 10.0}
configuration
2019-10-30 13:29:31,608 - url_helper.py[DEBUG]: Calling
'http://169.254.169.254/openstack' failed [10/-1s]: request error
[HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with
url: /openstack (Caused by
ConnectTimeoutError(, 'Connection to 169.254.169.254 timed out. (connect
timeout=10.0)'))]
2019-10-30 13:29:31,608 - DataSourceOpenStack.py[DEBUG]: Giving up on OpenStack
md from ['http://169.254.169.254/openstack'] after 10 seconds
2019-10-30 13:29:31,609 - util.py[DEBUG]: Crawl of metadata service took 50.079
seconds
Cloud-init did not find the OpenStack datasource at local time:
2019-10-30 13:29:31,689 - main.py[DEBUG]: No local datasource found
So we write out a fallback network config (dhcp on eth0).
2019-10-30 13:29:31,722 - stages.py[INFO]: Applying network configuration from
fallback bringup=False: {'version': 1, 'config': [{'subnets': [{'type':
'dhcp'}], 'type': 'physical', 'name': 'eth0', 'mac_address':
'fa:16:3e:f4:b5:1d'}]}
2019-10-30 13:29:31,723 - __init__.py[DEBUG]: Selected renderer 'sysconfig'
from priority list: None
2019-10-30 13:29:31,725 - util.py[DEBUG]: Writing to
/etc/sysconfig/network-scripts/ifcfg-eth0 - wb: [644] 159 bytes
2019-10-30 13:29:31,726 - util.py[DEBUG]: Restoring selinux mode for
/etc/sysconfig/network-scripts/ifcfg-eth0 (recursive=False)
2019-10-30 13:29:31,726 - util.py[DEBUG]: Restoring selinux mode for
/etc/sysconfig/network-scripts/ifcfg-eth0 (recursive=False)
And then exit cloud-init-local.service:
2019-10-30 13:29:31,730 - util.py[DEBUG]: cloud-init mode 'init' took
52.389 seconds (52.39)
Now, the OS networking layer comes up:
Oct 30 13:29:31.623535 localhost.localdomain cloud-init[732]: 2019-10-30
13:29:31,619 - util.py[WARNING]: No active metadata service found
Oct 30 13:29:31.751295 localhost.localdomain systemd[1]: Started Initial
cloud-init job (pre-networking).
Oct 30 13:29:31.754472 localhost.localdomain systemd[1]: Reached target Network
(Pre).
Oct 30 13:29:31.756812 localhost.localdomain systemd[1]: Starting LSB: Bring
up/down networking...
Oct 30 13:29:31.961050 localhost.localdomain network[866]: Bringing up loopback
interface: [ OK ]
Oct 30 13:29:31.990878 localhost.localdomain network[866]: Bringing up
interface eth0:
Oct 30 13:29:32.034411 localhost.localdomain dhclient[995]: DHCPDISCOVER on
eth0 to 255.255.255.255 port 67 interval 8 (xid=0xeceb89e)
Oct 30 13:29:32.055157 localhost.localdomain dhclient[995]: DHCPREQUEST on eth0
to 255.255.255.255 port 67 (xid=0xeceb89e)
Oct 30 13:29:32.055188 localhost.localdomain dhclient[995]: DHCPOFFER from
136.156.90.11
Oct 30 13:29:32.055796 localhost.localdomain dhclient[995]: DHCPACK from
136.156.90.11 (xid=0xeceb89e)
Oct 30 13:29:34.132189 localhost.localdomain NET[1054]:
/usr/sbin/dhclient-script : updated /etc/resolv.conf
Oct 30 13:29:34.166284 host-136-156-90-74 dhclient[995]: bound to 136.156.90.74
-- renewal in 34571 seconds.
Oct 30 13:29:34.167466 host-136-156-90-74 network[866]: Determining IP
information for eth0... done.
Oct 30 13:29:34.224637 host-136-156-90-74 network[866]: [ OK ]
Oct 30 13:29:34.245397
[Yahoo-eng-team] [Bug 1850642] [NEW] Cloud init unable to find the metadata service but can CURL it
Public bug reported: In a tripleo Rocky deployment I am seeing the behaviour bellow. In the bootup logs I see that the metadata service could not be reached. File "/usr/lib/python2.7/site-packages/cloudinit/sources/DataSourceOpenStack.py", line 177, in _crawl_metadata 'No active metadata service found') However the service is curlable from inside the VM and I am also seeing some requests in the metadata-service in Openstack. Furthemore I am getting SSH keys inserted so I believe this might be a false warning. ** Affects: cloud-init Importance: Undecided Status: New ** Attachment added: "cloud-init.tar.gz" https://bugs.launchpad.net/bugs/1850642/+attachment/5301400/+files/cloud-init.tar.gz -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1850642 Title: Cloud init unable to find the metadata service but can CURL it Status in cloud-init: New Bug description: In a tripleo Rocky deployment I am seeing the behaviour bellow. In the bootup logs I see that the metadata service could not be reached. File "/usr/lib/python2.7/site-packages/cloudinit/sources/DataSourceOpenStack.py", line 177, in _crawl_metadata 'No active metadata service found') However the service is curlable from inside the VM and I am also seeing some requests in the metadata-service in Openstack. Furthemore I am getting SSH keys inserted so I believe this might be a false warning. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1850642/+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 1850639] [NEW] FloatingIP list bad performance
Public bug reported:
Faced on stable/queens but applicable to master too.
On quite a heavy loaded environment it was noticed that simple floatingip list
command takes significant time (~1200 fips) while for example port list is
always faster (>7000 ports).
If enable sqlalchemy debug logs there can be seen lots of:
2019-10-22 21:02:44,977.977 23957 DEBUG sqlalchemy.orm.path_registry
[req-3db31d53-f6b9-408e-b8c7-bf037ef10a1b 1df8a7d5eb
b5414b9e29cf581098681c 10479799101a4fe4ada17daa105707c5 - default default] set
'memoized_setups' on path 'EntityRegistry(
(,))' to '{}' set
/usr/lib/python2.7/dist-packages/sqlalchemy/orm/path_registry.
py:63
- which basically eats all the time of a request.
As a test I commented 'dns' field in FloatingIP DB object definition and
response time reduced from 14 to 1 second. DNS extension is not configured on
the environment and no external DNS is used.
Also I don't see this field used anywhere in neutron.
Interestingly Port DB object has 'dns' field either (with corresponding
portdnses table in DB, all the same as done for floatingips), however DB
object is not used when listing ports.
The proposal would be to remove 'dns' field from FloatingIP OVO as not
used, until we find performance bottleneck.
** Affects: neutron
Importance: High
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/1850639
Title:
FloatingIP list bad performance
Status in neutron:
New
Bug description:
Faced on stable/queens but applicable to master too.
On quite a heavy loaded environment it was noticed that simple floatingip
list command takes significant time (~1200 fips) while for example port list is
always faster (>7000 ports).
If enable sqlalchemy debug logs there can be seen lots of:
2019-10-22 21:02:44,977.977 23957 DEBUG sqlalchemy.orm.path_registry
[req-3db31d53-f6b9-408e-b8c7-bf037ef10a1b 1df8a7d5eb
b5414b9e29cf581098681c 10479799101a4fe4ada17daa105707c5 - default default]
set 'memoized_setups' on path 'EntityRegistry(
(,))' to '{}' set
/usr/lib/python2.7/dist-packages/sqlalchemy/orm/path_registry.
py:63
- which basically eats all the time of a request.
As a test I commented 'dns' field in FloatingIP DB object definition and
response time reduced from 14 to 1 second. DNS extension is not configured on
the environment and no external DNS is used.
Also I don't see this field used anywhere in neutron.
Interestingly Port DB object has 'dns' field either (with
corresponding portdnses table in DB, all the same as done for
floatingips), however DB object is not used when listing ports.
The proposal would be to remove 'dns' field from FloatingIP OVO as not
used, until we find performance bottleneck.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1850639/+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 1850634] Re: stable/queens regresion - _dn_to_id() should still be using utf8_encode/utf8_decode in queens
** Also affects: keystone (Ubuntu) Importance: Undecided Status: New ** Also affects: keystone (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: keystone (Ubuntu) Status: New => Invalid ** Changed in: keystone (Ubuntu Bionic) Status: New => Triaged ** Changed in: keystone (Ubuntu Bionic) Importance: Undecided => High ** Also affects: cloud-archive Importance: Undecided Status: New ** Also affects: cloud-archive/queens Importance: Undecided Status: New ** Changed in: cloud-archive Status: New => Invalid ** Changed in: cloud-archive/queens Status: New => Triaged ** Changed in: cloud-archive/queens Importance: Undecided => High ** Changed in: cloud-archive/queens Assignee: (unassigned) => Corey Bryant (corey.bryant) ** Changed in: keystone (Ubuntu Bionic) Assignee: (unassigned) => Corey Bryant (corey.bryant) -- 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/1850634 Title: stable/queens regresion - _dn_to_id() should still be using utf8_encode/utf8_decode in queens Status in Ubuntu Cloud Archive: Invalid Status in Ubuntu Cloud Archive queens series: Triaged Status in OpenStack Identity (keystone): New Status in keystone package in Ubuntu: Invalid Status in keystone source package in Bionic: Triaged Bug description: There's a regression in the LDAP common backend code due to a recent stable/queens backport that shouldn't have been backported past stable/rocky. The following patch shouldn't have been backported to stable/queens: https://review.opendev.org/#/c/672519/ The reason why is because the following patch, which switched to bytes_mode=False, doesn't exist in stable/queens: https://review.opendev.org/#/c/613648/ In particular see the changes to _dn_to_id() in https://review.opendev.org/#/c/613648/4/keystone/identity/backends/ldap/common.py. Those changes didn't happen in stable/queens so _dn_to_id should still be UTF-8 encoding/decoding the appropriate fields. In other words it should still be using the following in stable/queens: def _dn_to_id(self, dn): # Check if the naming attribute in the DN is the same as keystone's # configured 'id' attribute'. If so, extract the ID value from the DN if self.id_attr == utf8_decode( ldap.dn.str2dn(utf8_encode(dn))[0][0][0].lower()): return utf8_decode(ldap.dn.str2dn(utf8_encode(dn))[0][0][1]) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1850634/+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 1850634] [NEW] stable/queens regresion - _dn_to_id() should still be using utf8_encode/utf8_decode in queens
Public bug reported: There's a regression in the LDAP common backend code due to a recent stable/queens backport that shouldn't have been backported past stable/rocky. The following patch shouldn't have been backported to stable/queens: https://review.opendev.org/#/c/672519/ The reason why is because the following patch, which switched to bytes_mode=False, doesn't exist in stable/queens: https://review.opendev.org/#/c/613648/ In particular see the changes to _dn_to_id() in https://review.opendev.org/#/c/613648/4/keystone/identity/backends/ldap/common.py. Those changes didn't happen in stable/queens so _dn_to_id should still be UTF-8 encoding/decoding the appropriate fields. In other words it should still be using the following in stable/queens: def _dn_to_id(self, dn): # Check if the naming attribute in the DN is the same as keystone's # configured 'id' attribute'. If so, extract the ID value from the DN if self.id_attr == utf8_decode( ldap.dn.str2dn(utf8_encode(dn))[0][0][0].lower()): return utf8_decode(ldap.dn.str2dn(utf8_encode(dn))[0][0][1]) ** Affects: keystone Importance: Undecided Status: New ** Affects: keystone (Ubuntu) Importance: Undecided Status: Invalid ** Affects: keystone (Ubuntu Bionic) Importance: Undecided Status: New -- 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/1850634 Title: stable/queens regresion - _dn_to_id() should still be using utf8_encode/utf8_decode in queens Status in OpenStack Identity (keystone): New Status in keystone package in Ubuntu: Invalid Status in keystone source package in Bionic: New Bug description: There's a regression in the LDAP common backend code due to a recent stable/queens backport that shouldn't have been backported past stable/rocky. The following patch shouldn't have been backported to stable/queens: https://review.opendev.org/#/c/672519/ The reason why is because the following patch, which switched to bytes_mode=False, doesn't exist in stable/queens: https://review.opendev.org/#/c/613648/ In particular see the changes to _dn_to_id() in https://review.opendev.org/#/c/613648/4/keystone/identity/backends/ldap/common.py. Those changes didn't happen in stable/queens so _dn_to_id should still be UTF-8 encoding/decoding the appropriate fields. In other words it should still be using the following in stable/queens: def _dn_to_id(self, dn): # Check if the naming attribute in the DN is the same as keystone's # configured 'id' attribute'. If so, extract the ID value from the DN if self.id_attr == utf8_decode( ldap.dn.str2dn(utf8_encode(dn))[0][0][0].lower()): return utf8_decode(ldap.dn.str2dn(utf8_encode(dn))[0][0][1]) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1850634/+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 1850630] [NEW] firewall rule update validating func is not robust enough，missing considering the stock data
Public bug reported: When we try to update a firewall rule, both protocol and s/d_port could be modified. However, the validate func is not robust enough, missing considering the stock data. As a result: 1.some unavailable rules will probably be constructed. 2: When try to update s/d port, must input the current protocol e.g. 1.1.update r1(protocol:imcp, sport:None, dport:None) protocol to tcp, will get r1`(protocol:tcp, sport:None, dport:None), which is unavailable. 1.2.update r2(protocol:tcp, sport:123, dport:234) protocol to icmp, will get r2`(protocol:tcp, sport:None, dport:None), which is unavailable. 2. update r3(protocol:tcp, sport:123, dport:234) sport to 456, could not assign the sport only, otherwise the following execption will be raised: Source, destination port are not allowed when protocol is set to ICMP. ** 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/1850630 Title: firewall rule update validating func is not robust enough，missing considering the stock data Status in neutron: New Bug description: When we try to update a firewall rule, both protocol and s/d_port could be modified. However, the validate func is not robust enough, missing considering the stock data. As a result: 1.some unavailable rules will probably be constructed. 2: When try to update s/d port, must input the current protocol e.g. 1.1.update r1(protocol:imcp, sport:None, dport:None) protocol to tcp, will get r1`(protocol:tcp, sport:None, dport:None), which is unavailable. 1.2.update r2(protocol:tcp, sport:123, dport:234) protocol to icmp, will get r2`(protocol:tcp, sport:None, dport:None), which is unavailable. 2. update r3(protocol:tcp, sport:123, dport:234) sport to 456, could not assign the sport only, otherwise the following execption will be raised: Source, destination port are not allowed when protocol is set to ICMP. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1850630/+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 1850626] [NEW] neutron-dynamic-routing: TypeError: bind() takes 4 positional arguments but 5 were given
Public bug reported:
Neutron-dynamic-routing scenario jobs in neutron-tempest-plugin repo are
failing all the time since few days.
Example of failure
https://openstack.fortnebula.com:13808/v1/AUTH_e8fd161dc34c421a979a9e6421f823e9/zuul_opendev_logs_cee/691855/1/check
/neutron-tempest-plugin-dynamic-routing/cee3785/testr_results.html.gz
It seems that this happens due to error in service plugin, see neutron
server log:
Notify callbacks
['neutron_dynamic_routing.services.bgp.scheduler.bgp_dragent_scheduler.BgpDrAgentSchedulerBase.schedule_bgp_speaker_callback--9223372036854649727']
for bgp_speaker, after_create {{(pid=19640) _notify_loop
/usr/local/lib/python3.6/dist-packages/neutron_lib/callbacks/manager.py:193}}
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860 neutron-server[19534]:
ERROR neutron_lib.callbacks.manager [None
req-c747f1f4-6424-4812-b7e4-cfc5c083fd81 tempest-BgpSpeakerTestJSON-1886159994
tempest-BgpSpeakerTestJSON-1886159994] Error during notification for
neutron_dynamic_routing.services.bgp.scheduler.bgp_dragent_scheduler.BgpDrAgentSchedulerBase.schedule_bgp_speaker_callback--9223372036854649727
bgp_speaker, after_create: TypeError: bind() takes 4 positional arguments but
5 were given
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860 neutron-server[19534]:
ERROR neutron_lib.callbacks.manager Traceback (most recent call last):
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860 neutron-server[19534]:
ERROR neutron_lib.callbacks.manager File
"/usr/local/lib/python3.6/dist-packages/neutron_lib/callbacks/manager.py", line
197, in _notify_loop
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860 neutron-server[19534]:
ERROR neutron_lib.callbacks.manager callback(resource, event, trigger,
**kwargs)
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860 neutron-server[19534]:
ERROR neutron_lib.callbacks.manager File
"/opt/stack/neutron-dynamic-routing/neutron_dynamic_routing/services/bgp/scheduler/bgp_dragent_scheduler.py",
line 202, in schedule_bgp_speaker_callback
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860 neutron-server[19534]:
ERROR neutron_lib.callbacks.manager plugin.schedule_bgp_speaker(ctx,
payload['bgp_speaker'])
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860 neutron-server[19534]:
ERROR neutron_lib.callbacks.manager File
"/opt/stack/neutron-dynamic-routing/neutron_dynamic_routing/db/bgp_dragentscheduler_db.py",
line 100, in schedule_bgp_speaker
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860 neutron-server[19534]:
ERROR neutron_lib.callbacks.manager created_bgp_speaker)
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860 neutron-server[19534]:
ERROR neutron_lib.callbacks.manager File
"/opt/stack/neutron/neutron/scheduler/base_scheduler.py", line 55, in schedule
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860 neutron-server[19534]:
ERROR neutron_lib.callbacks.manager context, chosen_agents, resource['id'],
force_scheduling)
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860 neutron-server[19534]:
ERROR neutron_lib.callbacks.manager TypeError: bind() takes 4 positional
arguments but 5 were given
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860 neutron-server[19534]:
ERROR neutron_lib.callbacks.manager
It is caused by https://review.opendev.org/#/c/288271/ which we merged
recently and revert of this patch is already proposed in
https://review.opendev.org/#/c/691710/
** Affects: neutron
Importance: Critical
Assignee: Slawek Kaplonski (slaweq)
Status: Confirmed
** Tags: gate-failure l3-bgp
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1850626
Title:
neutron-dynamic-routing: TypeError: bind() takes 4 positional
arguments but 5 were given
Status in neutron:
Confirmed
Bug description:
Neutron-dynamic-routing scenario jobs in neutron-tempest-plugin repo
are failing all the time since few days.
Example of failure
https://openstack.fortnebula.com:13808/v1/AUTH_e8fd161dc34c421a979a9e6421f823e9/zuul_opendev_logs_cee/691855/1/check
/neutron-tempest-plugin-dynamic-routing/cee3785/testr_results.html.gz
It seems that this happens due to error in service plugin, see neutron
server log:
Notify callbacks
['neutron_dynamic_routing.services.bgp.scheduler.bgp_dragent_scheduler.BgpDrAgentSchedulerBase.schedule_bgp_speaker_callback--9223372036854649727']
for bgp_speaker, after_create {{(pid=19640) _notify_loop
/usr/local/lib/python3.6/dist-packages/neutron_lib/callbacks/manager.py:193}}
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860
neutron-server[19534]: ERROR neutron_lib.callbacks.manager [None
req-c747f1f4-6424-4812-b7e4-cfc5c083fd81 tempest-BgpSpeakerTestJSON-1886159994
tempest-BgpSpeakerTestJSON-1886159994] Error during notification for
[Yahoo-eng-team] [Bug 1850602] [NEW] remove firewall_v1 exceptions in neutron-lib
Public bug reported: The fwaas_v1 code was removed in stein[1], so the related exceptions can also be removed. [1]https://review.opendev.org/#/c/616410/ ** Affects: neutron Importance: Undecided Assignee: zhanghao (zhanghao2) Status: New ** Changed in: neutron Assignee: (unassigned) => zhanghao (zhanghao2) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1850602 Title: remove firewall_v1 exceptions in neutron-lib Status in neutron: New Bug description: The fwaas_v1 code was removed in stein[1], so the related exceptions can also be removed. [1]https://review.opendev.org/#/c/616410/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1850602/+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
