date:20180227

[Yahoo-eng-team] [Bug 1752210] [NEW] Counter A ERROR when nova creates instance

2018-02-27 Thread wangthes

Public bug reported:

[root@controller0 ~]# . demo-openrc 
[root@controller0 ~]# openstack server create --flavor m1.tiny --image 
2af953de-058a-49a9-825d-781d220cd6eb --nic 
net-id=69d9c6d9-7716-45f1-a8d8-8988b59440af --security-group default 
demo-instance
Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and 
attach the Nova API log if possible.
 (HTTP 500) (Request-ID: 
req-4de93f56-1506-401e-a602-9fa5aa162824)

[root@controller0 ~]# tail -n 50 /var/log/nova/nova-api.log |grep ERROR
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions 
[req-4de93f56-1506-401e-a602-9fa5aa162824 d3eedc4b1e0348f0865b6a8052f75bd1 
1ec04ee805f24681a6a37cf0b6e52970 - - -] Unexpected exception in API method
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions Traceback 
(most recent call last):
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/api/openstack/extensions.py", line 478, 
in wrapped
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions return 
f(*args, **kwargs)
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 73, in 
wrapper
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 73, in 
wrapper
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/api/openstack/compute/servers.py", line 
611, in create
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions 
**create_kwargs)
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/hooks.py", line 149, in inner
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions rv = 
f(*args, **kwargs)
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/compute/api.py", line 1587, in create
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions 
check_server_group_quota=check_server_group_quota)
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/compute/api.py", line 1187, in 
_create_instance
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions 
auto_disk_config, reservation_id, max_count)
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/compute/api.py", line 961, in 
_validate_and_build_base_options
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions 
pci_request_info, requested_networks)
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 1092, in 
create_pci_requests_for_sriov_ports
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions neutron = 
get_client(context, admin=True)
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 237, in 
get_client
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions auth_token 
= _ADMIN_AUTH.get_token(_SESSION)
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/keystoneclient/auth/identity/base.py", line 
200, in get_token
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions return 
self.get_access(session).auth_token
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/keystoneclient/auth/identity/base.py", line 
240, in get_access
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions 
self.auth_ref = self.get_auth_ref(session)
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/keystoneclient/auth/identity/v2.py", line 88, 
in get_auth_ref
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions 
authenticated=False, log=False)
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/keystoneclient/session.py", line 501, in post
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions return 
self.request(url, 'POST', **kwargs)
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/keystoneclient/utils.py", line 337, in inner
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)
2018-02-27 20:50:57.551 1598 ERROR nova.api.openstack.extensions   File

[Yahoo-eng-team] [Bug 1752115] Re: detach multiattach volume disconnects innocent bystander

2018-02-27 Thread John Griffith

So looking into this the problem appears to be that Nova calls the brick
initiator disconnect_volume method indiscriminately.  Brick has no way
currently to interrogate usage of a connection, and I'm not sure that
something like that could be added in this case.

My first thought was that it would be logical to check for multiattach on the 
same host here:
  
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L1249
by using the objects.BlockDeviceMapping.get_by_volume() HOWEVER it turns out 
that's another special thing that isn't allowed when a volume is 
multiattach=True (I haven't figured out why that's there yet, but looking). 

** Also affects: nova
   Importance: Undecided
   Status: New

** No longer affects: cinder

-- 
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/1752115

Title:
  detach multiattach volume disconnects innocent bystander

Status in OpenStack Compute (nova):
  New

Bug description:
  Detaching a multi-attached lvm volume from one server, causes the
  other server to lose connectivity to the volume. I found this while
  developing a new tempest test to test this scenario.

  - create 2 instances on the same host, both simple instances with ephemeral 
disks
  - create a multi-attach lvm volume, attach to both instances
  - check that you can re-read the partition table from inside each instance 
(via ssh):

 $ sudo blockdev --rereadpt /dev/vdb

This succeeds on both instances (no output or err message is
  returned).

  - detach the volume from one of the instances
  - recheck connectivity. The expected result is that the command will now fail 
in the instance where 
the volume was detached. But it also fails on the instance where the volume 
is still supposedly 
attached:

 $ sudo blockdev --rereadpt /dev/vdb
 BLKRRPART: Input/output error

  cinder & nova still think that the volume is attached correctly:

  $ cinder show 2cf26a15-8937-4654-ba81-70cbcb97a238 | grep attachment
  | attachment_ids | ['f5876aff-5b5b-45a0-a020-515ca339eae4']   

  $ nova show vm1 | grep attached
  | os-extended-volumes:volumes_attached | [{"id": 
"2cf26a15-8937-4654-ba81-70cbcb97a238", "delete_on_termination": false}] |

  cinder version:

  :/opt/stack/cinder$ git show
  commit 015b1053990f00d1522c1074bcd160b4b57a5801
  Merge: 856e636 481535e
  Author: Zuul 
  Date:   Thu Feb 22 14:00:17 2018 +

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1752115/+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 1718356] Re: Include default config files in python wheel

2018-02-27 Thread OpenStack Infra

Reviewed:  https://review.openstack.org/506203
Committed: 
https://git.openstack.org/cgit/openstack/trove/commit/?id=39ae2ee3a9084e0b6945f0fbec3dd735dc0efa7d
Submitter: Zuul
Branch:master

commit 39ae2ee3a9084e0b6945f0fbec3dd735dc0efa7d
Author: Jesse Pretorius 
Date:   Thu Sep 21 15:16:08 2017 +0100

Add default configuration files to data_files

In order to make it simpler to use the default
configuration files when deploying services
from source, the files are added to pbr's
data_files section so that the files are
included in the built wheels and therefore
deployed with the code. Packaging and deployment
tools can then more easily use the default files
if they wish to.

