[Yahoo-eng-team] [Bug 1695147] [NEW] Unnecessary query is running to update the resource of the security group

[Kiran Totad]

Public bug reported:

When we try to delete a security group, unnecessary query is running to
update the resource of the security group which we are deleting.

Example: At the time of delete operation 'quotausages' table is being updated 
by resource (security_group_rule) which are not available in it, 
UPDATE query is below:-
UPDATE quotausages SET dirty=1 WHERE quotausages.resource = 
'security_group_rule' AND 
quotausages.tenant_id = '{ID}';

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

Title:
  Unnecessary query is running to update the resource of the security
  group

Status in neutron:
  New

Bug description:
  When we try to delete a security group, unnecessary query is running
  to update the resource of the security group which we are deleting.

  Example: At the time of delete operation 'quotausages' table is being updated 
by resource (security_group_rule) which are not available in it, 
  UPDATE query is below:-
  UPDATE quotausages SET dirty=1 WHERE quotausages.resource = 
'security_group_rule' AND 
  quotausages.tenant_id = '{ID}';

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1695147/+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 1695140] [NEW] SRC without FIP, DEST with FIP case is broken for dvr-multinode

[YAMAMOTO Takashi]

Public bug reported:

communication from a vm without floating-ip to another vm with floating-ip
doesn't work in dvr-multinode setup. [1]
see the result of tempest test cases. [2]

the same test is working well for midonet [3] and linuxbridge. [4]

[1] gate-tempest-dsvm-neutron-dvr-multinode-scenario-ubuntu-xenial-nv
[2] https://review.openstack.org/#/c/424959/
[3] gate-tempest-dsvm-networking-midonet-ml2-ubuntu-xenial
[4] gate-tempest-dsvm-neutron-scenario-linuxbridge-ubuntu-xenial-nv

eg. http://logs.openstack.org/59/424959/6/check/gate-tempest-dsvm-
neutron-dvr-multinode-scenario-ubuntu-xenial-nv/071223e/

2017-06-02 03:07:48,518 347 INFO [tempest.lib.common.ssh] Creating ssh 
connection to '10.1.0.8:22' as 'ubuntu' with public key authentication
2017-06-02 03:07:48,518 347 INFO [tempest.lib.common.ssh] Creating ssh 
connection to '172.24.5.21:22' as 'ubuntu' with public key authentication
2017-06-02 03:07:48,712 347 INFO [paramiko.transport] Connected (version 
2.0, client OpenSSH_7.2p2)
2017-06-02 03:07:48,911 347 INFO [paramiko.transport] Authentication 
(publickey) successful!
2017-06-02 03:07:48,925 347 INFO [tempest.lib.common.ssh] ssh connection to 
ubuntu@172.24.5.21 successfully created
2017-06-02 03:07:51,806 347 INFO [paramiko.transport] Connected (version 
2.0, client OpenSSH_7.2p2)
2017-06-02 03:07:52,052 347 INFO [paramiko.transport] Authentication 
(publickey) successful!
2017-06-02 03:07:52,059 347 INFO [tempest.lib.common.ssh] ssh connection to 
ubuntu@10.1.0.8 successfully created
2017-06-02 03:07:55,854 347 WARNING  [neutron.tests.tempest.scenario.base] 
Failed to ping IP: 172.24.5.23 via a ssh connection from: 10.1.0.8.

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

Title:
  SRC without FIP,DEST with FIP case is broken for dvr-multinode

Status in neutron:
  New

Bug description:
  communication from a vm without floating-ip to another vm with floating-ip
  doesn't work in dvr-multinode setup. [1]
  see the result of tempest test cases. [2]

  the same test is working well for midonet [3] and linuxbridge. [4]

  [1] gate-tempest-dsvm-neutron-dvr-multinode-scenario-ubuntu-xenial-nv
  [2] https://review.openstack.org/#/c/424959/
  [3] gate-tempest-dsvm-networking-midonet-ml2-ubuntu-xenial
  [4] gate-tempest-dsvm-neutron-scenario-linuxbridge-ubuntu-xenial-nv

  eg. http://logs.openstack.org/59/424959/6/check/gate-tempest-dsvm-
  neutron-dvr-multinode-scenario-ubuntu-xenial-nv/071223e/

  2017-06-02 03:07:48,518 347 INFO [tempest.lib.common.ssh] Creating ssh 
connection to '10.1.0.8:22' as 'ubuntu' with public key authentication
  2017-06-02 03:07:48,518 347 INFO [tempest.lib.common.ssh] Creating ssh 
connection to '172.24.5.21:22' as 'ubuntu' with public key authentication
  2017-06-02 03:07:48,712 347 INFO [paramiko.transport] Connected (version 
2.0, client OpenSSH_7.2p2)
  2017-06-02 03:07:48,911 347 INFO [paramiko.transport] Authentication 
(publickey) successful!
  2017-06-02 03:07:48,925 347 INFO [tempest.lib.common.ssh] ssh connection 
to ubuntu@172.24.5.21 successfully created
  2017-06-02 03:07:51,806 347 INFO [paramiko.transport] Connected (version 
2.0, client OpenSSH_7.2p2)
  2017-06-02 03:07:52,052 347 INFO [paramiko.transport] Authentication 
(publickey) successful!
  2017-06-02 03:07:52,059 347 INFO [tempest.lib.common.ssh] ssh connection 
to ubuntu@10.1.0.8 successfully created
  2017-06-02 03:07:55,854 347 WARNING  [neutron.tests.tempest.scenario.base] 
Failed to ping IP: 172.24.5.23 via a ssh connection from: 10.1.0.8.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1695140/+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 1695139] [NEW] nova-placement-api detailed document

[chuang]

Public bug reported:

Description
===
When I is ready to install [nova-placement-api], I find that not detailed 
document describe how to install and configure [nova-placement-api].

Steps
=
When I have installed [nova-compute], I found many *WARNNING* logs. eg:

WARNING nova.scheduler.client.report [req-642b06ce-08e7-4a07-b6c2-f53d429aa4fd 
None None] Placement API service is not responding.
WARNING nova.scheduler.client.report [req-642b06ce-08e7-4a07-b6c2-f53d429aa4fd 
None None] Placement API service is not responding.
WARNING nova.scheduler.client.report [req-642b06ce-08e7-4a07-b6c2-f53d429aa4fd 
None None] Unable to refresh my resource provider record
WARNING nova.scheduler.client.report [req-642b06ce-08e7-4a07-b6c2-f53d429aa4fd 
None None] Placement API service is not responding.
WARNING nova.scheduler.client.report [req-642b06ce-08e7-4a07-b6c2-f53d429aa4fd 
None None] Placement API service is not responding.
WARNING nova.scheduler.client.report [req-642b06ce-08e7-4a07-b6c2-f53d429aa4fd 
None None] Unable to refresh my resource provider record
WARNING nova.scheduler.client.report [req-642b06ce-08e7-4a07-b6c2-f53d429aa4fd 
None None] Placement API service is not responding.

I carefully view the [nova-compute] code. I find that when the [nova-compute] 
starts to running, it invokes the "ComputeManager.update_available_resources" 
to update the resources of the current compute node into the database. 
Then, "ResourceTracker.update_available_resource", 
"ResourceTracker._init_compute_node" are invoked, this will initialize the 
compute node if it does not already exist. Then, 
"SchedulerReportClient.update_compute_node" is invoked to update the resource 
of  the current compute node. Here. I find that it will send the request to the 
placement-api, but i'm not.
So, how to install and configure placement-api?

Environment
===
commit 7280f4fc4c5a2203ac2f59a9df0525488ac2c1ff
Author: Artom Lifshitz 
Date:   Mon Jan 9 18:57:17 2017 +

Libvirt support for tagged volume attachment

This patch adds support for tagged volume attachment to the libvirt
driver.

Change-Id: I8b475992b881db08cf1354299cc86042413074cc
Implements: blueprint bp/virt-device-tagged-attach-detach

** Affects: nova
 Importance: Undecided
 Status: New

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

Title:
  nova-placement-api detailed document

Status in OpenStack Compute (nova):
  New

Bug description:
  Description
  ===
  When I is ready to install [nova-placement-api], I find that not detailed 
document describe how to install and configure [nova-placement-api].

  Steps
  =
  When I have installed [nova-compute], I found many *WARNNING* logs. eg:

  WARNING nova.scheduler.client.report 
[req-642b06ce-08e7-4a07-b6c2-f53d429aa4fd None None] Placement API service is 
not responding.
  WARNING nova.scheduler.client.report 
[req-642b06ce-08e7-4a07-b6c2-f53d429aa4fd None None] Placement API service is 
not responding.
  WARNING nova.scheduler.client.report 
[req-642b06ce-08e7-4a07-b6c2-f53d429aa4fd None None] Unable to refresh my 
resource provider record
  WARNING nova.scheduler.client.report 
[req-642b06ce-08e7-4a07-b6c2-f53d429aa4fd None None] Placement API service is 
not responding.
  WARNING nova.scheduler.client.report 
[req-642b06ce-08e7-4a07-b6c2-f53d429aa4fd None None] Placement API service is 
not responding.
  WARNING nova.scheduler.client.report 
[req-642b06ce-08e7-4a07-b6c2-f53d429aa4fd None None] Unable to refresh my 
resource provider record
  WARNING nova.scheduler.client.report 