This pattern is already established with similar
files for neutron, designate and glance as has
been mentioned in the related bug report.

Change-Id: I3bb03644674f016018a178a76cca9d12afe11c43
Closes-Bug: #1718356


** Changed in: trove
   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/1718356

Title:
  Include default config files in python wheel

Status in Barbican:
  In Progress
Status in Cinder:
  Fix Released
Status in Cyborg:
  In Progress
Status in Designate:
  Fix Released
Status in Fuxi:
  New
Status in Glance:
  Fix Released
Status in OpenStack Heat:
  In Progress
Status in Ironic:
  Fix Released
Status in Karbor:
  In Progress
Status in OpenStack Identity (keystone):
  Fix Released
Status in kuryr-libnetwork:
  New
Status in Magnum:
  In Progress
Status in neutron:
  In Progress
Status in OpenStack Compute (nova):
  In Progress
Status in octavia:
  Invalid
Status in openstack-ansible:
  Confirmed
Status in Sahara:
  Fix Released
Status in OpenStack DBaaS (Trove):
  Fix Released
Status in Zun:
  In Progress

Bug description:
  The projects which deploy OpenStack from source or using python wheels
  currently have to either carry templates for api-paste, policy and
  rootwrap files or need to source them from git during deployment. This
  results in some rather complex mechanisms which could be radically
  simplified by simply ensuring that all the same files are included in
  the built wheel.

  A precedence for this has already been set in neutron [1], glance [2]
  and designate [3] through the use of the data_files option in the
  files section of setup.cfg.

  [1] 
https://github.com/openstack/neutron/blob/d3c393ff6b5fbd0bdaabc8ba678d755ebfba08f7/setup.cfg#L24-L39
  [2] 
https://github.com/openstack/glance/blob/02cd5cba70a8465a951cb813a573d390887174b7/setup.cfg#L20-L21
  [3] 
https://github.com/openstack/designate/blob/25eb143db04554d65efe2e5d60ad3afa6b51d73a/setup.cfg#L30-L37

  This bug will be used for a cross-project implementation of patches to
  normalise the implementation across the OpenStack projects. Hopefully
  the result will be a consistent implementation across all the major
  projects.

  A mailing list thread corresponding to this standard setting was begun:
  http://lists.openstack.org/pipermail/openstack-dev/2017-September/122794.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/barbican/+bug/1718356/+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 1627694] Re: unshelving an instance doesn't rollback volumes connections on failure

2018-02-27 Thread Matt Riedemann

** Also affects: nova/queens
   Importance: Undecided
   Status: New

** Changed in: nova/queens
   Status: New => Confirmed

** Changed in: nova/queens
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1627694

Title:
  unshelving an instance doesn't rollback volumes connections on failure

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) ocata series:
  Confirmed
Status in OpenStack Compute (nova) pike series:
  Confirmed
Status in OpenStack Compute (nova) queens series:
  In Progress

Bug description:
  When creating and instance and it is being spawned for the first time
  fails, the instance's volumes' initialize_connection is being rolled-
  back, but when unshelving an shelved-offloaded instance, there's no
  rollback in case of failure.

  The reason is that when spawning an instance for the first time, nova-compute 
calls initialize_connection using the _build_resources() method:
  
https://github.com/openstack/nova/blob/93e689516da0302b06c2760bb82c5004ae057913/nova/compute/manager.py#L1902
  That context-aware method will also take care of rollback in case of a 
failure in spawning, and will terminate_connection of the volumes:
  
https://github.com/openstack/nova/blob/93e689516da0302b06c2760bb82c5004ae057913/nova/compute/manager.py#L2095

  But, when unshelving an instance, initialize_connection is not called in a 
context aware method, and no rollback in happening when spawning fails.
  
https://github.com/openstack/nova/blob/93e689516da0302b06c2760bb82c5004ae057913/nova/compute/manager.py#L4330

  This makes the volumes stay connected to the node even-though the instance is 
shelved-offloaded.
  If you want to see this problem, replace the driver.spawn() call with a 
"raise Exception", and see the volumes have connection to the node even though 
they shouldn't have.

  I'm using openstack Liberty, but I can see this problem in current
  master (pre-Newton)

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1627694/+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 1752152] [NEW] Attach Volume Fails with secure call to cinder

2018-02-27 Thread Divya K Konoor

Public bug reported:

It is found that when cinder endpoint is configured to use https, attach
volume flow fails with the stack trace seen below (seen in nova api log)
because it fails to make a secure call from nova to cinder. Secure calls
perform certificate validation and in this particular flow, certificate
validation is completely skipped

File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 3971, in 
attach_volume
2018-02-27 08:16:51.338 1324 ERROR  
cinder.is_microversion_supported(context, '3.44')
2018-02-27 08:16:51.338 1324 ERRORFile 
"/usr/lib/python2.7/site-packages/nova/volume/cinder.py", line 138, in 
is_microversion_supported
2018-02-27 08:16:51.338 1324 ERROR  _check_microversion(url, microversion)
2018-02-27 08:16:51.338 1324 ERRORFile 
"/usr/lib/python2.7/site-packages/nova/volume/cinder.py", line 86, in 
_check_microversion
2018-02-27 08:16:51.338 1324 ERROR  max_api_version = 
cinder_client.get_highest_client_server_version(url)
2018-02-27 08:16:51.338 1324 ERRORFile 
"/usr/lib/python2.7/site-packages/cinderclient/client.py", line 126, in 
get_highest_client_server_version
2018-02-27 08:16:51.338 1324 ERROR  min_server, max_server = 
get_server_version(url)
2018-02-27 08:16:51.338 1324 ERRORFile 
"/usr/lib/python2.7/site-packages/cinderclient/client.py", line 109, in 
get_server_version
2018-02-27 08:16:51.338 1324 ERROR  response = requests.get(version_url)
2018-02-27 08:16:51.338 1324 ERRORFile 
"/usr/lib/python2.7/site-packages/requests/api.py", line 72, in get
2018-02-27 08:16:51.338 1324 ERROR  return request('get', url, 
params=params, **kwargs)
2018-02-27 08:16:51.338 1324 ERRORFile 
"/usr/lib/python2.7/site-packages/requests/api.py", line 58, in request
2018-02-27 08:16:51.338 1324 ERROR  return session.request(method=method, 
url=url, **kwargs)
2018-02-27 08:16:51.338 1324 ERRORFile 
"/usr/lib/python2.7/site-packages/requests/sessions.py", line 502, in request
2018-02-27 08:16:51.338 1324 ERROR  resp = self.send(prep, **send_kwargs)
2018-02-27 08:16:51.338 1324 ERRORFile 
"/usr/lib/python2.7/site-packages/requests/sessions.py", line 612, in send
2018-02-27 08:16:51.338 1324 ERROR  r = adapter.send(request, **kwargs)
2018-02-27 08:16:51.338 1324 ERRORFile 
"/usr/lib/python2.7/site-packages/requests/adapters.py", line 504, in send
2018-02-27 08:16:51.338 1324 ERROR  raise ConnectionError(e, 
request=request)
2018-02-27 08:16:51.338 1324 ERROR  ConnectionError: 
HTTPSConnectionPool(host='ip9-114-192-132.pok.stglabs.ibm.com', port=9000): Max 
retries exceeded with url: / (Caused by SSLError(SSLError("bad handshake: 
Error([('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify 
failed')],)",),))

This is a regression bug introduced as part of changeset
https://review.openstack.org/#/c/469579/, which was merged way back in
June 2017. As part of this changeset, a new function namely
_check_microversion was introduced, which then makes a cinderclient call
, which finally makes a cinder https REST api call without passing the
certificate. This leads to the problem listed above.

https://github.com/openstack/nova/blob/stable/queens/nova/volume/cinder.py#L75
https://github.com/openstack/nova/blob/stable/queens/nova/volume/cinder.py#L86

https://github.com/openstack/python-cinderclient/blob/stable/queens/cinderclient/client.py#L126
https://github.com/openstack/python-cinderclient/blob/stable/queens/cinderclient/client.py#L109

** Affects: nova
 Importance: Undecided
 Status: New

** Affects: python-cinderclient
 Importance: Undecided
 Status: New

** Project changed: cinder => nova

** Also affects: python-cinderclient
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1752152

Title:
  Attach Volume Fails with secure call to cinder

Status in OpenStack Compute (nova):
  New
Status in python-cinderclient:
  New

Bug description:
  It is found that when cinder endpoint is configured to use https,
  attach volume flow fails with the stack trace seen below (seen in nova
  api log) because it fails to make a secure call from nova to cinder.
  Secure calls perform certificate validation and in this particular
  flow, certificate validation is completely skipped

  File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 3971, in 
attach_volume
  2018-02-27 08:16:51.338 1324 ERROR  
cinder.is_microversion_supported(context, '3.44')
  2018-02-27 08:16:51.338 1324 ERRORFile 
"/usr/lib/python2.7/site-packages/nova/volume/cinder.py", line 138, in 
is_microversion_supported
  2018-02-27 08:16:51.338 1324 ERROR  _check_microversion(url, microversion)
  2018-02-27 08:16:51.338 1324 ERRORFile 
"/usr/lib/python2.7/site-packages/nova/volume/cinder.py", line 86, in 
_check_microversion

[Yahoo-eng-team] [Bug 1752152] [NEW] Attach Volume Fails with secure call to cinder

2018-02-27 Thread Launchpad Bug Tracker

You have been subscribed to a public bug:

It is found that when cinder endpoint is configured to use https, attach
volume flow fails with the stack trace seen below (seen in nova api log)
because it fails to make a secure call from nova to cinder. Secure calls
perform certificate validation and in this particular flow, certificate
validation is completely skipped

File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 3971, in 
attach_volume
2018-02-27 08:16:51.338 1324 ERROR  
cinder.is_microversion_supported(context, '3.44')
2018-02-27 08:16:51.338 1324 ERRORFile 
"/usr/lib/python2.7/site-packages/nova/volume/cinder.py", line 138, in 
is_microversion_supported
2018-02-27 08:16:51.338 1324 ERROR  _check_microversion(url, microversion)
2018-02-27 08:16:51.338 1324 ERRORFile 
"/usr/lib/python2.7/site-packages/nova/volume/cinder.py", line 86, in 
_check_microversion
2018-02-27 08:16:51.338 1324 ERROR  max_api_version = 
cinder_client.get_highest_client_server_version(url)
2018-02-27 08:16:51.338 1324 ERRORFile 
"/usr/lib/python2.7/site-packages/cinderclient/client.py", line 126, in 
get_highest_client_server_version
2018-02-27 08:16:51.338 1324 ERROR  min_server, max_server = 
get_server_version(url)
2018-02-27 08:16:51.338 1324 ERRORFile 
"/usr/lib/python2.7/site-packages/cinderclient/client.py", line 109, in 
get_server_version
2018-02-27 08:16:51.338 1324 ERROR  response = requests.get(version_url)
2018-02-27 08:16:51.338 1324 ERRORFile 
"/usr/lib/python2.7/site-packages/requests/api.py", line 72, in get
2018-02-27 08:16:51.338 1324 ERROR  return request('get', url, 
params=params, **kwargs)
2018-02-27 08:16:51.338 1324 ERRORFile 
"/usr/lib/python2.7/site-packages/requests/api.py", line 58, in request
2018-02-27 08:16:51.338 1324 ERROR  return session.request(method=method, 
url=url, **kwargs)
2018-02-27 08:16:51.338 1324 ERRORFile 
"/usr/lib/python2.7/site-packages/requests/sessions.py", line 502, in request
2018-02-27 08:16:51.338 1324 ERROR  resp = self.send(prep, **send_kwargs)
2018-02-27 08:16:51.338 1324 ERRORFile 
"/usr/lib/python2.7/site-packages/requests/sessions.py", line 612, in send
2018-02-27 08:16:51.338 1324 ERROR  r = adapter.send(request, **kwargs)
2018-02-27 08:16:51.338 1324 ERRORFile 
"/usr/lib/python2.7/site-packages/requests/adapters.py", line 504, in send
2018-02-27 08:16:51.338 1324 ERROR  raise ConnectionError(e, 
request=request)
2018-02-27 08:16:51.338 1324 ERROR  ConnectionError: 
HTTPSConnectionPool(host='ip9-114-192-132.pok.stglabs.ibm.com', port=9000): Max 
retries exceeded with url: / (Caused by SSLError(SSLError("bad handshake: 
Error([('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify 
failed')],)",),))

This is a regression bug introduced as part of changeset
https://review.openstack.org/#/c/469579/, which was merged way back in
June 2017. As part of this changeset, a new function namely
_check_microversion was introduced, which then makes a cinderclient call
, which finally makes a cinder https REST api call without passing the
certificate. This leads to the problem listed above.

https://github.com/openstack/nova/blob/stable/queens/nova/volume/cinder.py#L75
https://github.com/openstack/nova/blob/stable/queens/nova/volume/cinder.py#L86

https://github.com/openstack/python-cinderclient/blob/stable/queens/cinderclient/client.py#L126
https://github.com/openstack/python-cinderclient/blob/stable/queens/cinderclient/client.py#L109

** Affects: nova
 Importance: Undecided
 Status: New

-- 
Attach Volume Fails with secure call to cinder
https://bugs.launchpad.net/bugs/1752152
You received this bug notification because you are a member of Yahoo! 
Engineering Team, which is subscribed to OpenStack Compute (nova).

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1627694] Re: unshelving an instance doesn't rollback volumes connections on failure

2018-02-27 Thread OpenStack Infra

Reviewed:  https://review.openstack.org/378009
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=dcdd2c9832c7c60fe9163cd744ca2b5acfe16bcc
Submitter: Zuul
Branch:master

commit dcdd2c9832c7c60fe9163cd744ca2b5acfe16bcc
Author: Shoham Peller 
Date:   Tue Sep 27 20:25:05 2016 +0300

Handle spawning error on unshelving

If spawning fails when unshelving, terminate the volumes' connections
with the node, and remove the node reference from the instance entry.

Co-Authored-By: Matt Riedemann 

Closes-Bug: 1627694
Change-Id: I8cfb2280d956d452ccad1fc711bd814b7258147f


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

Title:
  unshelving an instance doesn't rollback volumes connections on failure

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) ocata series:
  Confirmed
Status in OpenStack Compute (nova) pike series:
  Confirmed

Bug description:
  When creating and instance and it is being spawned for the first time
  fails, the instance's volumes' initialize_connection is being rolled-
  back, but when unshelving an shelved-offloaded instance, there's no
  rollback in case of failure.

  The reason is that when spawning an instance for the first time, nova-compute 
calls initialize_connection using the _build_resources() method:
  
https://github.com/openstack/nova/blob/93e689516da0302b06c2760bb82c5004ae057913/nova/compute/manager.py#L1902
  That context-aware method will also take care of rollback in case of a 
failure in spawning, and will terminate_connection of the volumes:
  
https://github.com/openstack/nova/blob/93e689516da0302b06c2760bb82c5004ae057913/nova/compute/manager.py#L2095

  But, when unshelving an instance, initialize_connection is not called in a 
context aware method, and no rollback in happening when spawning fails.
  
https://github.com/openstack/nova/blob/93e689516da0302b06c2760bb82c5004ae057913/nova/compute/manager.py#L4330

  This makes the volumes stay connected to the node even-though the instance is 
shelved-offloaded.
  If you want to see this problem, replace the driver.spawn() call with a 
"raise Exception", and see the volumes have connection to the node even though 
they shouldn't have.

  I'm using openstack Liberty, but I can see this problem in current
  master (pre-Newton)

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1627694/+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 1598783] Re: Config drives created on RHEL/CentOS 7.1 can't be found

2018-02-27 Thread OpenStack Infra

Reviewed:  https://review.openstack.org/529448
Committed: 
https://git.openstack.org/cgit/openstack/cloudbase-init/commit/?id=24365043e31a7cb0899dbbba654ef718da5b
Submitter: Zuul
Branch:master

commit 24365043e31a7cb0899dbbba654ef718da5b
Author: James Penick 
Date:   Thu Dec 21 01:16:41 2017 +

Recognize uppercase vfat disk labels

New mkfs.vfat and fatlabel tools included in the dosfsutils package no
longer support creating vfat disks with lowercase labels. They silently
default to an all uppercase label eg CONFIG-2 instead of config-2. This
change makes cloud-init handle either upper or lower case.

Change-Id: Iec927db04b9621b20c9bee2c8d81325d7af80f9b
Closes-Bug: #1598783


** Changed in: cloudbase-init
   Status: In Progress => 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/1598783

Title:
  Config drives created on RHEL/CentOS 7.1 can't be found

Status in CirrOS:
  Confirmed
Status in cloud-init:
  Fix Released
Status in cloudbase-init:
  Fix Released

Bug description:
  Depending on the exact version of dosfstools used when preparing a
  config drive FS, it may not be detected by Cirron on VM boot. This is
  due to the fact, that Cirros currently performs a case-sensitive
  comparison of FS labels:

  http://bazaar.launchpad.net/~cirros-
  dev/cirros/trunk/view/head:/src/lib/cirros/shlib#L134

  and mkfs.vfat from CentOS will create an uppercase label "CONFIG-2".

  Apparently, dosfstools won't let you use lowercase labels on CentOS,
  while it works fine on Ubuntu:

  http://paste.openstack.org/show/507193/

  All the descriptions of the config drive format mention "config-2",
  not "CONFIG-2":

  http://cloudinit.readthedocs.io/en/latest/topics/datasources.html
  https://coreos.com/os/docs/latest/config-drive.html
  http://docs.openstack.org/user-guide/cli_config_drive.html

  Nothing is said about whether case-sensitive or -insensitive string
  comparison should be used for comparing of FS labels.

  Looks like FAT standard does not specify how labels should be treated,
  but Windows (at least XP) stores those in upper-case:

  "For FAT volumes, volume labels are stored as uppercase regardless of
  whether they contain lowercase letters. NTFS volume labels retain and
  display the case used when the label was created."

  https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs
  /en-us/label.mspx?mfr=true

  E.g. in Debian this was considered to be a bug and was fixed:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714971;msg=2

  It even was accepted to upstream:

  
https://github.com/dosfstools/dosfstools/commit/465dd8cf8f643bdd39a732e7d7f819a6abdf3d83

  and made it to 3.0.22 release.

  Related bug in MOS: https://bugs.launchpad.net/mos/+bug/1587960

To manage notifications about this bug go to:
https://bugs.launchpad.net/cirros/+bug/1598783/+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 1737207] Re: Guest admin password and network information is logged at debug if libvirt.inject_partition != -2

2018-02-27 Thread Matt Riedemann

** Also affects: nova/queens
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1737207

Title:
  Guest admin password and network information is logged at debug if
  libvirt.inject_partition != -2

Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Compute (nova) ocata series:
  In Progress
Status in OpenStack Compute (nova) pike series:
  In Progress
Status in OpenStack Compute (nova) queens series:
  In Progress

Bug description:
  When using the libvirt driver and the inject_partition config option
  is != -2 (disabled), the driver will log the network information and
  admin password about the guest during disk injection:

  http://logs.openstack.org/50/524750/1/check/legacy-tempest-dsvm-
  neutron-full-
  centos-7/a7f051e/logs/screen-n-cpu.txt.gz#_Dec_04_13_42_41_311316

  Dec 04 13:42:41.311316 centos-7-rax-dfw-0001196569 nova-compute[7962]: DEBUG 
nova.virt.libvirt.driver [None req-80dab566-372b-43d7-88f9-d807cc9cb673 service 
nova] [instance: 941f8290-5e14-4b53-85c9-c5045de9a067] Checking root disk 
injection InjectionInfo(network_info=[{"profile": {}, "ovs_interfaceid": 
"56e5a50e-d30e-4814-aee3-fcc9525d12ca", "preserve_on_delete": false, "network": 
{"bridge": "br-int", "subnets": [{"ips": [{"meta": {}, "version": 4, "type": 
"fixed", "floating_ips": [], "address": "10.1.0.6"}], "version": 4, "meta": 
{"dhcp_server": "10.1.0.2"}, "dns": [], "routes": [], "cidr": "10.1.0.0/28", 
"gateway": {"meta": {}, "version": 4, "type": "gateway", "address": 
"10.1.0.1"}}], "meta": {"injected": false, "tenant_id": 
"77504d716f9d4f38a021cbfa4f0e28ee", "mtu": 1450}, "id": 
"766bb2bf-e1c0-43b8-8800-5737351e9a03", "label": 
"tempest-ServersTestJSON-518988576-network"}, "devname": "tap56e5a50e-d3", 
"vnic_type": "normal", "qbh_params": null, "meta": {}, "details": 
{"port_filter": true, "datapath_type": "system", "ovs_hybrid_plug": true}, 
"address": "fa:16:3e:d3:8e:f8", "active": false, "type": "ovs", "id": 
"56e5a50e-d30e-4814-aee3-fcc9525d12ca", "qbg_params": null}], files=[], 
admin_pass=u'V2^cP#tYp*=UD&7') {{(pid=7962) _inject_data 
/opt/stack/new/nova/nova/virt/libvirt/driver.py:3115}}
  Dec 04 13:42:41.314687 centos-7-rax-dfw-0001196569 nova-compute[7962]: DEBUG 
nova.virt.libvirt.driver [None req-80dab566-372b-43d7-88f9-d807cc9cb673 service 
nova] [instance: 941f8290-5e14-4b53-85c9-c5045de9a067] Injecting 
InjectionInfo(network_info=[{"profile": {}, "ovs_interfaceid": 
"56e5a50e-d30e-4814-aee3-fcc9525d12ca", "preserve_on_delete": false, "network": 
{"bridge": "br-int", "subnets": [{"ips": [{"meta": {}, "version": 4, "type": 
"fixed", "floating_ips": [], "address": "10.1.0.6"}], "version": 4, "meta": 
{"dhcp_server": "10.1.0.2"}, "dns": [], "routes": [], "cidr": "10.1.0.0/28", 
"gateway": {"meta": {}, "version": 4, "type": "gateway", "address": 
"10.1.0.1"}}], "meta": {"injected": false, "tenant_id": 
"77504d716f9d4f38a021cbfa4f0e28ee", "mtu": 1450}, "id": 
"766bb2bf-e1c0-43b8-8800-5737351e9a03", "label": 
"tempest-ServersTestJSON-518988576-network"}, "devname": "tap56e5a50e-d3", 
"vnic_type": "normal", "qbh_params": null, "meta": {}, "details": 
{"port_filter": true, "datapath_type": "system", "ovs_hybrid_plug": true}, 
"address": "fa:16:3e:d3:8e:f8", "active": false, "type": "ovs", "id": 
"56e5a50e-d30e-4814-aee3-fcc9525d12ca", "qbg_params": null}], files=[], 
admin_pass=u'V2^cP#tYp*=UD&7') {{(pid=7962) _inject_data 
/opt/stack/new/nova/nova/virt/libvirt/driver.py:3146}}

  This was introduced in Ocata (15.0.0):
  https://review.openstack.org/#/c/337790/

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1737207/+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 1749215] Re: Allocations not deleted on failed resize_instance

2018-02-27 Thread OpenStack Infra

Reviewed:  https://review.openstack.org/543971
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=caf167862dd82e98f0189c9598856de57dfa7d35
Submitter: Zuul
Branch:master

commit caf167862dd82e98f0189c9598856de57dfa7d35
Author: Claudiu Belu 
Date:   Sun Feb 11 10:07:52 2018 -0800

compute: Cleans up allocations after failed resize

During cold resize, the ComputeManager's prep_resize calls the
rpcapi.ComputeAPI's resize_instance method, which will then do an
RPC cast (async).

Because the RPC cast is asynchronous, the exception branch in prep_resize
will not be executed if the cold resize failed, the allocations will not
be cleaned up, and the instance will not be rescheduled.

This patch adds allocation cleanup in the resize_instance and finish_resize
methods.

Change-Id: I2d9ab06b485f76550dbbff46f79f40ff4c97d12f
Closes-Bug: #1749215


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

Title:
  Allocations not deleted on failed resize_instance

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) ocata series:
  Confirmed
Status in OpenStack Compute (nova) pike series:
  Confirmed
Status in OpenStack Compute (nova) queens series:
  Confirmed

Bug description:
  Description
  ===

  During a resize, an instance's allocations are removed and replaced by
  2 sets of allocations instead. If a resize is completed sucessfully,
  one set of allocations is correctly removed, but in case of a failure,
  neither set of allocations is removed. Only one set of allocations are
  removed if the instance is deleted.

  This happens because the call self.compute_rpcapi.resize_instance [1]
  is an RPC cast (async), instead of a call (sync). Because of this, the
  Except branch [2] in which the allocation is cleared and the instance
  is rescheduled, is never called.

  Additionally, because not all of the allocations are cleared, the
  resources on the compute nodes will become "locked" and unusable. At
  some point, instances will no longer be scheduled to those compute
  nodes, due to all the resources being "allocated".

  [1] 
https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L4085
  [2] 
https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L4123

  
  Steps to reproduce
  ==

  * Spawn an instance.
  * Observe that the table nova_api.allocations only has 1 set of allocations 
for the instance (VCPU, MEMORY, DISK).
  * Cold resize to an invalid flavor (e.g.: smaller disk).
  * Observe that the table nova_api.allocations has 2 sets of allocations for 
the instance.
  * Observe that the cold resize failed, and that the instance's task state has 
been reverted to its original state.
  * Observe that the table nova_api.allocations continues to have 2 sets of 
allocations.
  * Delete the instance.
  * Observe even after the instance has been destroyed, there is still 1 set of 
allocations for the instance.

  
  Expected result
  ===

  After the cold resize failed, there should be only 1 set of
  allocations in the nova_api.allocations table, and after deleting the
  instance, there shouldn't be any.

  
  Actual result
  =

  After the cold resize failed, there are 2 sets of allocations in the
  nova_api.allocations table, after deleting the instance, there is 1
  set of allocations.

  
  Environment
  ===

  Branch: Queens
  Hypervisor: Hyper-V Server 2012 R2 (unrelated)

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1749215/+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 1739871] Re: Disable batch delete button when keypairs are deleted

2018-02-27 Thread OpenStack Infra

Reviewed:  https://review.openstack.org/529932
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=ab57c0937df8b870440974fd78dfe4557c104dbb
Submitter: Zuul
Branch:master

commit ab57c0937df8b870440974fd78dfe4557c104dbb
Author: wei.ying 
Date:   Fri Nov 17 16:45:32 2017 +0800

Fix batch delete key pairs button isn't disabled when the key pair has 
deleted

When the key pair has deleted by the batch delete button, the batch
delete button isn't disabled and still can be clicked.

Since whatever in the keypairs panel or on key pair details page,
After the key pair is deleted, the url will be redirected to the
key pairs panel. The correct way is that only the key pair is deleted
on the details page, and it needs to be redirected to the key pairs
panel.

Change-Id: Ie3041cc70bde84e9753be41f0a80d04534ffdf44
Closes-Bug:#1739871


** Changed in: horizon
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1739871

Title:
  Disable batch delete button when keypairs are deleted

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  Env: devstack master branch

  Steps to reproduce:

  1. Go to Porject/Compute Key Pairs panel.
  2. Create two key pairs, such as "keypair 1","keypair 2".
  3. Select "keypair 1","keypair 2" and click batch "Delete Key Pairs" button.

  After deleting keypairs, we will see that batch "Delete Key Pairs"
  button is not disabled and still can be clicked.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1739871/+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 1748062] Re: idp_id, protocol_id, unique_id and name filter doesn't work for list_users API when domain_specific_drivers_enabled is set

2018-02-27 Thread wangxiyuan

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

Title:
  idp_id, protocol_id, unique_id and name filter doesn't work for
  list_users API when  domain_specific_drivers_enabled is set

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  When domain_specific_drivers_enabled is set to True, the idp_id,
  protocol_id, unique_id and name filter will not work for listing
  federated users.

  Reproduce:
  1. set the domain_specific_drivers_enabled = true, then restart Keystone.
  2. try to list the federated users by "idp_id" filter, for example, if you 
have a federated user whose idp_id is "deamoidp" already, try this: GET 
/v3/users?idp_id=demoidp

  please ensure the user driver is domian aware, that is, should not be
  ldap.

  Expect: the federated user whose idp_id=demoidp should return.
  Actual: Nothing returned.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1748062/+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 1659691] Re: neutron-vpnaas tempest job improvement

2018-02-27 Thread YAMAMOTO Takashi

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

Title:
  neutron-vpnaas tempest job improvement

Status in neutron:
  Fix Released

Bug description:
  gate-neutron-dsvm-tempest-vpnaas-ubuntu-xenial is completely broken.
  (it doesn't even configure vpnaas)
  it needs to be fixed and made voting.

  i plan to fold gate-neutron-vpnaas-dsvm-api-ubuntu-xenial-nv into the above 
job
  once it gets ready.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1659691/+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 1752030] [NEW] Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.

2018-02-27 Thread tej

Public bug reported:

unable to launch compute resource getting issue "Unexpected API
Error. (HTTP 500"

checked nova-api.log

018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions 
[req-e0d369b3-e59b-4433-be74-9e6e5a4a31fa 1531b2f661164b18af3330a83aebfe24 
14b50966a8584661953656392115423a - default default] Unexpected exception in API 
method: Unauthorized: Unknown auth type: None
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions Traceback 
(most recent call last):
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/api/openstack/extensions.py", line 336, 
in wrapped
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions return 
f(*args, **kwargs)
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 108, 
in wrapper
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 108, 
in wrapper
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 108, 
in wrapper
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 108, 
in wrapper
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 108, 
in wrapper
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 108, 
in wrapper
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 108, 
in wrapper
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/api/openstack/compute/servers.py", line 
553, in create
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions 
**create_kwargs)
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/hooks.py", line 154, in inner
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions rv = 
f(*args, **kwargs)
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/compute/api.py", line 1635, in create
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions tags=tags)
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/compute/api.py", line 1092, in 
_create_instance
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions 
reservation_id, max_count)
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/compute/api.py", line 838, in 
_validate_and_build_base_options
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions 
pci_request_info, requested_networks)
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 1498, in 
create_pci_requests_for_sriov_ports
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions neutron = 
get_client(context, admin=True)
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 151, in 
get_client
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions 
_ADMIN_AUTH = _load_auth_plugin(CONF)
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 74, in 
_load_auth_plugin
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions raise 
neutron_client_exc.Unauthorized(message=err_msg)
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions Unauthorized: 
Unknown auth type: None
2018-02-27 06:43:00.867 21904 ERROR nova.api.openstack.extensions

** Affects: nova
 Importance: Undecided
 Status: New

--

[Yahoo-eng-team] [Bug 1752006] [NEW] [FWaaS] firewall l2 agent extension is not compatible with LinuxBridge agent

2018-02-27 Thread Nguyen Phuong An

Public bug reported:

When I try to enable fwaas_v2 with Q_AGENT=linuxbridge, I've got the
error as below:

Th02 27 14:15:13 team1-an neutron-linuxbridge-agent[22845]: INFO 
neutron.agent.agent_extensions_manager [None 
req-0f64e4c1-2820-41ac-aa5f-8833edeaa663 None None] Loaded agent extensions: 
['fwaas_v2']
Th02 27 14:15:13 team1-an neutron-linuxbridge-agent[22845]: INFO 
neutron.agent.agent_extensions_manager [None 
req-0f64e4c1-2820-41ac-aa5f-8833edeaa663 None None] Initializing agent 
extension 'fwaas_v2'
Th02 27 14:15:13 team1-an neutron-linuxbridge-agent[22845]: ERROR 
oslo_service.service [None req-0f64e4c1-2820-41ac-aa5f-8833edeaa663 None None] 
Error starting thread.: AttributeError: 'LinuxbridgeAgentExtensionAPI' object 
has no attribute 'request_int_br'
Th02 27 14:15:13 team1-an neutron-linuxbridge-agent[22845]: ERROR 
oslo_service.service Traceback (most recent call last):
Th02 27 14:15:13 team1-an neutron-linuxbridge-agent[22845]: ERROR 
oslo_service.service   File 
"/usr/local/lib/python2.7/dist-packages/oslo_service/service.py", line 729, in 
run_service
Th02 27 14:15:13 team1-an neutron-linuxbridge-agent[22845]: ERROR 
oslo_service.service service.start()
Th02 27 14:15:13 team1-an neutron-linuxbridge-agent[22845]: ERROR 
oslo_service.service   File 
"/usr/local/lib/python2.7/dist-packages/osprofiler/profiler.py", line 157, in 
wrapper
Th02 27 14:15:13 team1-an neutron-linuxbridge-agent[22845]: ERROR 
oslo_service.service result = f(*args, **kwargs)
Th02 27 14:15:13 team1-an neutron-linuxbridge-agent[22845]: ERROR 
oslo_service.service   File 
"/opt/stack/neutron/neutron/plugins/ml2/drivers/agent/_common_agent.py", line 
86, in start
Th02 27 14:15:13 team1-an neutron-linuxbridge-agent[22845]: ERROR 
oslo_service.service self.init_extension_manager(self.connection)
Th02 27 14:15:13 team1-an neutron-linuxbridge-agent[22845]: ERROR 
oslo_service.service   File 
"/usr/local/lib/python2.7/dist-packages/osprofiler/profiler.py", line 157, in 
wrapper
Th02 27 14:15:13 team1-an neutron-linuxbridge-agent[22845]: ERROR 
oslo_service.service result = f(*args, **kwargs)
Th02 27 14:15:13 team1-an neutron-linuxbridge-agent[22845]: ERROR 
oslo_service.service   File 
"/opt/stack/neutron/neutron/plugins/ml2/drivers/agent/_common_agent.py", line 
178, in init_extension_manager
Th02 27 14:15:13 team1-an neutron-linuxbridge-agent[22845]: ERROR 
oslo_service.service connection, self.mgr.get_extension_driver_type(), 
agent_api)
Th02 27 14:15:13 team1-an neutron-linuxbridge-agent[22845]: ERROR 
oslo_service.service   File 
"/opt/stack/neutron/neutron/agent/agent_extensions_manager.py", line 54, in 
initialize
Th02 27 14:15:13 team1-an neutron-linuxbridge-agent[22845]: ERROR 
oslo_service.service extension.obj.initialize(connection, driver_type)
Th02 27 14:15:13 team1-an neutron-linuxbridge-agent[22845]: ERROR 
oslo_service.service   File 
"/opt/stack/neutron-fwaas/neutron_fwaas/services/firewall/agents/l2/fwaas_v2.py",
 line 73, in initialize