[req-642b06ce-08e7-4a07-b6c2-f53d429aa4fd None None] Placement API service is 
not responding.

  I carefully view the [nova-compute] code. I find that when the [nova-compute] 
starts to running, it invokes the "ComputeManager.update_available_resources" 
to update the resources of the current compute node into the database. 
  Then, "ResourceTracker.update_available_resource", 
"ResourceTracker._init_compute_node" are invoked, this will initialize the 
compute node if it does not already exist. Then, 
"SchedulerReportClient.update_compute_node" is invoked to update the resource 
of  the current compute node. Here. I find that it will send the request to the 
placement-api, but i'm not.
  So, how to install and configure placement-api?

  Environment
  ===
  commit 7280f4fc4c5a2203ac2f59a9df0525488ac2c1ff
  Author: Artom Lifshitz 
  Date:   Mon Jan 9 18:57:17 2017 +

  Libvirt support for tagged volume attachment
  
  This patch adds support for tagged volume attachment to the libvirt
  driver.
  
  Change-Id: I8b475992b881db08cf1354299cc86042413074cc
  Implements: blueprint bp/virt-device-tagged-attach-detach

To manage notifications about this bug go to:

[Yahoo-eng-team] [Bug 1694897] Re: neutron tag xxx.xxx doesn't work correctly

[OpenStack Infra]

Reviewed:  https://review.openstack.org/470016
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=527468be33407d65a940f1cd1e7a5a0bbbe12795
Submitter: Jenkins
Branch:master

commit 527468be33407d65a940f1cd1e7a5a0bbbe12795
Author: Ihar Hrachyshka 
Date:   Thu Jun 1 21:08:20 2017 +

api: work around Routes cutting off suffix from resource id

Routes allows for auxiliary format suffix. Sadly it doesn't distinguish
between an actual format suffix (.json) and any other suffix that may be
part of the id. (like for first.second resource tag). To work this
behavior around, we will reattach the 'format' suffix if it is not of a
supported format (json only at the time of writing).

This of course leaves a corner case where there is a tag where .json is
a part of its id. This seems to be a reasonable balance to leave it
unfixed, because an alternative would probably be not backwards
compatible.

Closes-Bug: #1694897
Change-Id: I271107150166f0ee680faaa2e3ca6044cf4e8d4f


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

Title:
  neutron tag xxx.xxx doesn't work correctly

Status in neutron:
  Fix Released
Status in Zun:
  Invalid

Bug description:
  Steps to reproduce:

$ neutron tag-add --resource-type network --resource private --tag 
first.second
$ neutron net-show private
neutron CLI is deprecated and will be removed in the future. Use openstack 
CLI instead.
+-+--+
| Field   | Value|
+-+--+
...
| tags| first|
...
+-+--+

  The second half of the tag is not there.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1694897/+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 1695131] [NEW] DirectMappingError shows incorrect message when insecure_debug set to true

[yangweiwei]

Public bug reported:

When I set the rule below:
[
{
"local": [
{
"user":{
   "name":"{0}"
   }
},
{
"group": {
   "id":"c59d9770089b4d5aaa893973bbcfb538"
}
}
],
"remote":[
  {
  "type":"openstack_user",
  "any_one_of": [
"bob"
   ]
  }
 ]
}
]

and I want to get the unscoped token, the error shows:

keystoneauth1.exceptions.http.InternalServerError: An unexpected error
prevented the server from fulfilling your request. (HTTP 500) (Request-
ID: req-94ec1d2f-4e3e-4174-a1d7-1ff574169f1f)


Then I set the 'insecure_debug' to 'True', the error shows:
keystoneauth1.exceptions.http.InternalServerError: An unexpected error 
prevented the server from fulfilling your request: . (Disable insecure_debug 
mode to suppress these details.) (HTTP 500) (Request-ID: 
req-eb26c090-87b2-4fa8-90d9-004928a61711)


I have digging the error happens in '_update_local_mapping' method in 
keystone/federation/utils.py.
Some logs bellow:

2017-06-02 09:48:02.160 2933 DEBUG keystone.federation.utils 
[req-94ec1d2f-4e3e-4174-a1d7-1ff574169f1f - - - - -] {u'remote': [{u'type': 
u'openstack_user', u'any_one_of': [u'bob']}], u'local': [{u'user': {u'name': 
u'{0}'}}, {u'group': {u'id': u'c59d9770089b4d5aaa893973bbcfb538'}}]} process 
/usr/lib/python2.7/site-packages/keystone/federation/utils.py:531
2017-06-02 09:48:02.160 2933 DEBUG keystone.federation.utils 
[req-94ec1d2f-4e3e-4174-a1d7-1ff574169f1f - - - - -] _verify_all_requirements 
/usr/lib/python2.7/site-packages/keystone/federation/utils.py:796
2017-06-02 09:48:02.161 2933 DEBUG keystone.federation.utils 
[req-94ec1d2f-4e3e-4174-a1d7-1ff574169f1f - - - - -] _verify_all_requirements 
/usr/lib/python2.7/site-packages/keystone/federation/utils.py:806
2017-06-02 09:48:02.161 2933 DEBUG keystone.federation.utils 
[req-94ec1d2f-4e3e-4174-a1d7-1ff574169f1f - - - - -] 
 process 
/usr/lib/python2.7/site-packages/keystone/federation/utils.py:537
2017-06-02 09:48:02.161 2933 DEBUG keystone.federation.utils 
[req-94ec1d2f-4e3e-4174-a1d7-1ff574169f1f - - - - -] direct_maps: 
 
_update_local_mapping 
/usr/lib/python2.7/site-packages/keystone/federation/utils.py:717
2017-06-02 09:48:02.162 2933 DEBUG keystone.federation.utils 
[req-94ec1d2f-4e3e-4174-a1d7-1ff574169f1f - - - - -] local: {u'user': {u'name': 
u'{0}'}} _update_local_mapping 
/usr/lib/python2.7/site-packages/keystone/federation/utils.py:718
2017-06-02 09:48:02.162 2933 DEBUG keystone.federation.utils 
[req-94ec1d2f-4e3e-4174-a1d7-1ff574169f1f - - - - -] direct_maps: 
 
_update_local_mapping 
/usr/lib/python2.7/site-packages/keystone/federation/utils.py:717
2017-06-02 09:48:02.162 2933 DEBUG keystone.federation.utils 
[req-94ec1d2f-4e3e-4174-a1d7-1ff574169f1f - - - - -] local: {u'name': u'{0}'} 
_update_local_mapping 
/usr/lib/python2.7/site-packages/keystone/federation/utils.py:718
2017-06-02 09:48:02.163 2933 DEBUG keystone.federation.utils 
[req-94ec1d2f-4e3e-4174-a1d7-1ff574169f1f - - - - -] 
{0} _update_local_mapping 
/usr/lib/python2.7/site-packages/keystone/federation/utils.py:728
2017-06-02 09:48:02.169 2933 WARNING oslo_config.cfg 
[req-94ec1d2f-4e3e-4174-a1d7-1ff574169f1f - - - - -] Option "rpc_backend" from 
group "DEFAULT" is deprecated for removal.  Its value may be silently ignored 
in the future.
2017-06-02 09:48:02.191 2933 DEBUG keystone.auth.plugins.mapped 
[req-94ec1d2f-4e3e-4174-a1d7-1ff574169f1f - - - - -] An unexpected error 
prevented the server from fulfilling your request. handle_unscoped_token 
/usr/lib/python2.7/site-packages/keystone/auth/plugins/mapped.py:283
2017-06-02 09:48:02.192 2933 WARNING keystone.common.wsgi 
[req-94ec1d2f-4e3e-4174-a1d7-1ff574169f1f - - - - -] An unexpected error 
prevented the server from fulfilling your request.

** Affects: keystone
 Importance: Undecided
 Assignee: yangweiwei (496176919-6)
 Status: In Progress

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

Title:
  DirectMappingError shows incorrect message when  insecure_debug set to
  true

Status in OpenStack Identity (keystone):
  In Progress

Bug description:
  When I set the rule below:
  [
  {
  "local": [
  {
  "user":{
 "name":"{0}"
 }
  },
  {
  "group": {
 "id":"c59d9770089b4d5aaa893973bbcfb538"
  }
  }
  ],
  "remote":[
{
"type":"openstack_user",
"any_one_of": [
  "bob"
 ]
}
   ]
  }
  ]

  and I want to get the unscoped token, the error shows:

  

[Yahoo-eng-team] [Bug 1695127] [NEW] nova-specs docs builds fail with sphinx 1.6.2: Citation is not referenced.

[Takashi NATSUME]

Public bug reported:

This issue seemed be fixed in https://bugs.launchpad.net/nova/+bug/1693010.
But it has not been fixed yet.

http://logs.openstack.org/47/460847/5/check/gate-nova-specs-docs-ubuntu-
xenial/e4e669b/console.html

2017-06-01 23:31:09.904757 | Running Sphinx v1.6.2
(snipped...)
2017-06-01 23:31:44.280392 | scanning 
/home/jenkins/workspace/gate-nova-specs-docs-ubuntu-xenial/doc/source for 
redirects...
2017-06-01 23:31:44.281018 |found redirects at 
/home/jenkins/workspace/gate-nova-specs-docs-ubuntu-xenial/doc/source/specs/juno/redirects
2017-06-01 23:31:44.287320 |found redirects at 
/home/jenkins/workspace/gate-nova-specs-docs-ubuntu-xenial/doc/source/specs/liberty/redirects
2017-06-01 23:31:44.290284 |found redirects at 
/home/jenkins/workspace/gate-nova-specs-docs-ubuntu-xenial/doc/source/specs/queens/redirects
2017-06-01 23:31:44.290664 |found redirects at 
/home/jenkins/workspace/gate-nova-specs-docs-ubuntu-xenial/doc/source/specs/kilo/redirects
2017-06-01 23:31:44.293625 |found redirects at 
/home/jenkins/workspace/gate-nova-specs-docs-ubuntu-xenial/doc/source/specs/ocata/redirects
2017-06-01 23:31:44.295852 |found redirects at 
/home/jenkins/workspace/gate-nova-specs-docs-ubuntu-xenial/doc/source/specs/pike/redirects
2017-06-01 23:31:44.296663 |found redirects at 
/home/jenkins/workspace/gate-nova-specs-docs-ubuntu-xenial/doc/source/specs/mitaka/redirects
2017-06-01 23:31:44.300105 |found redirects at 
/home/jenkins/workspace/gate-nova-specs-docs-ubuntu-xenial/doc/source/specs/newton/redirects
2017-06-01 23:31:44.304215 | ...done
2017-06-01 23:31:45.098021 | pickling environment... done
2017-06-01 23:31:45.099044 | checking consistency... 
2017-06-01 23:31:45.099110 | Warning, treated as error:
2017-06-01 23:31:45.099207 | 
/home/jenkins/workspace/gate-nova-specs-docs-ubuntu-xenial/doc/source/specs/juno/implemented/pci-passthrough-sriov.rst:412:Citation
 [VIF_DETA] is not referenced.
2017-06-01 23:31:45.323528 | ERROR: InvocationError: 
'/home/jenkins/workspace/gate-nova-specs-docs-ubuntu-xenial/.tox/venv/bin/python
 setup.py build_sphinx'
2017-06-01 23:31:45.323612 | ___ summary 

2017-06-01 23:31:45.323637 | ERROR:   venv: commands failed
2017-06-01 23:31:45.334621 | [Zuul] Task exit code: 1
2017-06-01 23:31:46.425403 | [Zuul] Job complete, result: FAILURE

** Affects: nova
 Importance: Undecided
 Assignee: Takashi NATSUME (natsume-takashi)
 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/1695127

Title:
  nova-specs docs builds fail with sphinx 1.6.2: Citation is not
  referenced.

Status in OpenStack Compute (nova):
  New

Bug description:
  This issue seemed be fixed in https://bugs.launchpad.net/nova/+bug/1693010.
  But it has not been fixed yet.

  http://logs.openstack.org/47/460847/5/check/gate-nova-specs-docs-
  ubuntu-xenial/e4e669b/console.html

  2017-06-01 23:31:09.904757 | Running Sphinx v1.6.2
  (snipped...)
  2017-06-01 23:31:44.280392 | scanning 
/home/jenkins/workspace/gate-nova-specs-docs-ubuntu-xenial/doc/source for 
redirects...
  2017-06-01 23:31:44.281018 |found redirects at 
/home/jenkins/workspace/gate-nova-specs-docs-ubuntu-xenial/doc/source/specs/juno/redirects
  2017-06-01 23:31:44.287320 |found redirects at 
/home/jenkins/workspace/gate-nova-specs-docs-ubuntu-xenial/doc/source/specs/liberty/redirects
  2017-06-01 23:31:44.290284 |found redirects at 
/home/jenkins/workspace/gate-nova-specs-docs-ubuntu-xenial/doc/source/specs/queens/redirects
  2017-06-01 23:31:44.290664 |found redirects at 
/home/jenkins/workspace/gate-nova-specs-docs-ubuntu-xenial/doc/source/specs/kilo/redirects
  2017-06-01 23:31:44.293625 |found redirects at 
/home/jenkins/workspace/gate-nova-specs-docs-ubuntu-xenial/doc/source/specs/ocata/redirects
  2017-06-01 23:31:44.295852 |found redirects at 
/home/jenkins/workspace/gate-nova-specs-docs-ubuntu-xenial/doc/source/specs/pike/redirects
  2017-06-01 23:31:44.296663 |found redirects at 
/home/jenkins/workspace/gate-nova-specs-docs-ubuntu-xenial/doc/source/specs/mitaka/redirects
  2017-06-01 23:31:44.300105 |found redirects at 
/home/jenkins/workspace/gate-nova-specs-docs-ubuntu-xenial/doc/source/specs/newton/redirects
  2017-06-01 23:31:44.304215 | ...done
  2017-06-01 23:31:45.098021 | pickling environment... done
  2017-06-01 23:31:45.099044 | checking consistency... 
  2017-06-01 23:31:45.099110 | Warning, treated as error:
  2017-06-01 23:31:45.099207 | 
/home/jenkins/workspace/gate-nova-specs-docs-ubuntu-xenial/doc/source/specs/juno/implemented/pci-passthrough-sriov.rst:412:Citation
 [VIF_DETA] is not referenced.
  2017-06-01 23:31:45.323528 | ERROR: InvocationError: 

[Yahoo-eng-team] [Bug 1695101] [NEW] DVR Router ports and gateway ports are not bound to any host and no snat namespace created

[Swaminathan Vasudevan]

Public bug reported:

In the Pike cycle there were some refactoring to the DVR db classes and 
resource handler mixin. 
This lead to the regression where it was not creating the SNAT namespace for 
the DVR routers if it has gateway configured.

The only namespace seen was the fipnamespace.

This was the patch set that caused the regression.
https://review.openstack.org/#/c/457592/5

On further debugging it was found that the snat ports and the
distributed router ports were not host bound. The neutron was trying to
bind it to a 'null' host.

The '_build_routers_list' function in the l3_dvr_db.py was not called
and hence the host binding was missing.

We have seen a similar issue a while back, #1369012 (Fix KeyError on
missing gw_port_host for L3 agent in DVR mode

The issue here is the order of inheritance of the classes. If the order
of inheritance of the classes are messed up, then the functions that are
over-ridden are not called in the right order or skipped.

So with this we have seen the same problem, where the
'_build_routers_list' in the l3_db_gwmode.py was called and not the one
in the 'l3_dvr_db.py' file.

This is the current order of inheritance.

class L3_NAT_with_dvr_db_mixin(l3_db.L3_NAT_db_mixin,
   l3_attrs_db.ExtraAttributesMixin,
   DVRResourceOperationHandler,
  _DVRAgentInterfaceMixin):

If the order is shuffled, it works fine and here is the shuffled order.

class L3_NAT_with_dvr_db_mixin(DVRResourceOperationHandler,
   _DVRAgentInterfaceMixin,
   l3_attrs_db.ExtraAttributesMixin,
   l3_db.L3_NAT_db_mixin):

This seems to fix the problem.

** Affects: neutron
 Importance: Undecided
 Assignee: Swaminathan Vasudevan (swaminathan-vasudevan)
 Status: Confirmed


** Tags: l3-dvr-backlog

** Tags added: l3-dvr-backlog

** Changed in: neutron
 Assignee: (unassigned) => Swaminathan Vasudevan (swaminathan-vasudevan)

** Changed in: neutron
   Status: New => Confirmed

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

Title:
  DVR Router ports and gateway ports are not bound to any host and no
  snat namespace created

Status in neutron:
  Confirmed

Bug description:
  In the Pike cycle there were some refactoring to the DVR db classes and 
resource handler mixin. 
  This lead to the regression where it was not creating the SNAT namespace for 
the DVR routers if it has gateway configured.

  The only namespace seen was the fipnamespace.

  This was the patch set that caused the regression.
  https://review.openstack.org/#/c/457592/5

  On further debugging it was found that the snat ports and the
  distributed router ports were not host bound. The neutron was trying
  to bind it to a 'null' host.

  The '_build_routers_list' function in the l3_dvr_db.py was not called
  and hence the host binding was missing.

  We have seen a similar issue a while back, #1369012 (Fix KeyError on
  missing gw_port_host for L3 agent in DVR mode

  The issue here is the order of inheritance of the classes. If the
  order of inheritance of the classes are messed up, then the functions
  that are over-ridden are not called in the right order or skipped.

  So with this we have seen the same problem, where the
  '_build_routers_list' in the l3_db_gwmode.py was called and not the
  one in the 'l3_dvr_db.py' file.

  This is the current order of inheritance.

  class L3_NAT_with_dvr_db_mixin(l3_db.L3_NAT_db_mixin,
 l3_attrs_db.ExtraAttributesMixin,
 DVRResourceOperationHandler,
_DVRAgentInterfaceMixin):

  If the order is shuffled, it works fine and here is the shuffled
  order.

  class L3_NAT_with_dvr_db_mixin(DVRResourceOperationHandler,
 _DVRAgentInterfaceMixin,
 l3_attrs_db.ExtraAttributesMixin,
 l3_db.L3_NAT_db_mixin):

  This seems to fix the problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1695101/+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 1694337] Re: Port information (binding:host_id) not updated for network:router_gateway after qRouter failover

[OpenStack Infra]

Reviewed:  https://review.openstack.org/466414
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=d8334b41d2c5bcd4916347d20008b1538d48b0ef
Submitter: Jenkins
Branch:master

commit d8334b41d2c5bcd4916347d20008b1538d48b0ef
Author: Felipe Reyes 
Date:   Fri May 19 17:13:52 2017 -0400