Th02 27 14:15:13 team1-an neutron-linuxbridge-agent[22845]: ERROR 
oslo_service.service int_br = self.agent_api.request_int_br()
Th02 27 14:15:13 team1-an neutron-linuxbridge-agent[22845]: ERROR 
oslo_service.service AttributeError: 'LinuxbridgeAgentExtensionAPI' object has 
no attribute 'request_int_br'
Th02 27 14:15:14 team1-an neutron-linuxbridge-agent[22845]: ERROR 
oslo_service.service

Currently, firewall l2 agent extension is work with openvswitch agent.
So shall we make firewall l2 agent extension is compatible with
linuxbridge agent?

** Affects: neutron
 Importance: Undecided
 Assignee: Nguyen Phuong An (annp)
 Status: New

** Description changed:

  When I try to enable fwaas_v2 with Q_AGENT=linuxbridge, I've got the
  error as below:
  
  Th02 27 14:15:13 team1-an neutron-linuxbridge-agent[22845]: INFO 
neutron.agent.agent_extensions_manager [None 
req-0f64e4c1-2820-41ac-aa5f-8833edeaa663 None None] Loaded agent extensions: 
['fwaas_v2']
  Th02 27 14:15:13 team1-an neutron-linuxbridge-agent[22845]: INFO 