Update the host_id for network:router_gateway interfaces

The ports owned by a router_gateway need to get its host_id property
updated during the failover of a router. Otherwise the port connected
to the external network will always have its host_id set to the value
obtained during creation.

Change-Id: I5eca20e3cc64d7a9e52b0556a3cadd29eb4c821d
Closes-Bug: 1694337


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

Title:
  Port information (binding:host_id) not updated for
  network:router_gateway after qRouter failover

Status in neutron:
  Fix Released

Bug description:
  [Impact]

  When using l3 ha and a router agent fails over, the interface holding
  the network:router_gateway interface does not get its property
  binding:host_id updated to reflect where the keepalived moved the
  router.

  [Steps to reproduce]

  0) Deploy a cloud with l3ha enabled
- If familiar with juju, it's possible to use this bundle 
http://paste.ubuntu.com/24707730/ , but the deployment tool is not relevant

  1) Once it's deployed, configure it and create a router see 
https://docs.openstack.org/mitaka/networking-guide/deploy-lb-ha-vrrp.html )
- This is the script used during the troubleshooting
  -8<--
  #!/bin/bash -x

  source novarc  # admin

  neutron net-create ext-net --router:external True
  --provider:physical_network physnet1 --provider:network_type flat

  neutron subnet-create ext-net 10.5.0.0/16 --name ext-subnet
  --allocation-pool start=10.5.254.100,end=10.5.254.199 --disable-dhcp
  --gateway 10.5.0.1 --dns-nameserver 10.5.0.3

  keystone tenant-create --name demo 2>/dev/null
  keystone user-role-add --user admin --tenant demo --role Admin 2>/dev/null

  export TENANT_ID_DEMO=$(keystone tenant-list | grep demo | awk -F'|'
  '{print $2}' | tr -d ' ' 2>/dev/null )

  neutron net-create demo-net --tenant-id ${TENANT_ID_DEMO}
  --provider:network_type vxlan

  env OS_TENANT_NAME=demo neutron subnet-create demo-net 192.168.1.0/24 --name 
demo-subnet --gateway 192.168.1.1
  env OS_TENANT_NAME=demo neutron router-create demo-router
  env OS_TENANT_NAME=demo neutron router-interface-add demo-router demo-subnet
  env OS_TENANT_NAME=demo neutron router-gateway-set demo-router ext-net

  # verification
  neutron net-list
  neutron l3-agent-list-hosting-router demo-router
  neutron router-port-list demo-router
  - 8< ---

  2) Kill the associated master keepalived process for the router
  ps aux | grep keepalived | grep $ROUTER_ID
  kill $PID

  3) Wait until "neutron l3-agent-list-hosting-router demo-router" shows the 
other host as active
  4) Check the binding:host_id property for the interfaces of the router
  for ID in `neutron port-list --device-id $ROUTER_ID | tail -n +4 | head 
-n -1| awk -F' ' '{print $2}' `; do neutron port-show $ID ; done

  Expected results:

  The interface where the device_owner is network:router_gateway has its
  property binding:host_id set to where the keepalived process is master

  Actual result:

  The binding:host_id is never updated, it stays set with the value
  obtainer during the creation of the port.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1694337/+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 1695092] [NEW] sysconfig only applies subnet/route config to physical interfaces

[Ryan Harper]

Public bug reported:

cloud-init master

Testing bridging configuration.  First, empty subnets break sysconfig
rendering; this has been reported in other bugs), after that, the
resulting ifcfg-br0 does not include the static network configuration.
Upon closer examination the _render_interface_subnets and routes is only
called in the _render_physical_interface code.  Instead, this should be
called on *any* interface as we can configure subnets and routes on
vlans or bridges, bonds, etc.

% cat bridge.yaml
network:
version: 1
config:
- type: physical
  name: eth0
  mac_address: "52:54:00:12:34:00"
  subnets:
  - type: dhcp4
- type: physical
  name: eth1
  mac_address: "52:54:00:12:34:02"
- type: physical
  name: eth2
  mac_address: "52:54:00:12:34:04"
- type: bridge
  name: br0
  bridge_interfaces:
- eth1
- eth2
  params:
  bridge_ageing: 250
  bridge_bridgeprio: 22
  bridge_fd: 1
  bridge_gcint: 2
  bridge_hello: 1
  bridge_maxage: 10
  bridge_maxwait: 0
  bridge_pathcost:
- eth1 50
- eth2 75
  bridge_portprio:
- eth1 28
- eth2 14
  bridge_stp: 'off'
  bridge_waitport:
- 1 eth1
- 2 eth2
  subnets:
  - type: static
address: 192.168.14.2/24

After fixing the empty subnet issue, we can see in net-convert rendering of 
ifcfg-br0 is missing
the 192.168.14.2/24 address.

% cat target-sysconfig/etc/sysconfig/network-scripts/ifcfg-br0 
# Created by cloud-init on instance boot automatically, do not edit.
#
AGEING=250
BOOTPROTO=none
DEVICE=br0
NM_CONTROLLED=no
ONBOOT=yes
PRIO=22
STP=off
TYPE=Bridge
USERCTL=no

** Affects: cloud-init
 Importance: Undecided
 Status: New


** Tags: centos7

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

Title:
  sysconfig only applies subnet/route config to physical interfaces

Status in cloud-init:
  New

Bug description:
  cloud-init master

  Testing bridging configuration.  First, empty subnets break sysconfig
  rendering; this has been reported in other bugs), after that, the
  resulting ifcfg-br0 does not include the static network configuration.
  Upon closer examination the _render_interface_subnets and routes is
  only called in the _render_physical_interface code.  Instead, this
  should be called on *any* interface as we can configure subnets and
  routes on vlans or bridges, bonds, etc.

  % cat bridge.yaml
  network:
  version: 1
  config:
  - type: physical
name: eth0
mac_address: "52:54:00:12:34:00"
subnets:
- type: dhcp4
  - type: physical
name: eth1
mac_address: "52:54:00:12:34:02"
  - type: physical
name: eth2
mac_address: "52:54:00:12:34:04"
  - type: bridge
name: br0
bridge_interfaces:
  - eth1
  - eth2
params:
bridge_ageing: 250
bridge_bridgeprio: 22
bridge_fd: 1
bridge_gcint: 2
bridge_hello: 1
bridge_maxage: 10
bridge_maxwait: 0
bridge_pathcost:
  - eth1 50
  - eth2 75
bridge_portprio:
  - eth1 28
  - eth2 14
bridge_stp: 'off'
bridge_waitport:
  - 1 eth1
  - 2 eth2
subnets:
- type: static
  address: 192.168.14.2/24

  After fixing the empty subnet issue, we can see in net-convert rendering of 
ifcfg-br0 is missing
  the 192.168.14.2/24 address.

  % cat target-sysconfig/etc/sysconfig/network-scripts/ifcfg-br0 
  # Created by cloud-init on instance boot automatically, do not edit.
  #
  AGEING=250
  BOOTPROTO=none
  DEVICE=br0
  NM_CONTROLLED=no
  ONBOOT=yes
  PRIO=22
  STP=off
  TYPE=Bridge
  USERCTL=no

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1695092/+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 1694897] Re: neutron tag xxx.xxx doesn't work correctly

[Armando Migliaccio]

Workaround for now would be to use anything other than a '.' as
delimiter. The server freaks out when it sees one in tags.

** Changed in: python-neutronclient
   Importance: Critical => Low

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

** No longer affects: python-neutronclient

** Changed in: neutron
   Status: New => Confirmed

** Changed in: neutron
   Importance: Undecided => Low

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

Title:
  neutron tag xxx.xxx doesn't work correctly

Status in neutron:
  Confirmed
Status in Zun:
  Invalid

Bug description:
  Steps to reproduce:

$ neutron tag-add --resource-type network --resource private --tag 
first.second
$ neutron net-show private
neutron CLI is deprecated and will be removed in the future. Use openstack 
CLI instead.
+-+--+
| Field   | Value|
+-+--+
...
| tags| first|
...
+-+--+

  The second half of the tag is not there.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1694897/+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 1695066] [NEW] sysconfig doesn't render bond configurations correctly

[Ryan Harper]

Public bug reported:

cloud-init master using net-convert, we can see that the bond
configuration is not complete with the following input network
configuration


% cat bonding.yaml
network:
version: 1
config:
- type: physical
  name: interface0
  mac_address: "52:54:00:12:34:00"
  subnets:
  - type: dhcp4
- type: physical
  name: interface1
  mac_address: "52:54:00:12:34:02"
- type: physical
  name: interface2
  mac_address: "52:54:00:12:34:04"
- type: bond
  name: bond0
  mac_address: "52:54:00:12:34:06"
  bond_interfaces:
- interface1
- interface2
  params:
bond-mode: active-backup
  subnets:
  - type: static
address: 10.23.23.2/24
  - type: static
address: 10.23.24.2/24

% Traceback (most recent call last):
  File "./tools/net-convert.py", line 82, in 
main()
  File "./tools/net-convert.py", line 78, in main
r.render_network_state(ns, target=args.directory)
  File "/home/rharper/work/git/cloud-init/cloudinit/net/sysconfig.py", line 
501, in render_network_state
network_state).items():
  File "/home/rharper/work/git/cloud-init/cloudinit/net/sysconfig.py", line 