neutron.agent.agent_extensions_manager [None 
req-0f64e4c1-2820-41ac-aa5f-8833edeaa663 None None] Initializing agent 
extension 'fwaas_v2'
  Th02 27 14:15:13 team1-an neutron-linuxbridge-agent[22845]: ERROR 
oslo_service.service [None req-0f64e4c1-2820-41ac-aa5f-8833edeaa663 None None] 
Error starting thread.: AttributeError: 'LinuxbridgeAgentExtensionAPI' object 
has no attribute 'request_int_br'
  Th02 27 14:15:13 team1-an neutron-linuxbridge-agent[22845]: ERROR 
oslo_service.service Traceback (most recent call last):
  Th02 27 14:15:13 team1-an neutron-linuxbridge-agent[22845]: ERROR 
oslo_service.service   File 
"/usr/local/lib/python2.7/dist-packages/oslo_service/service.py", line 729, in 
run_service
  Th02 27 14:15:13 team1-an neutron-linuxbridge-agent[22845]: ERROR 
oslo_service.service service.start()
  Th02 27 14:15:13 team1-an neutron-linuxbridge-agent[22845]: ERROR 
oslo_service.service   File

[Yahoo-eng-team] [Bug 1752210] [NEW] Counter A ERROR when nova creates instance

[Yahoo-eng-team] [Bug 1752115] Re: detach multiattach volume disconnects innocent bystander