479, in _render_sysconfig
cls._render_physical_interfaces(network_state, iface_contents)
  File "/home/rharper/work/git/cloud-init/cloudinit/net/sysconfig.py", line 
406, in _render_physical_interfaces
cls._render_subnets(iface_cfg, iface_subnets)
  File "/home/rharper/work/git/cloud-init/cloudinit/net/sysconfig.py", line 
272, in _render_subnets
for i, subnet in enumerate(subnets, start=len(iface_cfg.children)):
TypeError: 'NoneType' object is not iterable


Even with small fixes to handle empty subnets or routes, the current 
_render_bond_interfaces doesn't write out the required bonding key value pairs.

** Affects: cloud-init
 Importance: Undecided
 Status: New


** Tags: centos7

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

Title:
  sysconfig doesn't render bond configurations correctly

Status in cloud-init:
  New

Bug description:
  cloud-init master using net-convert, we can see that the bond
  configuration is not complete with the following input network
  configuration

  
  % cat bonding.yaml
  network:
  version: 1
  config:
  - type: physical
name: interface0
mac_address: "52:54:00:12:34:00"
subnets:
- type: dhcp4
  - type: physical
name: interface1
mac_address: "52:54:00:12:34:02"
  - type: physical
name: interface2
mac_address: "52:54:00:12:34:04"
  - type: bond
name: bond0
mac_address: "52:54:00:12:34:06"
bond_interfaces:
  - interface1
  - interface2
params:
  bond-mode: active-backup
subnets:
- type: static
  address: 10.23.23.2/24
- type: static
  address: 10.23.24.2/24

  % Traceback (most recent call last):
File "./tools/net-convert.py", line 82, in 
  main()
File "./tools/net-convert.py", line 78, in main
  r.render_network_state(ns, target=args.directory)
File "/home/rharper/work/git/cloud-init/cloudinit/net/sysconfig.py", line 
501, in render_network_state
  network_state).items():
File "/home/rharper/work/git/cloud-init/cloudinit/net/sysconfig.py", line 
479, in _render_sysconfig
  cls._render_physical_interfaces(network_state, iface_contents)
File "/home/rharper/work/git/cloud-init/cloudinit/net/sysconfig.py", line 
406, in _render_physical_interfaces
  cls._render_subnets(iface_cfg, iface_subnets)
File "/home/rharper/work/git/cloud-init/cloudinit/net/sysconfig.py", line 
272, in _render_subnets
  for i, subnet in enumerate(subnets, start=len(iface_cfg.children)):
  TypeError: 'NoneType' object is not iterable

  
  Even with small fixes to handle empty subnets or routes, the current 
_render_bond_interfaces doesn't write out the required bonding key value pairs.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1695066/+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 1673569] Re: [OSSA-2017-002] Failed notification payload is dumped in logs with auth secrets (CVE-2017-7214)

[Launchpad Bug Tracker]

This bug was fixed in the package nova - 2:14.0.5-0ubuntu1

---
nova (2:14.0.5-0ubuntu1) yakkety; urgency=medium

  [Saverio Proto]
  * New upstream point release for OpenStack Newton (LP: #1688557).

  [Corey Bryant]
  * SECURITY UPDATE: Failed notification payload is dumped in logs
with auth secrets (LP: #1673569).
- This is included from upstream in the 14.0.5 stable point release.
- CVE-2017-7214

 -- Corey Bryant   Mon, 15 May 2017 08:37:32
-0400

** Changed in: nova (Ubuntu Yakkety)
   Status: Fix Committed => 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/1673569

Title:
  [OSSA-2017-002] Failed notification payload is dumped in logs with
  auth secrets (CVE-2017-7214)

Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive mitaka series:
  New
Status in Ubuntu Cloud Archive newton series:
  Fix Committed
Status in Ubuntu Cloud Archive ocata series:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) mitaka series:
  Fix Released
Status in OpenStack Compute (nova) newton series:
  Fix Released
Status in OpenStack Compute (nova) ocata series:
  Fix Released
Status in OpenStack Security Advisory:
  Fix Released
Status in nova package in Ubuntu:
  Fix Released
Status in nova source package in Xenial:
  New
Status in nova source package in Yakkety:
  Fix Released
Status in nova source package in Zesty:
  Fix Released
Status in nova source package in Artful:
  Fix Released

Bug description:
  Noticed here:

  http://logs.openstack.org/08/445308/3/check/gate-tempest-dsvm-py35
  -ubuntu-
  xenial/7bf0d72/logs/screen-n-api.txt.gz#_2017-03-16_05_31_09_399

  I noticed this while investigating public nova bug 1673375, but it
  looks like that bug is caused by a ValueError coming from the
  oslo.messaging notification code, related to a circular reference in
  the json blob:

  2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging Traceback 
(most recent call last):
  2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging   File 
"/usr/local/lib/python3.5/dist-packages/oslo_messaging/notify/messaging.py", 
line 70, in notify
  2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging 
retry=retry)
  2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging   File 
"/usr/local/lib/python3.5/dist-packages/oslo_messaging/transport.py", line 104, 
in _send_notification
  2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging 
retry=retry)
  2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging   File 
"/usr/local/lib/python3.5/dist-packages/oslo_messaging/_drivers/amqpdriver.py", 
line 509, in send_notification
  2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging 
envelope=(version == 2.0), notify=True, retry=retry)
  2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging   File 
"/usr/local/lib/python3.5/dist-packages/oslo_messaging/_drivers/amqpdriver.py", 
line 457, in _send
  2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging msg = 
rpc_common.serialize_msg(msg)
  2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging   File 
"/usr/local/lib/python3.5/dist-packages/oslo_messaging/_drivers/common.py", 
line 293, in serialize_msg
  2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging 
_MESSAGE_KEY: jsonutils.dumps(raw_msg)}
  2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging   File 
"/usr/local/lib/python3.5/dist-packages/oslo_serialization/jsonutils.py", line 
190, in dumps
  2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging 
return json.dumps(obj, default=default, **kwargs)
  2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging   File 
"/usr/lib/python3.5/json/__init__.py", line 237, in dumps
  2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging 
**kw).encode(obj)
  2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging   File 
"/usr/lib/python3.5/json/encoder.py", line 198, in encode
  2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging 
chunks = self.iterencode(o, _one_shot=True)
  2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging   File 
"/usr/lib/python3.5/json/encoder.py", line 256, in iterencode
  2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging 
return _iterencode(o, 0)
  2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging 
ValueError: Circular reference detected
  2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging

  The security issue here is that the notification payload that's logged
  has all kinds of auth secrets in it, like tokens and passwords.

  From logstash it looks like this is only 

[Yahoo-eng-team] [Bug 1694505] Re: neutron-ovs-agent dies with return code 0 when neutron-server is down

[OpenStack Infra]

Reviewed:  https://review.openstack.org/469231
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=73701bf75b964509c7d7e8b62dba97f7cbe9c87a
Submitter: Jenkins
Branch:master

commit 73701bf75b964509c7d7e8b62dba97f7cbe9c87a
Author: Ihar Hrachyshka 
Date:   Tue May 30 19:42:16 2017 +

ovs: bubble up failures into main thread in native ofctl mode

When native ofctl interface is used (the default), the agent main() is
running in a separate gevent thread. Unless we explicitly request from
ryu to raise errors that may have happened in the agent app, it will
ignore them (only logging a warning message). This may interfere with
service management software like systemd that may use the return code to
decide whether to restart the dead service.

This patch makes ryu raise any uncaught errors happening inside the
agent. It also makes the agent 'wrapper' helper function not to swallow
raised exceptions on logging the error. Those two changes combined make
the agent exit with rc=1 if an exception happens inside the main()
function when in native mode.

This patch doesn't include any unit tests because those would be very
silly (like checking that we indeed pass the needed arguments to ryu).

Change-Id: Ic86b5eeae25a916c3c51f21e6820f5b0212dd5f8
Closes-Bug: #1694505


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

Title:
  neutron-ovs-agent dies with return code 0 when neutron-server is down

Status in neutron:
  Fix Released

Bug description:
  Environment description:

  - Deployment using RDO Trunk repo from master.
  - Neutron based on commit c430e9b

  In neutron-ovs-agent is started before neutron-server starts, it exits
  with return code 0, which is not identified by systemd as a failure so
  it's not restarted.

  following ERRORS appear in /var/log/neutron/openvswitch-agent.log:

  2017-05-30 17:38:48.692 29042 DEBUG neutron.api.rpc.handlers.resources_rpc 
[req-b5a96471-f0e2-4b24-938c-27ed4d8502c9 - - - - -] 
neutron.api.rpc.handlers.resources_rpc.ResourcesPullRpcApi met
  hod bulk_pull called with arguments (, 'Port') {} wrapper 
/usr/lib/python2.7/site-packages/oslo_log/helpers.py:47
  2017-05-30 17:38:49.298 29042 DEBUG ovsdbapp.backend.ovs_idl.vlog [-] 
[POLLIN] on fd 12 __log_wakeup 
/usr/lib/python2.7/site-packages/ovs/poller.py:202

  
  2017-05-30 17:40:26.506 29042 DEBUG ovsdbapp.backend.ovs_idl.vlog [-] 
[POLLIN] on fd 12 __log_wakeup 
/usr/lib/python2.7/site-packages/ovs/poller.py:202
  2017-05-30 17:40:27.530 29042 ERROR 
neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp 
[req-b5a96471-f0e2-4b24-938c-27ed4d8502c9 - - - - -] Agent main thread died of 
an exception
  ...
  2017-05-30 17:40:27.530 29042 ERROR 
neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp 
'to message ID %s' % msg_id)
  2017-05-30 17:40:27.530 29042 ERROR 
neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp 
MessagingTimeout: Timed out waiting for a reply to message ID 
3874905892f543e0be9984e6504644bb
  2017-05-30 17:40:27.530 29042 ERROR 
neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_ryuapp 
  2017-05-30 17:40:27.624 29042 INFO oslo_rootwrap.client [-] Stopping rootwrap 
daemon process with pid=29502

  From systemd side, following status is reported:

  [root@weirdo1 neutron]# systemctl status neutron-openvswitch-agent
  ● neutron-openvswitch-agent.service - OpenStack Neutron Open vSwitch Agent
 Loaded: loaded (/usr/lib/systemd/system/neutron-openvswitch-agent.service; 
enabled; vendor preset: disabled)
 Active: inactive (dead) since Tue 2017-05-30 17:40:27 UTC; 5min ago
   Main PID: 29042 (code=exited, status=0/SUCCESS)

  May 30 17:38:44 weirdo1 systemd[1]: Starting OpenStack Neutron Open vSwitch 
Agent...
  May 30 17:38:44 weirdo1 neutron-enable-bridge-firewall.sh[29032]: 
net.bridge.bridge-nf-call-arptables = 1
  May 30 17:38:44 weirdo1 neutron-enable-bridge-firewall.sh[29032]: 
net.bridge.bridge-nf-call-iptables = 1
  May 30 17:38:44 weirdo1 neutron-enable-bridge-firewall.sh[29032]: 
net.bridge.bridge-nf-call-ip6tables = 1
  May 30 17:38:44 weirdo1 systemd[1]: Started OpenStack Neutron Open vSwitch 
Agent.
  May 30 17:38:45 weirdo1 neutron-openvswitch-agent[29042]: Guru meditation now 
registers SIGUSR1 and SIGUSR2 by default for backward compatibility. SIGUSR1 
will no longer be reg...te reports.
  May 30 17:38:46 weirdo1 neutron-openvswitch-agent[29042]: Option 
"notification_driver" from group "DEFAULT" is deprecated. Use option "driver" 
from group "oslo_messaging_notifications".
  May 30 17:38:46 weirdo1 neutron-openvswitch-agent[29042]: Could not load 
neutron.openstack.common.notifier.rpc_notifier

  
  Note 

[Yahoo-eng-team] [Bug 1695056] [NEW] libvirt realtime feature mlockall: Cannot allocate memory

[Wei Zhu]

Public bug reported:

Trying to use this feature on newton,
https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/libvirt-real-time.html

Is low latency (realtime) kernel a requirement?
Anyway, I'm using 4.4.0-78-lowlatency now, following failed
(It worked if I manually copy out the portion before  into virsh xml 
with addition of )

  
20971520
  

warning: host doesn't support requested feature: CPUID.01H:EDX.ds [bit 21]
warning: host doesn't support requested feature: CPUID.01H:EDX.acpi [bit 22]
warning: host doesn't support requested feature: CPUID.01H:EDX.ht [bit 28]
warning: host doesn't support requested feature: CPUID.01H:EDX.tm [bit 29]
warning: host doesn't support requested feature: CPUID.01H:EDX.pbe [bit 31]
warning: host doesn't support requested feature: CPUID.01H:ECX.dtes64 [bit 2]
warning: host doesn't support requested feature: CPUID.01H:ECX.monitor [bit 3]
warning: host doesn't support requested feature: CPUID.01H:ECX.ds_cpl [bit 4]
warning: host doesn't support requested feature: CPUID.01H:ECX.smx [bit 6]
warning: host doesn't support requested feature: CPUID.01H:ECX.est [bit 7]
warning: host doesn't support requested feature: CPUID.01H:ECX.tm2 [bit 8]
warning: host doesn't support requested feature: CPUID.01H:ECX.xtpr [bit 14]
warning: host doesn't support requested feature: CPUID.01H:ECX.pdcm [bit 15]
warning: host doesn't support requested feature: CPUID.01H:ECX.dca [bit 18]
warning: host doesn't support requested feature: CPUID.01H:ECX.osxsave [bit 27]
warning: host doesn't support requested feature: CPUID.01H:EDX.ds [bit 21]
warning: host doesn't support requested feature: CPUID.01H:EDX.acpi [bit 22]
warning: host doesn't support requested feature: CPUID.01H:EDX.ht [bit 28]
warning: host doesn't support requested feature: CPUID.01H:EDX.tm [bit 29]
warning: host doesn't support requested feature: CPUID.01H:EDX.pbe [bit 31]
warning: host doesn't support requested feature: CPUID.01H:ECX.dtes64 [bit 2]
warning: host doesn't support requested feature: CPUID.01H:ECX.monitor [bit 3]
warning: host doesn't support requested feature: CPUID.01H:ECX.ds_cpl [bit 4]
warning: host doesn't support requested feature: CPUID.01H:ECX.smx [bit 6]
warning: host doesn't support requested feature: CPUID.01H:ECX.est [bit 7]
warning: host doesn't support requested feature: CPUID.01H:ECX.tm2 [bit 8]
warning: host doesn't support requested feature: CPUID.01H:ECX.xtpr [bit 14]
warning: host doesn't support requested feature: CPUID.01H:ECX.pdcm [bit 15]
warning: host doesn't support requested feature: CPUID.01H:ECX.dca [bit 18]
warning: host doesn't support requested feature: CPUID.01H:ECX.osxsave [bit 27]
mlockall: Cannot allocate memory
2017-06-01T14:47:43.122805Z qemu-system-x86_64: locking memory failed


 this is generated by openstack

  instance-005f
  de8a2358-f5cb-426a-ad2b-840f5f6ddfcf
  
http://openstack.org/xmlns/libvirt/nova/1.0;>
  
  vlns1_pfe
  2017-06-01 13:33:29
  
12288
4
0
0
12
  
  
admin
admin
  
  

  
  12582912
  12582912
  

  



  
  12
  
12288














  
  


  
  
/machine
  
  

  OpenStack Foundation
  OpenStack Nova
  14.0.4
  06b68615-3f83-4484-b195-0d68d5d67077
  de8a2358-f5cb-426a-ad2b-840f5f6ddfcf
  Virtual Machine

  
  
hvm


  
  


  
  



  

  
  



  
  destroy
  restart
  destroy
  
/usr/bin/kvm-spice

  
  

  
  



  
  
  
  
  


  
  

  
  



  
  
  
  
  
  


  
  


  


  
  


  
  
  

  
  
  
  
  


  
  
  

  
  
  
  
  


  
  
  

  
  

  
  
  


  
  
  

  
  

  
  
  


  
  
  
  


  
  


  
  
  
  


  




  


  
  
  


  
  
  

  
  
libvirt-de8a2358-f5cb-426a-ad2b-840f5f6ddfcf
libvirt-de8a2358-f5cb-426a-ad2b-840f5f6ddfcf
  



> this tested good with addition of memtune

  vlns-pfe
  9d5e4b00-ffac-4e9d-9d97-70ad3ac1de2c
  12582912
  12582912
  
20971520
  
  

  



  
  12
  
12288














  
  


  
  
/machine
  
  
hvm

  
  


  
  



  

  
  



  
  destroy
  restart
  destroy

** Affects: nova
 Importance: 

[Yahoo-eng-team] [Bug 1695052] [NEW] Pagination doesn't work on the Volume Snapshot tab

[Vladislav Kuzmin]

Public bug reported:

Steps to reproduce:
- Login as admin
- Go to admin settings
- Set "Item Per Page" to 2
- Create a volume if no volumes are present
- Create 3 snapshots of a volume via dropdown menu
- Go to "Volume" -> "Snapshots" tab

Expected result:
-Button "Next>>" is displayed

Actual result:
-"Next>>" isn't presented

** Affects: horizon
 Importance: Undecided
 Assignee: Vladislav Kuzmin (vkuzmin-u)
 Status: In Progress

** Changed in: horizon
 Assignee: (unassigned) => Vladislav Kuzmin (vkuzmin-u)

** Changed in: horizon
   Status: New => In Progress

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

Title:
  Pagination doesn't work on the Volume Snapshot tab

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  Steps to reproduce:
  - Login as admin
  - Go to admin settings
  - Set "Item Per Page" to 2
  - Create a volume if no volumes are present
  - Create 3 snapshots of a volume via dropdown menu
  - Go to "Volume" -> "Snapshots" tab

  Expected result:
  -Button "Next>>" is displayed

  Actual result:
  -"Next>>" isn't presented

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1695052/+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 1673411] Re: config-drive support is broken

[James Page]

** Changed in: cloud-archive/newton
   Status: Fix Committed => 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/1673411

Title:
  config-drive support is broken

Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive newton series:
  Fix Released
Status in Ubuntu Cloud Archive ocata series:
  Fix Released
Status in cloud-init:
  Fix Committed
Status in nova-lxd:
  Fix Released
Status in nova-lxd newton series:
  Fix Released
Status in nova-lxd ocata series:
  Fix Released
Status in nova-lxd trunk series:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in nova-lxd package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in nova-lxd source package in Xenial:
  Invalid