[Yahoo-eng-team] [Bug 1718356] Re: Include default config files in python wheel

[Yahoo-eng-team] [Bug 1627694] Re: unshelving an instance doesn't rollback volumes connections on failure

[Yahoo-eng-team] [Bug 1752152] [NEW] Attach Volume Fails with secure call to cinder

[Yahoo-eng-team] [Bug 1752152] [NEW] Attach Volume Fails with secure call to cinder

[Yahoo-eng-team] [Bug 1627694] Re: unshelving an instance doesn't rollback volumes connections on failure

[Yahoo-eng-team] [Bug 1598783] Re: Config drives created on RHEL/CentOS 7.1 can't be found

[Yahoo-eng-team] [Bug 1737207] Re: Guest admin password and network information is logged at debug if libvirt.inject_partition != -2

[Yahoo-eng-team] [Bug 1749215] Re: Allocations not deleted on failed resize_instance

[Yahoo-eng-team] [Bug 1739871] Re: Disable batch delete button when keypairs are deleted

[Yahoo-eng-team] [Bug 1748062] Re: idp_id, protocol_id, unique_id and name filter doesn't work for list_users API when domain_specific_drivers_enabled is set

[Yahoo-eng-team] [Bug 1659691] Re: neutron-vpnaas tempest job improvement

[Yahoo-eng-team] [Bug 1752030] [NEW] Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.

[Yahoo-eng-team] [Bug 1752006] [NEW] [FWaaS] firewall l2 agent extension is not compatible with LinuxBridge agent

15 matches

Site Navigation

Mail list logo

Footer information