Status in cloud-init source package in Yakkety:
  Fix Released
Status in nova-lxd source package in Yakkety:
  Fix Released
Status in cloud-init source package in Zesty:
  Fix Released
Status in nova-lxd source package in Zesty:
  Fix Released

Bug description:
  === Begin cloud-init SRU Template ===
  [Impact]
  nova-lxd can provide data to instances in 2 ways:
   a.) metadata service
   b.) config drive

  The support for reading the config drive in cloud-init was never
  functional.  Nova-lxd has changed the way they're presenting the config
  drive to the guest.  Now they are doing so by populating a directory in
  the container /config-drive with the information.
  The change added to cloud-init was to extend support read config drive
  information from that directory.

  [Test Case]
  With a nova-lxd that contains the fix this can be fully tested
  by launching an instance with updated cloud-init and config drive
  attached.

  For cloud-init, the easiest way to demonstrate this is to
  create a lxc container and populate it with a '/config-drive'.

  lxc-proposed-snapshot is
    
https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bin/lxc-proposed-snapshot
  It publishes an image to lxd with proposed enabled and cloud-init upgraded.

  $ release=xenial
  $ ref=xenial-proposed
  $ name=$release-lp1673411
  $ lxc-proposed-snapshot --proposed --publish $release $ref
  $ lxc init $ref $name

  # lxc will create the 'NoCloud' seed, and the normal search
  # path looks there first, so remove it.

  $ lxc file pull $name/etc/cloud/cloud.cfg.d/90_dpkg.cfg - |
  sed 's/NoCloud, //' |
  lxc file push - $name/etc/cloud/cloud.cfg.d/90_dpkg.cfg

  ## populate a /config-drive with attached 'make-config-drive-dir'
  ## and push it to the container

  $ d=$(mktemp -d)
  $ make-config-drive-dir "$d" "$name"
  $ rm -Rf "$d"

  ## start it and look around
  $ lxc start $name
  $ sleep 10
  $ lxc exec $name cat /run/cloud-init/result.json
  {
   "v1": {
    "datasource": "DataSourceConfigDrive [net,ver=2][source=/config-drive]",
    "errors": []
   }
  }

  [Regression Potential]
  There is a potentiali false positive where a user had data in
  /config-drive and now that information is read as config drive data.

  That would require a directory tree like:
    /config-drive/openstack/2???-??-??/meta_data.json
  or
    /config-drive/openstack/latest/meta_data.json

  Which seems like a small likelyhood of non-contrived hit.

  [Other Info]
  Upstream commit:
   https://git.launchpad.net/cloud-init/commit/?id=443095f4d4b6fe

  === End cloud-init SRU Template ===

  After reviewing https://review.openstack.org/#/c/445579/ and doing
  some testing, it would appear that the config-drive support in the
  nova-lxd driver is not functional.

  cloud-init ignores the data presented in /var/lib/cloud/data and reads
  from the network accessible metadata-service.

  To test this effectively you have to have a fully offline instance
  (i.e. no metadata service access).

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1673411/+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 1694417] Re: dhcp_domain used when use_neutron is not set

[Stephen Finucane]

** Changed in: nova
   Status: Invalid => Incomplete

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

Title:
  dhcp_domain used when use_neutron is not set

Status in OpenStack Compute (nova):
  Incomplete

Bug description:
  Description
  ===

  While configuring nova with neutron and designate to provide DNS to
  instances, found that if use_neutron is not explicitly set to True in
  nova.conf it gets ignored and dhcp_domain setting is used (novalocal
  by default). I think designate does nothing here and the issue is
  between nova and neutron configuration because if nova option is not
  used, neutron default dns_domain would be openstacklocal.

  network_opts = [
  cfg.BoolOpt('use_neutron',
  default=True,
  deprecated_for_removal=True,
  deprecated_since='15.0.0',
  deprecated_reason="""
  nova-network is deprecated, as are any related configuration options.
  """,
  help="""
  Enable neutron as the backend for networking.
  Determine whether to use Neutron or Nova Network as the back end. Set to true
  to use neutron.
  """),

  From what I understand from [0] is if use_neutron is True(default
  value, see above), dhcp_domain option is not used and uses neutron
  settings.

  cfg.StrOpt("dhcp_domain",
  default="novalocal",
  deprecated_for_removal=True,
  deprecated_since='15.0.0',
  deprecated_reason="""
  nova-network is deprecated, as are any related configuration options.
  """,
  help="""
  This option allows you to specify the domain for the DHCP server.
  Possible values:
  * Any string that is a valid domain name.
  Related options:
  * ``use_neutron``
  """),

  Steps to reproduce
  ==

  No set use_neutron=True at nova.conf (is default)
  Set dns_domain = sample.openstack.org. in neutron.conf
  Boot an instance and check fqdn

  Expected results
  

  Instance have fqdn .sample.openstack.org

  Actual results
  ==

  Instance have fqdn .novalocal

  
  Environment
  ===

  CentOS
  Source code from master
  Deployed with kolla-ansible
  neutron + ml2 + ovs
  nova==16.0.0.0b2.dev511
  Latest commit: 
https://github.com/openstack/nova/commit/98b8e39ac5f7b3f2bb06ca415bbb806705461d74

  If manually set use_neutron=True in nova.conf instance gets domain
  based on dns_domain setting from neutron.

  [0] https://github.com/openstack/nova/blob/master/nova/conf/network.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1694417/+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 1694085] Re: dogpile.cache===0.6.3 breaks nova

[Matt Riedemann]

Looks like this was fixed:

https://github.com/openstack/nova/commit/eb22047abd80f218f009a1df169a3e4695558790

** Changed in: nova
   Status: New => Fix Released

** Changed in: nova
   Importance: Undecided => High

** Changed in: nova
 Assignee: (unassigned) => Davanum Srinivas (DIMS) (dims-v)

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

Title:
  dogpile.cache===0.6.3 breaks nova

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  see for more info: https://review.openstack.org/468184

  There are not that many commits, so it should be 'simple' to find out
  what changed.

  https://bitbucket.org/zzzeek/dogpile.cache/commits/tag/rel_0_6_3

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1694085/+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 1694417] Re: dhcp_domain used when use_neutron is not set

[Matt Riedemann]

use_neutron defaults to True, so you don't need to explicitly set it in
nova.conf to be using neutron. The dhcp_domain option is deprecated
since the Ocata release as it's only used for nova-network, which it
sounds like you're not using.

I think there is a misunderstanding here about how things are working
with the use_neutron config option, so I'm going to invalidate this, but
please re-open and explain if I'm missing something.

** Changed in: nova
   Status: New => Invalid

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

Title:
  dhcp_domain used when use_neutron is not set

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  Description
  ===

  While configuring nova with neutron and designate to provide DNS to
  instances, found that if use_neutron is not explicitly set to True in
  nova.conf it gets ignored and dhcp_domain setting is used (novalocal
  by default). I think designate does nothing here and the issue is
  between nova and neutron configuration because if nova option is not
  used, neutron default dns_domain would be openstacklocal.

  network_opts = [
  cfg.BoolOpt('use_neutron',
  default=True,
  deprecated_for_removal=True,
  deprecated_since='15.0.0',
  deprecated_reason="""
  nova-network is deprecated, as are any related configuration options.
  """,
  help="""
  Enable neutron as the backend for networking.
  Determine whether to use Neutron or Nova Network as the back end. Set to true
  to use neutron.
  """),

  From what I understand from [0] is if use_neutron is True(default
  value, see above), dhcp_domain option is not used and uses neutron
  settings.

  cfg.StrOpt("dhcp_domain",
  default="novalocal",
  deprecated_for_removal=True,
  deprecated_since='15.0.0',
  deprecated_reason="""
  nova-network is deprecated, as are any related configuration options.
  """,
  help="""
  This option allows you to specify the domain for the DHCP server.
  Possible values:
  * Any string that is a valid domain name.
  Related options:
  * ``use_neutron``
  """),

  Steps to reproduce
  ==

  No set use_neutron=True at nova.conf (is default)
  Set dns_domain = sample.openstack.org. in neutron.conf
  Boot an instance and check fqdn

  Expected results
  

  Instance have fqdn .sample.openstack.org

  Actual results
  ==

  Instance have fqdn .novalocal

  
  Environment
  ===

  CentOS
  Source code from master
  Deployed with kolla-ansible
  neutron + ml2 + ovs
  nova==16.0.0.0b2.dev511
  Latest commit: 
https://github.com/openstack/nova/commit/98b8e39ac5f7b3f2bb06ca415bbb806705461d74

  If manually set use_neutron=True in nova.conf instance gets domain
  based on dns_domain setting from neutron.

  [0] https://github.com/openstack/nova/blob/master/nova/conf/network.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1694417/+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 1694441] Re: Add `img_hide_hypervisor_id` image property

[Matt Riedemann]

https://docs.openstack.org/cli-reference/glance-property-keys.html
should be updated with the new image metadata property.

** Also affects: openstack-manuals
   Importance: Undecided
   Status: New

** Changed in: nova
   Status: New => Invalid

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

Title:
  Add `img_hide_hypervisor_id` image property

Status in OpenStack Compute (nova):
  Invalid
Status in openstack-manuals:
  New

Bug description:
  https://review.openstack.org/459753
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/nova" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit c7c08e590eb0ea2452a1a1d925297ba43fa609b0
  Author: Daniel Pawlik 
  Date:   Tue Apr 25 15:12:29 2017 +

  Add `img_hide_hypervisor_id` image property
  
  Image hide_hypervisor_id property helps libvirt set an xml instance file
  property, which will hide on guest host KVM hypervisor signature
  ("KVMKVMKVM\0\0\0").
  According to the commit message in QEMU repository [1]:
  
  "The latest Nvidia driver (337.88) specifically checks
  for KVM as the hypervisor and reports Code 43 for the
  driver  in a Windows guest when found.  Removing or
  changing the KVM signature is sufficient for the driver
  to load and work."
  
  DocImpact: New feature ``img_hide_hypervisor_id`` image property should be
  added in the glance-property-keys page of the cli-reference docs [2].
  
  [1]: http://git.qemu.org/?p=qemu.git;a=commitdiff;h=f522d2a
  [2]: https://docs.openstack.org/cli-reference/glance-property-keys.html
  
  Implements: blueprint add-kvm-hidden-feature
  
  Co-Authored-By: Adam Kijak 
  
  Change-Id: Ie8227fececa40e502aaa39d77de2a1cd0cd72682

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1694441/+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 1694959] Re: Openstack Instance snapshots returns 0 bytes

[Matt Riedemann]

Going to need more details about this. What is the recreate scenario?
What type of instance is it - is it volume-backed or using nova local
disk (ephemeral)?

Are there errors in the nova-compute logs during the snapshot? Are there
errors in the Glance logs? Is a snapshot image created in glance and if
so, what are the details about that (image show output)? Is the image
uploading?

Which virt driver are you using? Which glance image backend are you
using?

** Changed in: nova
   Status: New => Invalid

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

Title:
  Openstack Instance snapshots returns 0 bytes

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  I am trying to take a snapshot of fine running instance in
  openstack(mitaka) release. I get "Snapshot created successfully"
  message when i create snapshot but snapshot size returns to 0 bytes.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1694959/+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 1694965] [NEW] port security rules only applied at port binding/creation time

[Eduardo Gonzalez]

Public bug reported:

Quick Overview
==

OpenStack is already running with networks and instances created.
Port security extension is not enabled.
When enabling port_security, instances in old networks not get DHCP.
Instances in new networks work fine.


Bug Description
===

As suggestion in bug https://bugs.launchpad.net/neutron/+bug/1694420.
Decided to verify how port_security behaves regarding upgrade or
reconfiguration of existing environments without port_security to
port_security as this is a blocker to enable it by default.

During my verification/tests with source code from master branch (Pike
ATM) found that instances not get DHCP in old networks while instances
in new networks after enabling port_security worked fine.

In a IRC discussion, one suggestion was to disable and re-enable DHCP in
old subnets. After that DHCP worked fine and fixes the issue.


How to reproduce


- Deploy OpenStack without port_security
- Create 1 network, subnet and attach to a router
-  ->  Not really needed.
- Enable port_security extension in ml2_conf.ini
- Restart all neutron services.
- Create 1 instance in the old network.
- Instance not getting DHCP lease.
- Create 1 new network, subnet, attach to router.
- Spawn new instance in new network
- Instance gets DHCP lease.

Expected behaviour
=

Instance in old network get DHCP lease.

Actual Results
==

Instance in old network not get DHCP lease.


Environment configuration
=

- CentOS 7.
- Neutron master source code Latest commit: 
https://github.com/openstack/neutron/commit/0f218aae7ed666f3f13ac0560a57f1eeed45cee7
- OpenStack deployed with Kolla, all defaults.


Logs


Attached logs with:
 - network/ports information
 - iptables-save in qdhcp


Let me know if need something else.
I'm available in kolla's IRC channel as egonzalez

Regards

** Affects: neutron
 Importance: Undecided
 Status: New

** Attachment added: "port_security_dhcp_issue.txt"
   
https://bugs.launchpad.net/bugs/1694965/+attachment/4887254/+files/port_security_dhcp_issue.txt

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

Title:
  port security rules only applied at port binding/creation time

Status in neutron:
  New

Bug description:
  Quick Overview
  ==

  OpenStack is already running with networks and instances created.
  Port security extension is not enabled.
  When enabling port_security, instances in old networks not get DHCP.
  Instances in new networks work fine.

  
  Bug Description
  ===

  As suggestion in bug https://bugs.launchpad.net/neutron/+bug/1694420.
  Decided to verify how port_security behaves regarding upgrade or
  reconfiguration of existing environments without port_security to
  port_security as this is a blocker to enable it by default.

  During my verification/tests with source code from master branch (Pike
  ATM) found that instances not get DHCP in old networks while instances
  in new networks after enabling port_security worked fine.

  In a IRC discussion, one suggestion was to disable and re-enable DHCP
  in old subnets. After that DHCP worked fine and fixes the issue.

  
  How to reproduce
  

  - Deploy OpenStack without port_security
  - Create 1 network, subnet and attach to a router
  -  ->  Not really needed.
  - Enable port_security extension in ml2_conf.ini
  - Restart all neutron services.
  - Create 1 instance in the old network.
  - Instance not getting DHCP lease.
  - Create 1 new network, subnet, attach to router.
  - Spawn new instance in new network
  - Instance gets DHCP lease.

  Expected behaviour
  =

  Instance in old network get DHCP lease.

  Actual Results
  ==

  Instance in old network not get DHCP lease.

  
  Environment configuration
  =

  - CentOS 7.
  - Neutron master source code Latest commit: 
https://github.com/openstack/neutron/commit/0f218aae7ed666f3f13ac0560a57f1eeed45cee7
  - OpenStack deployed with Kolla, all defaults.

  
  Logs
  

  Attached logs with:
   - network/ports information
   - iptables-save in qdhcp

  
  Let me know if need something else.
  I'm available in kolla's IRC channel as egonzalez

  Regards

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1694965/+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 1694913] [NEW] revert resize and resize again will fail when use rbd

[赵明俊]

Public bug reported:

Description
===
I resize an instance and revert it, it works correctly, but when I resize this 
instance again, the instance set to error, and I check the compute log like 
below.
I use the rbd backend, I think the reason should be like this, If instance use 
shared storage, revert resize will not delete the instance dir and files on 
destination host, this files owner is root, if resize the instance again and 
migrate to the same destination host, the IOError exception will be thrown.

Logs
==
Traceback (most recent call last):
   File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 3950, 
in finish_resize
 disk_info, image_meta)
   File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 3915, 
in _finish_resize
 old_instance_type)
   File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in 
__exit__
 self.force_reraise()
   File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
 six.reraise(self.type_, self.value, self.tb)
   File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 3910, 
in _finish_resize
 block_device_info, power_on)
   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 
7223, in finish_migration
 self._ensure_console_log_for_instance(instance)
   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 
2867, in _ensure_console_log_for_instance
 libvirt_utils.file_open(console_file, 'a').close()
   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/utils.py", line 
313, in file_open
 return open(*args, **kwargs)
 IOError: [Errno 13] Permission denied: 
'/var/lib/nova/instances/c1c4847d-0470-4fae-9060-6511a8e2c056/console.log'

** Affects: nova
 Importance: Undecided
 Status: New

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

Title:
  revert resize and resize again will fail when use rbd

Status in OpenStack Compute (nova):
  New

Bug description:
  Description
  ===
  I resize an instance and revert it, it works correctly, but when I resize 
this instance again, the instance set to error, and I check the compute log 
like below.
  I use the rbd backend, I think the reason should be like this, If instance 
use shared storage, revert resize will not delete the instance dir and files on 
destination host, this files owner is root, if resize the instance again and 
migrate to the same destination host, the IOError exception will be thrown.

  Logs
  ==
  Traceback (most recent call last):
 File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 
3950, in finish_resize
   disk_info, image_meta)
 File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 
3915, in _finish_resize
   old_instance_type)
 File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, 
in __exit__
   self.force_reraise()
 File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, 
in force_reraise
   six.reraise(self.type_, self.value, self.tb)
 File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 
3910, in _finish_resize
   block_device_info, power_on)
 File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 
7223, in finish_migration
   self._ensure_console_log_for_instance(instance)
 File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 
2867, in _ensure_console_log_for_instance
   libvirt_utils.file_open(console_file, 'a').close()
 File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/utils.py", line 
313, in file_open
   return open(*args, **kwargs)
   IOError: [Errno 13] Permission denied: 
'/var/lib/nova/instances/c1c4847d-0470-4fae-9060-6511a8e2c056/console.log'

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1694913/+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 1692491] Re: nova shows wrong RAM usage

[jichenjc]

*** This bug is a duplicate of bug 1681989 ***
https://bugs.launchpad.net/bugs/1681989

** This bug has been marked a duplicate of bug 1681989
   the deletion of the instance does not release the memory quota for vram

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

Title:
  nova shows wrong RAM usage

Status in OpenStack Compute (nova):
  New

Bug description:
  If flavor has hw_video:ram_max_mb value, nova will add this value to
  the project usage[1]. But when we delete this server, it seems we
  don't cover this case. So we will always get wrong ram usage.

  For example, we create a server with flavor f, whose ram is 1024 and
  hw_video:ram_max_mb is 64, then we will compute quota usage as 1024 +
  64, but when we delete this server, we only release 1024, rather than
  1024 + 64. As a result, the usage may incremente constantly， until
  over max limit.

  [1]
  https://github.com/openstack/nova/blob/master/nova/compute/api.py#L352-L353

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