[Yahoo-eng-team] [Bug 1754978] Re: neutron fails to work with pecan-1.3.2

[OpenStack Infra]

Reviewed:  https://review.openstack.org/561825
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=0063aa33c65def9245730754ab2dc2f1b09b76e0
Submitter: Zuul
Branch:master

commit 0063aa33c65def9245730754ab2dc2f1b09b76e0
Author: Isaku Yamahata 
Date:   Mon Apr 16 23:05:53 2018 -0700

pecan.jsonify v1.3 adjustment

From pecan v1.3, pecan.jsonify uses json.Encoder unconditionally so that
jsonifying mock fails.
Pecan v1.2 uses simplejson.Encoder as encoder which accidentally encodes
MagicMock as {} due to check of '_asdict' attributes.
Since pecan.jsonify uses __json__ magic method when it's defined,
add __json__ method to mocks to return {} as json encode.

Closes-bug: #1754978
Change-Id: Iac955a7de2a1b66b5b56a73f5cc8a4e75150f82e


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

Title:
  neutron fails to work with pecan-1.3.2

Status in neutron:
  Fix Released
Status in OpenStack Global Requirements:
  New

Bug description:
  Requirements would like to update this package but can't (it is
  currently at version 1.2).

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1754978/+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 1765008] Re: Tempest API tests failing for stable/queens branch

[yatin]

The test is failing in tripleo as well:- 
master:- 
https://logs.rdoproject.org/openstack-periodic/periodic-tripleo-ci-centos-7-ovb-1ctlr_1comp-featureset020-master/63a5b7a/undercloud/home/jenkins/tempest/tempest.html.gz
Queens:- 
https://logs.rdoproject.org/openstack-periodic/periodic-tripleo-ci-centos-7-ovb-1ctlr_1comp-featureset020-queens/a1bc8c7/undercloud/home/jenkins/tempest/tempest.html.gz

https://review.openstack.org/#/c/562324/ should fix the issue.

** Also affects: tripleo
   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/1765008

Title:
  Tempest API tests failing for stable/queens branch

Status in neutron:
  In Progress
Status in tripleo:
  New

Bug description:
  neutron-tempest-plugin repo is branchless so same tests are running for 
master and stable/queens neutron code.
  Recently there was new test merged: https://review.openstack.org/#/c/558609/
  and this cause problem like: 
http://logs.openstack.org/47/562147/1/check/neutron-tempest-plugin-api/5596592/logs/testr_results.html.gz
 for stable branches

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1765008/+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 1733395] Re: subnetallocation extension not doc'd in api-ref

[OpenStack Infra]

Reviewed:  https://review.openstack.org/559735
Committed: 
https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=032f3a4cb5a419c54e9dedcd97528224f341b20a
Submitter: Zuul
Branch:master

commit 032f3a4cb5a419c54e9dedcd97528224f341b20a
Author: Michal Kelner Mishali 
Date:   Mon Apr 9 16:17:43 2018 +0300

Documenting subnet_allocation extension

Closes-Bug: #1733395

Change-Id: I666ad54e3fa179c19c4b9a255d088bca0651c66d
Signed-off-by: Michal Kelner Mishali 


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

Title:
  subnetallocation extension not doc'd in api-ref

Status in neutron:
  Fix Released

Bug description:
  The subnetallocation extension appears to be a shim extension that
  doesn't add any attrs/resources. However we should still document this
  extension in a subsection to describe what it does.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1733395/+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 1517839] Re: Make CONF.set_override with parameter enforce_type=True by default

[Jeffrey Zhang]

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: "
  Only still supported release names are valid (OCATA, PIKE, QUEENS, ROCKY, 
ROCKY).
  Valid example: CONFIRMED FOR: OCATA


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

** Changed in: kolla
   Status: Confirmed => Expired

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

Title:
  Make CONF.set_override with parameter enforce_type=True by default

Status in Cinder:
  In Progress
Status in cloudkitty:
  Fix Released
Status in Designate:
  Fix Released
Status in OpenStack Backup/Restore and DR (Freezer):
  Fix Committed
Status in Glance:
  Invalid
Status in OpenStack Heat:
  Fix Released
Status in Ironic:
  Fix Released
Status in Karbor:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in kolla:
  Expired
Status in Magnum:
  Fix Released
Status in Manila:
  Fix Released
Status in Murano:
  Fix Released
Status in neutron:
  Won't Fix
Status in OpenStack Compute (nova):
  Fix Released
Status in octavia:
  New
Status in oslo.config:
  Fix Released
Status in oslo.messaging:
  Fix Released
Status in Quark: Money Reinvented:
  New
Status in Rally:
  Fix Released
Status in senlin:
  Fix Released
Status in tacker:
  Fix Released
Status in tempest:
  Fix Released
Status in watcher:
  Fix Released

Bug description:
  1. Problems :
     oslo_config provides method CONF.set_override[1] , developers usually use 
it to change config option's value in tests. That's convenient .
     By default  parameter enforce_type=False,  it doesn't check any type or 
value of override. If set enforce_type=True , will check parameter
     override's type and value.  In production code(running time code),  
oslo_config  always checks  config option's value.
     In short, we test and run code in different ways. so there's  gap:  config 
option with wrong type or invalid value can pass tests when
     parameter enforce_type = False in consuming projects.  that means some 
invalid or wrong tests are in our code base.

     [1]
  https://github.com/openstack/oslo.config/blob/master/oslo_config/cfg.py#L2173

  2. Proposal
     1) Fix violations when enforce_type=True in each project.

    2) Make method CONF.set_override with  enforce_type=True by default
  in oslo_config

   You can find more details and comments  in
  https://etherpad.openstack.org/p/enforce_type_true_by_default

  3. How to find violations in your projects.

     1. Run tox -e py27

     2. then modify oslo.config with enforce_type=True
    cd .tox/py27/lib64/python2.7/site-packages/oslo_config
    edit cfg.py with enforce_type=True

  -def set_override(self, name, override, group=None, enforce_type=False):
  +def set_override(self, name, override, group=None, enforce_type=True):

    3. Run tox -e py27 again, you will find violations.

  
  The current state is that oslo.config make enforce_type as True by default 
and deprecate this parameter, will remove it in the future, the current work
  is that remove usage of enforce_type in consuming projects. We can list the
  usage of it in 
http://codesearch.openstack.org/?q=enforce_type=nope==

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1517839/+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 1763824] Re: JSON schema validator.nullable doesn't work with ENUMs

[Morgan Fainberg]

This also impacts ocata.

** Also affects: keystone/ocata
   Importance: Undecided
   Status: New

** Changed in: keystone/ocata
   Status: New => Won't Fix

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

Title:
  JSON schema validator.nullable doesn't work with ENUMs

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) ocata series:
  Won't Fix
Status in OpenStack Identity (keystone) pike series:
  In Progress
Status in OpenStack Identity (keystone) queens series:
  In Progress
Status in OpenStack Identity (keystone) rocky series:
  Fix Released

Bug description:
  JSON Schema validator.nullable only sets null in the types list. This
  works except when an enum is set (such as the case with boolean) [0].

  The fix is to make validator.nullable() smart enough to add to the
  ENUM if ENUM is set as well as type.

  [0]
  
https://github.com/openstack/keystone/blob/56237b709ef901fabfd9e8ba744bbcc4cebf8b9b/keystone/common/validation/__init__.py#L33-L43

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1763824/+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 1765214] [NEW] Multiple success messages sent to Azure Fabric if reboot occurs during pre-provisioning

[Joshua Chan]

Public bug reported:

In Azure's preprovisioning feature. During the poll IMDS phase, if an
unexpected reboot happens and a report ready has been already been sent
to Azure Fabric prior, we are sending another report ready after the
reboot. This is not the behavior that Azure Fabric expected.

** Affects: cloud-init
 Importance: Undecided
 Assignee: Joshua Chan (jocha)
 Status: New

** Changed in: cloud-init
 Assignee: (unassigned) => Joshua Chan (jocha)

** Merge proposal linked:
   https://code.launchpad.net/~jocha/cloud-init/+git/cloud-init/+merge/343563

** Summary changed:

- unexpectedly sent report ready to Azure Fabric
+ Multiple success messages sent to Azure Fabric if reboot occurs during 
pre-provisioning

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

Title:
  Multiple success messages sent to Azure Fabric if reboot occurs during
  pre-provisioning

Status in cloud-init:
  New

Bug description:
  In Azure's preprovisioning feature. During the poll IMDS phase, if an
  unexpected reboot happens and a report ready has been already been
  sent to Azure Fabric prior, we are sending another report ready after
  the reboot. This is not the behavior that Azure Fabric expected.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1765214/+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 1765208] [NEW] IPtables firewall code sometimes tries to remove non-existent rules

[Brian Haley]

Public bug reported:

I've seen errors like this in some of the OVS agent logs recently:

WARNING neutron.agent.linux.iptables_manager [None 
req-61600016-733c-44f2-a96c-d9f62b7e049c None None] Tried to remove rule that 
was not there: 'PREROUTING' u'-m physdev --physdev-in brq0b54770c-65 -m comment 
--comment "Set zone for 43bcf43-ba" -j CT --zone 4101' True False
(there's usually 5 more similar lines)

Looking into it, the line right before we had allocated a conntrack
zone:

DEBUG neutron.agent.linux.ip_conntrack [None req-61600016-733c-44f2
-a96c-d9f62b7e049c None None] Assigned CT zone 4101 to device
0b54770c-65

So we allocate a zone and immediately try and remove some iptables rules
associated with it, but they won't exist since the zone was just
allocated.  Instead, we should return early if there was no zone - the
caller in question is _remove_conntrack_jump(), which is being called
when we're removing a set of chains./lin

** Affects: neutron
 Importance: Undecided
 Assignee: Brian Haley (brian-haley)
 Status: New


** Tags: sg-fw

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

Title:
  IPtables firewall code sometimes tries to remove non-existent rules

Status in neutron:
  New

Bug description:
  I've seen errors like this in some of the OVS agent logs recently:

  WARNING neutron.agent.linux.iptables_manager [None 
req-61600016-733c-44f2-a96c-d9f62b7e049c None None] Tried to remove rule that 
was not there: 'PREROUTING' u'-m physdev --physdev-in brq0b54770c-65 -m comment 
--comment "Set zone for 43bcf43-ba" -j CT --zone 4101' True False
  (there's usually 5 more similar lines)

  Looking into it, the line right before we had allocated a conntrack
  zone:

  DEBUG neutron.agent.linux.ip_conntrack [None req-61600016-733c-44f2
  -a96c-d9f62b7e049c None None] Assigned CT zone 4101 to device
  0b54770c-65

  So we allocate a zone and immediately try and remove some iptables
  rules associated with it, but they won't exist since the zone was just
  allocated.  Instead, we should return early if there was no zone - the
  caller in question is _remove_conntrack_jump(), which is being called
  when we're removing a set of chains./lin

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1765208/+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 1765204] [NEW] Listing resource providers in placement with a postgresql backend gets a group by error

[Chris Dent]

Public bug reported:

When listing resource providers in placement with a postgresql database,
this error recently started showing up:

column "root_rp.uuid" must appear in the GROUP BY clause or be used
in an aggregate function

And then once you fix that it says the same for parent_rp.uuid.

It's not clear when this problem came on the scene, since we don't test
regularly with postgresql, but I do use it in my experiments with
placement in a container [1] and it wasn't there as of April 6th, and
probably a bit later.

Work is in progress to fix this as well as turn on an experimental job
for checking with postgres every now and again.


[1] https://hub.docker.com/r/cdent/placedock/

** Affects: nova
 Importance: Low
 Assignee: Chris Dent (cdent)
 Status: In Progress


** Tags: placement

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

Title:
  Listing resource providers in placement with a postgresql backend gets
  a group by error

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  When listing resource providers in placement with a postgresql
  database, this error recently started showing up:

  column "root_rp.uuid" must appear in the GROUP BY clause or be
  used in an aggregate function

  And then once you fix that it says the same for parent_rp.uuid.

  It's not clear when this problem came on the scene, since we don't
  test regularly with postgresql, but I do use it in my experiments with
  placement in a container [1] and it wasn't there as of April 6th, and
  probably a bit later.

  Work is in progress to fix this as well as turn on an experimental job
  for checking with postgres every now and again.

  
  [1] https://hub.docker.com/r/cdent/placedock/

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1765204/+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 1763824] Re: JSON schema validator.nullable doesn't work with ENUMs

[OpenStack Infra]

Reviewed:  https://review.openstack.org/561348
Committed: 
https://git.openstack.org/cgit/openstack/keystone/commit/?id=78adf4b40fb88e371101ed065ac1d15063d8d86e
Submitter: Zuul
Branch:master

commit 78adf4b40fb88e371101ed065ac1d15063d8d86e
Author: Morgan Fainberg 
Date:   Fri Apr 13 13:34:31 2018 -0700

Fix json schema nullable to add None to ENUM

The JSON Schema validation implementation of nullable(), which makes
values possible to be null was not adding None to the enum if it exists.
This causes validation to fail on ``None`` especially in the case of
keystone's boolean parameter_type implementation. ``nullable()`` now
adds ``None`` to the enum if the enum exists.

Closes-Bug: #1763824
Change-Id: I176fa90df63049661413c445554dba9b7d87272a


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

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

Title:
  JSON schema validator.nullable doesn't work with ENUMs

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) pike series:
  In Progress
Status in OpenStack Identity (keystone) queens series:
  In Progress
Status in OpenStack Identity (keystone) rocky series:
  Fix Released

Bug description:
  JSON Schema validator.nullable only sets null in the types list. This
  works except when an enum is set (such as the case with boolean) [0].

  The fix is to make validator.nullable() smart enough to add to the
  ENUM if ENUM is set as well as type.

  [0]
  
https://github.com/openstack/keystone/blob/56237b709ef901fabfd9e8ba744bbcc4cebf8b9b/keystone/common/validation/__init__.py#L33-L43

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1763824/+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 1687074] Re: Sometimes ovsdb fails with "tcp:127.0.0.1:6640: error parsing stream"

[Terry Wilson]

I guess incomplete is still "open", so invalid it is.

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

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

Title:
  Sometimes ovsdb fails with "tcp:127.0.0.1:6640: error parsing stream"

Status in neutron:
  Fix Released
Status in ovsdbapp:
  Invalid

Bug description:
  Example (Ocata): http://logs.openstack.org/67/460867/1/check/gate-
  neutron-dsvm-functional-ubuntu-xenial/382d800/logs/dsvm-functional-
  
logs/neutron.tests.functional.agent.ovsdb.test_impl_idl.ImplIdlTestCase.test_post_commit_vswitchd_completed_no_failures.txt.gz

  2017-04-28 07:59:01.430 11929 WARNING neutron.agent.ovsdb.native.vlog [-] 
tcp:127.0.0.1:6640: error parsing stream: line 0, column 1, byte 1: syntax 
error at beginning of input
  2017-04-28 07:59:01.431 11929 DEBUG neutron.agent.ovsdb.impl_idl [-] Running 
txn command(idx=0): AddBridgeCommand(name=test-brc6de03bf, may_exist=True, 
datapath_type=None) do_commit neutron/agent/ovsdb/impl_idl.py:100
  2017-04-28 07:59:01.433 11929 DEBUG neutron.agent.ovsdb.impl_idl [-] OVSDB 
transaction returned TRY_AGAIN, retrying do_commit 
neutron/agent/ovsdb/impl_idl.py:111
  2017-04-28 07:59:01.433 11929 WARNING neutron.agent.ovsdb.native.vlog [-] 
tcp:127.0.0.1:6640: connection dropped (Protocol error)

  If we look at logstash here:
  
http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22tcp%3A127.0.0.1%3A6640%3A%20error%20parsing%20stream%5C%22

  We see some interesting data points, sometimes it actually logs what's
  in the buffer, and I see instances of:

  2017-04-27 19:02:51.755
  
[neutron.tests.functional.tests.common.exclusive_resources.test_port.TestExclusivePort.test_port]
  3300 WARNING ovsdbapp.backend.ovs_idl.vlog [-] tcp:127.0.0.1:6640:
  error parsing stream: line 0, column 1355, byte 1355: invalid keyword
  'id'

  2017-04-27 14:22:02.294
  
[neutron.tests.functional.agent.linux.test_ovsdb_monitor.TestSimpleInterfaceMonitor.test_get_events_native_]
  3433 WARNING ovsdbapp.backend.ovs_idl.vlog [-] tcp:127.0.0.1:6640:
  error parsing stream: line 0, column 3, byte 3: invalid keyword 'new'

  2017-04-27 04:46:17.667
  
[neutron.tests.functional.agent.test_dhcp_agent.DHCPAgentOVSTestCase.test_bad_address_allocation]
  4136 WARNING ovsdbapp.backend.ovs_idl.vlog [-] tcp:127.0.0.1:6640:
  error parsing stream: line 0, column 3, byte 3: invalid keyword 'ace'

  2017-04-26 18:04:59.110
  
[neutron.tests.functional.agent.linux.test_linuxbridge_arp_protect.LinuxBridgeARPSpoofTestCase.test_arp_correct_protection_allowed_address_pairs]
  3477 WARNING ovsdbapp.backend.ovs_idl.vlog [-] tcp:127.0.0.1:6640:
  error parsing stream: line 0, column 3, byte 3: invalid keyword 'err'

  2017-04-25 19:00:01.452
  
[neutron.tests.functional.agent.test_dhcp_agent.DHCPAgentOVSTestCase.test_agent_mtu_set_on_interface_driver]
  4251 WARNING ovsdbapp.backend.ovs_idl.vlog [-] tcp:127.0.0.1:6640:
  error parsing stream: line 0, column 3, byte 3: invalid keyword 'set'

  2017-04-25 16:34:11.355
  
[neutron.tests.functional.agent.linux.test_linuxbridge_arp_protect.LinuxBridgeARPSpoofTestCase.test_arp_fails_incorrect_mac_protection]
  3332 WARNING ovsdbapp.backend.ovs_idl.vlog [-] tcp:127.0.0.1:6640:
  error parsing stream: line 0, column 5, byte 5: invalid keyword
  'tatus'

  2017-04-25 03:28:25.858
  
[neutron.tests.functional.agent.ovsdb.test_impl_idl.ImplIdlTestCase.test_post_commit_vswitchd_completed_no_failures]
  4112 WARNING ovsdbapp.backend.ovs_idl.vlog [-] tcp:127.0.0.1:6640:
  error parsing stream: line 0, column 3, byte 3: invalid keyword 'set'

  2017-04-24 21:59:39.094
  
[neutron.tests.functional.agent.linux.test_linuxbridge_arp_protect.LinuxBridgeARPSpoofTestCase.test_arp_protection_port_security_disabled]
  3682 WARNING ovsdbapp.backend.ovs_idl.vlog [-] tcp:127.0.0.1:6640:
  error parsing stream: line 0, column 5, byte 5: invalid keyword
  'rsion'

  Terry says it doesn't resemble the protocol, but some random crap,
  potentially from some random place in memory (SCARY!)

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1687074/+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 1765193] [NEW] Unified limits API doesn't expose model information

[Lance Bragstad]

Public bug reported:

One of the primary advantages of the unified limit concept in keystone
was that keystone would expose the limit model via the API so that other
services could reason about it during enforcement with oslo.limit.

This was documented in the Queens specification [0], but the
implementation never included it. This wasn't a real big deal because
the only enforcement model supported currently is flat. We should add
this API before we mark the unified limit API as stable or before we add
any more enforcement models to keystone.

[0] http://specs.openstack.org/openstack/keystone-
specs/specs/keystone/queens/limits-api.html#flat-hierarchy-enforcement

** Affects: keystone
 Importance: Medium
 Status: Triaged


** Tags: limits

** Changed in: keystone
   Importance: Undecided => Medium

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

** Changed in: keystone
   Status: Confirmed => Triaged

** Tags added: limits

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

Title:
  Unified limits API doesn't expose model information

Status in OpenStack Identity (keystone):
  Triaged

Bug description:
  One of the primary advantages of the unified limit concept in keystone
  was that keystone would expose the limit model via the API so that
  other services could reason about it during enforcement with
  oslo.limit.

  This was documented in the Queens specification [0], but the
  implementation never included it. This wasn't a real big deal because
  the only enforcement model supported currently is flat. We should add
  this API before we mark the unified limit API as stable or before we
  add any more enforcement models to keystone.

  [0] http://specs.openstack.org/openstack/keystone-
  specs/specs/keystone/queens/limits-api.html#flat-hierarchy-enforcement

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1765193/+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 1764489] Re: Preallocated disks are deducted twice from disk_available_least when using preallocated_images = space

[Matt Riedemann]

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

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

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

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

** Changed in: nova/ocata
   Status: New => In Progress

** Changed in: nova/pike
   Status: New => In Progress

** Changed in: nova/queens
   Status: New => In Progress

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

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

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

** Changed in: nova/ocata
 Assignee: (unassigned) => Lee Yarwood (lyarwood)

** Changed in: nova/pike
 Assignee: (unassigned) => Lee Yarwood (lyarwood)

** Changed in: nova/queens
 Assignee: (unassigned) => Lee Yarwood (lyarwood)

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

Title:
  Preallocated disks are deducted twice from disk_available_least when
  using preallocated_images = space

Status in OpenStack Compute (nova):
  Fix Released
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:
  Description
  ===
  When using preallocated file based disks (preallocate_images = space) with 
the Libvirt virt driver the reported allocation for each disk appears doubled, 
leaving disk_available_least under reporting the amount of available resources 
on a compute node.

  Originally reported and debugged by mschuppert and mdbooth:
  https://bugzilla.redhat.com/show_bug.cgi?id=1554265

  Steps to reproduce
  ==

  $ crudini --get /etc/nova/nova-cpu.conf DEFAULT preallocate_images
  space

  $ nova hypervisor-show eb515aa2-b79e-4f38-a6ea-d493a6e0657f
  +---+--+
  | Property  | Value|
  +---+--+
  [..]
  | disk_available_least  | 43   |
  | free_disk_gb  | 48   |
  [..]
  | local_gb  | 48   |
  | local_gb_used | 0|
  [..]
  +---+--+

  $ nova flavor-show 2
  ++--+
  | Property   | Value|
  ++--+
  [..]
  | disk   | 20   |
  [..]
  ++--+

  $ nova boot --image cirros-0.3.5-x86_64-disk --flavor 2 test
  [..]
  $ nova hypervisor-show eb515aa2-b79e-4f38-a6ea-d493a6e0657f
  +---+--+
  | Property  | Value|
  +---+--+
  [..]
  | disk_available_least  | 3|
  | free_disk_gb  | 28   |
  [..]
  | local_gb  | 48   |
  | local_gb_used | 20   |
  [..]
  +---+--+

  Expected result
  ===
  The allocation for each preallocated disk is reported correctly and removed 
from disk_available_least.

  Actual result
  =
  The allocation for each preallocated disk appears doubled and removed from 
disk_available_least.

  Environment
  ===
  1. Exact version of OpenStack you are running. See the following
list for all releases: http://docs.openstack.org/releases/

 fb0b785169e5e422b06e82f2eb58e68f6d2008b3

  2. Which hypervisor did you use?
 (For example: Libvirt + KVM, Libvirt + XEN, Hyper-V, PowerKVM, ...)
 What's the version of that?

 Libvirt + KVM

  2. Which storage type did you use?
 (For example: Ceph, LVM, GPFS, ...)
 What's the version of that?

 file / qcow2

  3. Which networking type did you use?
 (For example: nova-network, Neutron with OpenVSwitch, ...)

 N/A

  Logs & Configs
  ==
  See above.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1764489/+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 1685678] Re: swap volume operation may leak credentials into debug logs

[Matt Riedemann]

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

** This bug has been marked a duplicate of bug 1761054
   nova log expose password when swapvolume

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

Title:
  swap volume operation may leak credentials into debug logs

Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  The swap volume code in the compute service logs old and new volume
  connection_info dicts to debug here:

  
https://github.com/openstack/nova/blob/1ad41c0b0c844b65424251dbc3399039789b064f/nova/compute/manager.py#L4930

  The new connection_info comes from Cinder:

  
https://github.com/openstack/nova/blob/1ad41c0b0c844b65424251dbc3399039789b064f/nova/compute/manager.py#L4901

  That's a plain dict from the response which may contain credentials.

  The old connection_info comes from the
  nova.objects.block_device.BlockDeviceMapping object, which uses
  SensitiveStringField to sanitize the field's value when logged:

  
https://github.com/openstack/nova/blob/1ad41c0b0c844b65424251dbc3399039789b064f/nova/compute/manager.py#L4904

  
https://github.com/openstack/oslo.versionedobjects/blob/1.23.0/oslo_versionedobjects/fields.py#L280

  The new connection_info could contain credentials though, so we should
  mask those when logging it, even at debug level.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1685678/+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 1764556] Re: "nova list" fails with exception.ServiceNotFound if service is deleted and has no UUID

[Matt Riedemann]

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

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

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

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

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

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

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

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

Title:
  "nova list" fails with exception.ServiceNotFound if service is deleted
  and has no UUID

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

Bug description:
  We had a testcase where we booted an instance on Newton, migrated it
  off the compute node, deleted the compute node (and service), upgraded
  to Pike, created a new compute node with the same name, and migrated
  the instance back to the compute node.

  At this point the "nova list" command failed with
  exception.ServiceNotFound.

  It appears that since the Service has no UUID the _from_db_object()
  routine will try to add it, but the service.save() call fails because
  the service in question has been deleted.

  I reproduced the issue with stable/pike devstack.  I booted an
  instance, then created a fake entry in the "services" table without a
  UUID so the table looked like this:

  mysql>  select * from services;
  
+-+-+-++--++---+--+--+-+-+-+-+-+--+
  | created_at  | updated_at  | deleted_at  | id | host 
| binary | topic | report_count | disabled | deleted | 
disabled_reason | last_seen_up| forced_down | version | uuid
 |
  
+-+-+-++--++---+--+--+-+-+-+-+-+--+
  | 2018-02-20 16:10:07 | 2018-04-16 22:10:46 | NULL|  1 | 
devstack | nova-conductor | conductor |   477364 |0 |   0 | 
NULL| 2018-04-16 22:10:46 |   0 |  22 | 
c041d7cf-5047-4014-b50c-3ba6b5d95097 |
  | 2018-02-20 16:10:10 | 2018-04-16 22:10:54 | NULL|  2 | 
devstack | nova-compute   | compute   |   477149 |0 |   0 | 
NULL| 2018-04-16 22:10:54 |   0 |  22 | 
d0cfb63c-8b59-4b65-bb7e-6b89acd3fe35 |
  | 2018-02-20 16:10:10 | 2018-04-16 20:29:33 | 2018-04-16 20:30:33 |  3 | 
devstack | nova-compute   | compute   |   476432 |0 |   3 | 
NULL| 2018-04-16 20:30:33 |   0 |  22 | NULL
 |
  
+-+-+-++--++---+--+--+-+-+-+-+-+--+


  At this point, running "nova show " worked fine, but running
  "nova list" failed:

  stack@devstack:~/devstack$ nova list
  ERROR (ClientException): 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-b7e1b5f9-e7b4-4ccf-ba28-e8b3e1acd2f6)

  
  The nova-api log looked like this:

  Apr 16 22:11:00 devstack devstack@n-api.service[4258]: DEBUG nova.compute.api 
[None req-b7e1b5f9-e7b4-4ccf-ba28-e8b3e1acd2f6 demo demo] Listing 1000 
instances in cell 09eb515f-9906-40bf-9be6-63b5e6ee279a(cell1) {{(pid=4261) 
_get_instances_by_filters_all_cells /opt/stack/nova/nova/compute/api.py:2559}}
  Apr 16 22:11:00 devstack devstack@n-api.service[4258]: DEBUG 
oslo_concurrency.lockutils [None req-b7e1b5f9-e7b4-4ccf-ba28-e8b3e1acd2f6 demo 
demo] Lock "09eb515f-9906-40bf-9be6-63b5e6ee279a" acquired by 
"nova.context.get_or_set_cached_cell_and_set_connections" :: waited 0.000s 
{{(pid=4261) inner 
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:270}}
  Apr 16 22:11:00 devstack devstack@n-api.service[4258]: DEBUG 
oslo_concurrency.lockutils [None req-b7e1b5f9-e7b4-4ccf-ba28-e8b3e1acd2f6 demo 
demo] Lock "09eb515f-9906-40bf-9be6-63b5e6ee279a" released by 
"nova.context.get_or_set_cached_cell_and_set_connections" :: held 0.000s 
{{(pid=4261) inner 
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:282}}
  Apr 16 22:11:00 devstack devstack@n-api.service[4258]: 

[Yahoo-eng-team] [Bug 1765144] [NEW] [keystone_authtoken] auth_url = http://controller:35357 port error, it should be 5000

[Yufei]

Public bug reported:

[api]
# ...
auth_strategy = keystone

[keystone_authtoken]
# ...
auth_uri = http://controller:5000
auth_url = http://controller:35357
memcached_servers = controller:11211
auth_type = password
project_domain_name = default
user_domain_name = default
project_name = service
username = nova
password = NOVA_PASS


above configuration has the port error, should replace 35357 to 5000


Thanks
Yufei


This bug tracker is for errors with the documentation, use the following
as a template and remove or add fields as you see fit. Convert [ ] into
[x] to check boxes:

- [ ] This doc is inaccurate in this way: __
- [ ] This is a doc addition request.
- [ ] I have a fix to the document that I can paste below including example: 
input and output. 

If you have a troubleshooting or support issue, use the following
resources:

 - Ask OpenStack: http://ask.openstack.org
 - The mailing list: http://lists.openstack.org
 - IRC: 'openstack' channel on Freenode

---
Release: 17.0.3.dev13 on 2018-04-17 17:03
SHA: 991c2926cbcb16dab9cf0ef059b0393b6c895490
Source: 
https://git.openstack.org/cgit/openstack/nova/tree/doc/source/install/controller-install-ubuntu.rst
URL: 
https://docs.openstack.org/nova/queens/install/controller-install-ubuntu.html

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

Title:
  [keystone_authtoken]  auth_url = http://controller:35357 port error,
  it should be 5000

Status in OpenStack Compute (nova):
  New

Bug description:
  [api]
  # ...
  auth_strategy = keystone

  [keystone_authtoken]
  # ...
  auth_uri = http://controller:5000
  auth_url = http://controller:35357
  memcached_servers = controller:11211
  auth_type = password
  project_domain_name = default
  user_domain_name = default
  project_name = service
  username = nova
  password = NOVA_PASS

  
  above configuration has the port error, should replace 35357 to 5000

  
  Thanks
  Yufei



  This bug tracker is for errors with the documentation, use the
  following as a template and remove or add fields as you see fit.
  Convert [ ] into [x] to check boxes:

  - [ ] This doc is inaccurate in this way: __
  - [ ] This is a doc addition request.
  - [ ] I have a fix to the document that I can paste below including example: 
input and output. 

  If you have a troubleshooting or support issue, use the following
  resources:

   - Ask OpenStack: http://ask.openstack.org
   - The mailing list: http://lists.openstack.org
   - IRC: 'openstack' channel on Freenode

  ---
  Release: 17.0.3.dev13 on 2018-04-17 17:03
  SHA: 991c2926cbcb16dab9cf0ef059b0393b6c895490
  Source: 
https://git.openstack.org/cgit/openstack/nova/tree/doc/source/install/controller-install-ubuntu.rst
  URL: 
https://docs.openstack.org/nova/queens/install/controller-install-ubuntu.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1765144/+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 1754417] Re: Documentation is missing dependency for python-openstackclient

[OpenStack Infra]

Reviewed:  https://review.openstack.org/552568
Committed: 
https://git.openstack.org/cgit/openstack/keystone/commit/?id=f01edae95c389108ee0ff66c8a0933f6e5c57cf4
Submitter: Zuul
Branch:master

commit f01edae95c389108ee0ff66c8a0933f6e5c57cf4
Author: Russell Tweed 
Date:   Tue Mar 13 16:13:00 2018 +

Add prerequisite package note to Keystone install guide

Added prerequisite package note and associated link to the main Install 
Guide
to the Keystone install guide. This is to ensure commands further down the
Keystone guide don't fail unexpectedly.

Change-Id: I189854fbc7f1e05945ab0002c08ee84f7bfad196
Closes-Bug: 1754413
Closes-Bug: 1754417


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

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

Title:
  Documentation is missing dependency for python-openstackclient

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:

  This bug tracker is for errors with the documentation, use the
  following as a template and remove or add fields as you see fit.
  Convert [ ] into [x] to check boxes:

  - [x ] This doc is inaccurate in this way: openstack queens on centos
  7.4.  missing dependancy python-openstackclient that provides the
  openstack command.

  - [ ] This is a doc addition request.
  - [ ] I have a fix to the document that I can paste below including example: 
input and output. 

  If you have a troubleshooting or support issue, use the following
  resources:

   - Ask OpenStack: http://ask.openstack.org
   - The mailing list: http://lists.openstack.org
   - IRC: 'openstack' channel on Freenode

  ---
  Release: 13.0.0.0rc3.dev1 on 2018-02-22 22:43
  SHA: c06d74fcf4cf5338db6572265c609036f6817466
  Source: 
https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/keystone-users-rdo.rst
  URL: 
https://docs.openstack.org/keystone/queens/install/keystone-users-rdo.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1754417/+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 1754413] Re: Documentation is missing steps to include a dependency for openstack-selinux

[OpenStack Infra]

Reviewed:  https://review.openstack.org/552568
Committed: 
https://git.openstack.org/cgit/openstack/keystone/commit/?id=f01edae95c389108ee0ff66c8a0933f6e5c57cf4
Submitter: Zuul
Branch:master

commit f01edae95c389108ee0ff66c8a0933f6e5c57cf4
Author: Russell Tweed 
Date:   Tue Mar 13 16:13:00 2018 +

Add prerequisite package note to Keystone install guide

Added prerequisite package note and associated link to the main Install 
Guide
to the Keystone install guide. This is to ensure commands further down the
Keystone guide don't fail unexpectedly.

Change-Id: I189854fbc7f1e05945ab0002c08ee84f7bfad196
Closes-Bug: 1754413
Closes-Bug: 1754417


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

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

Title:
  Documentation is missing steps to include a dependency for openstack-
  selinux

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  This bug tracker is for errors with the documentation, use the
  following as a template and remove or add fields as you see fit.
  Convert [ ] into [x] to check boxes:

  - [x] This doc is inaccurate in this way: 
  Installing keystone queens on centos 7.4 from documentation 

  ln -s /usr/share/keystone/wsgi-keystone.conf /etc/httpd/conf.d/
  command will not allow httpd to start due to selinux confilicts.  Missing 
dependancy is openstack-selinux which requires the Cloud, OS, and Extras 
repisitories enabled.

  - [ ] This is a doc addition request.
  - [ ] I have a fix to the document that I can paste below including example: 
input and output. 

  If you have a troubleshooting or support issue, use the following
  resources:

   - Ask OpenStack: http://ask.openstack.org
   - The mailing list: http://lists.openstack.org
   - IRC: 'openstack' channel on Freenode

  ---
  Release: 13.0.0.0rc3.dev1 on 2018-02-22 22:43
  SHA: c06d74fcf4cf5338db6572265c609036f6817466
  Source: 
https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/keystone-install-rdo.rst
  URL: 
https://docs.openstack.org/keystone/queens/install/keystone-install-rdo.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1754413/+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 1764556] Re: "nova list" fails with exception.ServiceNotFound if service is deleted and has no UUID

[Chris Friesen]

I think we could get into the bad state described in the bug if we do a
slightly different series of actions:

1) boot instance on Ocata
2) migrate instance 
3) delete compute node (thus deleting the service record) 
4) create compute node with same name 
5) migrate instance to newly-created compute node 
6) upgrade to Pike

This should result in the deleted service not having a UUID, which will
cause problems in Pike if we do a "nova list".


I suppose an argument could be made that this is an unlikely scenario, which is 
probably true. :)

** Changed in: nova
   Status: Fix Released => 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/1764556

Title:
  "nova list" fails with exception.ServiceNotFound if service is deleted
  and has no UUID

Status in OpenStack Compute (nova):
  New

Bug description:
  We had a testcase where we booted an instance on Newton, migrated it
  off the compute node, deleted the compute node (and service), upgraded
  to Pike, created a new compute node with the same name, and migrated
  the instance back to the compute node.

  At this point the "nova list" command failed with
  exception.ServiceNotFound.

  It appears that since the Service has no UUID the _from_db_object()
  routine will try to add it, but the service.save() call fails because
  the service in question has been deleted.

  I reproduced the issue with stable/pike devstack.  I booted an
  instance, then created a fake entry in the "services" table without a
  UUID so the table looked like this:

  mysql>  select * from services;
  
+-+-+-++--++---+--+--+-+-+-+-+-+--+
  | created_at  | updated_at  | deleted_at  | id | host 
| binary | topic | report_count | disabled | deleted | 
disabled_reason | last_seen_up| forced_down | version | uuid
 |
  
+-+-+-++--++---+--+--+-+-+-+-+-+--+
  | 2018-02-20 16:10:07 | 2018-04-16 22:10:46 | NULL|  1 | 
devstack | nova-conductor | conductor |   477364 |0 |   0 | 
NULL| 2018-04-16 22:10:46 |   0 |  22 | 
c041d7cf-5047-4014-b50c-3ba6b5d95097 |
  | 2018-02-20 16:10:10 | 2018-04-16 22:10:54 | NULL|  2 | 
devstack | nova-compute   | compute   |   477149 |0 |   0 | 
NULL| 2018-04-16 22:10:54 |   0 |  22 | 
d0cfb63c-8b59-4b65-bb7e-6b89acd3fe35 |
  | 2018-02-20 16:10:10 | 2018-04-16 20:29:33 | 2018-04-16 20:30:33 |  3 | 
devstack | nova-compute   | compute   |   476432 |0 |   3 | 
NULL| 2018-04-16 20:30:33 |   0 |  22 | NULL
 |
  
+-+-+-++--++---+--+--+-+-+-+-+-+--+


  At this point, running "nova show " worked fine, but running
  "nova list" failed:

  stack@devstack:~/devstack$ nova list
  ERROR (ClientException): 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-b7e1b5f9-e7b4-4ccf-ba28-e8b3e1acd2f6)

  
  The nova-api log looked like this:

  Apr 16 22:11:00 devstack devstack@n-api.service[4258]: DEBUG nova.compute.api 
[None req-b7e1b5f9-e7b4-4ccf-ba28-e8b3e1acd2f6 demo demo] Listing 1000 
instances in cell 09eb515f-9906-40bf-9be6-63b5e6ee279a(cell1) {{(pid=4261) 
_get_instances_by_filters_all_cells /opt/stack/nova/nova/compute/api.py:2559}}
  Apr 16 22:11:00 devstack devstack@n-api.service[4258]: DEBUG 
oslo_concurrency.lockutils [None req-b7e1b5f9-e7b4-4ccf-ba28-e8b3e1acd2f6 demo 
demo] Lock "09eb515f-9906-40bf-9be6-63b5e6ee279a" acquired by 
"nova.context.get_or_set_cached_cell_and_set_connections" :: waited 0.000s 
{{(pid=4261) inner 
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:270}}
  Apr 16 22:11:00 devstack devstack@n-api.service[4258]: DEBUG 
oslo_concurrency.lockutils [None req-b7e1b5f9-e7b4-4ccf-ba28-e8b3e1acd2f6 demo 
demo] Lock "09eb515f-9906-40bf-9be6-63b5e6ee279a" released by 
"nova.context.get_or_set_cached_cell_and_set_connections" :: held 0.000s 
{{(pid=4261) inner 
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:282}}
  Apr 16 22:11:00 devstack devstack@n-api.service[4258]: DEBUG 

[Yahoo-eng-team] [Bug 1759971] Re: [dvr][fast-exit] a route to a tenant network does not get created in fip namespace if an external network is attached after a tenant network have been attached (race

[Launchpad Bug Tracker]

This bug was fixed in the package neutron - 2:12.0.0-0ubuntu3

---
neutron (2:12.0.0-0ubuntu3) bionic; urgency=medium

  * d/p/refresh-router-objects-after-port-binding.patch: Cherry-picked
from upstream stable/queens branch (LP: #1759971).
  * d/p/use-cidr-during-tenant-network-rule-deletion.patch: Cherry-picked
from upstream stable/queens branch (LP: #1759956).

 -- Corey Bryant   Mon, 16 Apr 2018 16:06:25
-0400

** Changed in: neutron (Ubuntu Bionic)
   Status: Triaged => 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/1759971

Title:
  [dvr][fast-exit] a route to a tenant network does not get created in
  fip namespace if an external network is attached after a tenant
  network have been attached (race condition)

Status in Ubuntu Cloud Archive:
  Triaged
Status in Ubuntu Cloud Archive pike series:
  Triaged
Status in Ubuntu Cloud Archive queens series:
  Triaged
Status in neutron:
  Fix Released
Status in neutron package in Ubuntu:
  Fix Released
Status in neutron source package in Artful:
  Triaged
Status in neutron source package in Bionic:
  Fix Released

Bug description:
  Overall, similar scenario to
  https://bugs.launchpad.net/neutron/+bug/1759956 but a different
  problem.

  Relevant agent config options:
  http://paste.openstack.org/show/718418/

  OpenStack Queens from UCA (xenial, GA kernel, deployed via OpenStack
  charms), 2 external subnets (one routed provider network), 1 tenant
  subnet, all subnets in the same address scope to trigger "fast exit"
  logic.

  Tenant subnet cidr: 192.168.100.0/24

  openstack address scope create dev
  openstack subnet pool create --address-scope dev --pool-prefix 10.232.40.0/21 
--pool-prefix 10.232.16.0/21 dev
  openstack subnet pool create --address-scope dev --pool-prefix 
192.168.100.0/24 tenant
  openstack network create --external --provider-physical-network physnet1 
--provider-network-type flat pubnet
  openstack network segment set --name segment1 
d8391bfb-4466-4a45-972c-45ffcec9f6bc
  openstack network segment create --physical-network physnet2 --network-type 
flat --network pubnet segment2
  openstack subnet create --no-dhcp --subnet-pool dev --subnet-range 
10.232.16.0/21 --allocation-pool start=10.232.17.0,end=10.232.17.255 
--dns-nameserver 10.232.36.101 --ip-version 4 --network pubnet 
--network-segment segment1 pubsubnetl1
  openstack subnet create --gateway 10.232.40.100 --no-dhcp --subnet-pool dev 
--subnet-range 10.232.40.0/21 --allocation-pool 
start=10.232.41.0,end=10.232.41.255 --dns-nameserver 10.232.36.101 --ip-version 
4 --network pubnet --network-segment segment2 pubsubnetl2
  openstack network create --internal --provider-network-type vxlan tenantnet
   openstack subnet create --dhcp --ip-version 4 --subnet-range 
192.168.100.0/24 --subnet-pool tenant --dns-nameserver 10.232.36.101 --network 
tenantnet tenantsubnet

  # ---
  # Works in this order when an external network is attached first

  openstack router create --disable --no-ha --distributed pubrouter
  openstack router set --disable-snat --external-gateway pubnet --enable 
pubrouter

  openstack router add subnet pubrouter tenantsubnet

  2018-03-29 23:30:48.933 2050638 DEBUG neutron.agent.linux.utils [-] Running 
command: ['sudo', 'neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'ne
  tns', 'exec', 'fip-d0f008fc-dc45-4237-9ce0-a9e1977735eb', 'ip', '-4', 
'route', 'replace', '192.168.100.0/24', 'via', '169.254.106.114', 'dev', 
'fpr-09fd1
  424-7'] create_process 
/usr/lib/python2.7/dist-packages/neutron/agent/linux/utils.py:92

  # --
  # Doesn't work the other way around - as a fip namespace does not get created 
before a tenant network is attached
  openstack router create --disable --no-ha --distributed pubrouter

  openstack router add subnet pubrouter tenantsubnet
  openstack router set --disable-snat --external-gateway pubnet --enable 
pubrouter

  # to "fix" this we need to re-trigger the right code path

  openstack router remove subnet pubrouter tenantsubnet
  openstack router add subnet pubrouter tenantsubnet

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1759971/+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 1759956] Re: [dvr][fast-exit] incorrect policy rules get deleted when a distributed router has ports on multiple tenant networks

[Launchpad Bug Tracker]

This bug was fixed in the package neutron - 2:12.0.0-0ubuntu3

---
neutron (2:12.0.0-0ubuntu3) bionic; urgency=medium

  * d/p/refresh-router-objects-after-port-binding.patch: Cherry-picked
from upstream stable/queens branch (LP: #1759971).
  * d/p/use-cidr-during-tenant-network-rule-deletion.patch: Cherry-picked
from upstream stable/queens branch (LP: #1759956).

 -- Corey Bryant   Mon, 16 Apr 2018 16:06:25
-0400

** Changed in: neutron (Ubuntu Bionic)
   Status: Triaged => 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/1759956

Title:
  [dvr][fast-exit] incorrect policy rules get deleted when a distributed
  router has ports on multiple tenant networks

Status in Ubuntu Cloud Archive:
  Triaged
Status in Ubuntu Cloud Archive pike series:
  Triaged
Status in Ubuntu Cloud Archive queens series:
  Triaged
Status in neutron:
  Fix Released
Status in neutron package in Ubuntu:
  Fix Released
Status in neutron source package in Artful:
  Triaged
Status in neutron source package in Bionic:
  Fix Released

Bug description:
  Ubuntu SRU details
  --
  [Impact]
  See Original Description below.

  [Test Case]
  See Original Description below.

  [Regression Potential]
  Low. All patches have landed upstream in corresponding stable branches. 

  Original Description
  
  TL;DR: ip -4 rule del priority  table  type unicast will 
delete the first matching rule it encounters: if there are two rules with the 
same priority it will just kill the first one it finds.

  The original setup is described here:
  https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1759918

  OpenStack Queens from UCA (xenial, GA kernel, deployed via OpenStack
  charms), 2 external subnets (one routed provider network), 2 tenant
  subnets all in the same address scope to trigger "fast exit".

  2 tenant networks attached (subnets 192.168.100.0/24 and
  192.168.200.0/24) to a DVR:

  # 2 rules as expected
  ip netns exec qrouter-4f9ca9ef-303b-4082-abbc-e50782d9b800 ip rule
  0:  from all lookup local
  32766:  from all lookup main
  32767:  from all lookup default
  8:  from 192.168.100.0/24 lookup 16
  8:  from 192.168.200.0/24 lookup 16

  # remove 192.168.200.0/24 sometimes deletes an incorrect policy rule
  openstack router remove subnet pubrouter othertenantsubnet

  # ip route del contains the cidr
  2018-03-29 20:09:52.946 2083594 DEBUG neutron.agent.linux.utils [-] Running 
command: ['sudo', 'neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'ne
  tns', 'exec', 'fip-d0f008fc-dc45-4237-9ce0-a9e1977735eb', 'ip', '-4', 
'route', 'del', '192.168.200.0/24', 'via', '169.254.93.94', 'dev', 
'fpr-4f9ca9ef-3'
  ] create_process 
/usr/lib/python2.7/dist-packages/neutron/agent/linux/utils.py:92

  # ip rule delete is not that specific
  2018-03-29 20:09:53.195 2083594 DEBUG neutron.agent.linux.utils [-] Running 
command: ['sudo', 'neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 
'netns', 'exec', 'qrouter-4f9ca9ef-303b-4082-abbc-e50782d9b800', 'ip', '-4', 
'rule', 'del', 'priority', '8', 'table', '16', 'type', 'unicast'] create_pr
  ocess /usr/lib/python2.7/dist-packages/neutron/agent/linux/utils.py:92

  2018-03-29 20:15:59.210 2083594 DEBUG neutron.agent.linux.utils [-] Running 
command: ['sudo', 'neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 
'netns', 'exec', 'qrouter-4f9ca9ef-303b-4082-abbc-e50782d9b800', 'ip', '-4', 
'rule', 'show'] create_process 
/usr/lib/python2.7/dist-packages/neutron/agent/linux/utils.py:92
  2018-03-29 20:15:59.455 2083594 DEBUG neutron.agent.linux.utils [-] Running 
command: ['sudo', 'neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 
'netns', 'exec', 'qrouter-4f9ca9ef-303b-4082-abbc-e50782d9b800', 'ip', '-4', 
'rule', 'add', 'from', '192.168.100.0/24', 'priority', '8', 'table', '16', 
'type', 'unicast'] create_process 
/usr/lib/python2.7/dist-packages/neutron/agent/linux/utils.py:92

  

  ip netns exec qrouter-4f9ca9ef-303b-4082-abbc-e50782d9b800 ip rule
  0:  from all lookup local
  32766:  from all lookup main
  32767:  from all lookup default
  8:  from 192.168.100.0/24 lookup 16
  8:  from 192.168.200.0/24 lookup 16

  # try to delete a rule manually to see what is going on

  ip netns exec qrouter-4f9ca9ef-303b-4082-abbc-e50782d9b800 ip rule ; ip netns 
exec qrouter-4f9ca9ef-303b-4082-abbc-e50782d9b800 ip -4 rule del priority 8 
table 16 type unicast ; ip netns exec 
qrouter-4f9ca9ef-303b-4082-abbc-e50782d9b800 ip rule
  0:  from all lookup local
  32766:  from all lookup main
  32767:  from all lookup default
  8:  from 192.168.100.0/24 lookup 16
  8:  from 192.168.200.0/24 lookup 16

  0:  from all lookup local
  32766:  from all lookup main
  32767:  from all lookup default
  8:  from 192.168.200.0/24 lookup 16

  

[Yahoo-eng-team] [Bug 1765122] [NEW] qemu-img execute not mocked in unit tests

[Jay Pipes]

Public bug reported:

nova.tests.unit.virt.test_images.QemuTestCase.test_qemu_info_with_errors
is failing in both py27 and py36 tox environments due to a missing mock.

This system does not have qemu(-img) installed in it and running unit
tests returns the following:

==
Failed 1 tests - output below:
==

nova.tests.unit.virt.test_images.QemuTestCase.test_qemu_info_with_errors


Captured traceback:
~~~
b'Traceback (most recent call last):'
b'  File 
"/home/jaypipes/src/git.openstack.org/openstack/nova/nova/virt/images.py", line 
73, in qemu_img_info'
b'out, err = utils.execute(*cmd, prlimit=QEMU_IMG_LIMITS)'
b'  File 
"/home/jaypipes/src/git.openstack.org/openstack/nova/nova/utils.py", line 231, 
in execute'
b'return processutils.execute(*cmd, **kwargs)'
b'  File 
"/home/jaypipes/src/git.openstack.org/openstack/nova/.tox/py36/lib/python3.6/site-packages/oslo_concurrency/processutils.py",
 line 424, in execute'
b'cmd=sanitized_cmd)'
b'oslo_concurrency.processutils.ProcessExecutionError: Unexpected error 
while running command.'
b'Command: 
/home/jaypipes/src/git.openstack.org/openstack/nova/.tox/py36/bin/python -m 
oslo_concurrency.prlimit --as=1073741824 --cpu=30 -- env LC_ALL=C LANG=C 
qemu-img info /fake/path'
b'Exit code: 127'
b"Stdout: ''"
b"Stderr: '/usr/bin/env: \xe2\x80\x98qemu-img\xe2\x80\x99: No such file or 
directory\\n'"
b''
b'During handling of the above exception, another exception occurred:'
b''
b'Traceback (most recent call last):'
b'  File 
"/home/jaypipes/src/git.openstack.org/openstack/nova/.tox/py36/lib/python3.6/site-packages/mock/mock.py",
 line 1305, in patched'
b'return func(*args, **keywargs)'
b'  File 
"/home/jaypipes/src/git.openstack.org/openstack/nova/nova/tests/unit/virt/test_images.py",
 line 37, in test_qemu_info_with_errors'
b"'/fake/path')"
b'  File 
"/home/jaypipes/src/git.openstack.org/openstack/nova/.tox/py36/lib/python3.6/site-packages/testtools/testcase.py",
 line 485, in assertRaises'
b'self.assertThat(our_callable, matcher)'
b'  File 
"/home/jaypipes/src/git.openstack.org/openstack/nova/.tox/py36/lib/python3.6/site-packages/testtools/testcase.py",
 line 496, in assertThat'
b'mismatch_error = self._matchHelper(matchee, matcher, message, 
verbose)'
b'  File 
"/home/jaypipes/src/git.openstack.org/openstack/nova/.tox/py36/lib/python3.6/site-packages/testtools/testcase.py",
 line 547, in _matchHelper'
b'mismatch = matcher.match(matchee)'
b'  File 
"/home/jaypipes/src/git.openstack.org/openstack/nova/.tox/py36/lib/python3.6/site-packages/testtools/matchers/_exception.py",
 line 108, in match'
b'mismatch = self.exception_matcher.match(exc_info)'
b'  File 
"/home/jaypipes/src/git.openstack.org/openstack/nova/.tox/py36/lib/python3.6/site-packages/testtools/matchers/_higherorder.py",
 line 62, in match'
b'mismatch = matcher.match(matchee)'
b'  File 
"/home/jaypipes/src/git.openstack.org/openstack/nova/.tox/py36/lib/python3.6/site-packages/testtools/testcase.py",
 line 475, in match'
b'reraise(*matchee)'
b'  File 
"/home/jaypipes/src/git.openstack.org/openstack/nova/.tox/py36/lib/python3.6/site-packages/testtools/_compat3x.py",
 line 16, in reraise'
b'raise exc_obj.with_traceback(exc_tb)'
b'  File 
"/home/jaypipes/src/git.openstack.org/openstack/nova/.tox/py36/lib/python3.6/site-packages/testtools/matchers/_exception.py",
 line 101, in match'
b'result = matchee()'
b'  File 
"/home/jaypipes/src/git.openstack.org/openstack/nova/.tox/py36/lib/python3.6/site-packages/testtools/testcase.py",
 line 1049, in __call__'
b'return self._callable_object(*self._args, **self._kwargs)'
b'  File 
"/home/jaypipes/src/git.openstack.org/openstack/nova/nova/virt/images.py", line 
87, in qemu_img_info'
b'raise exception.InvalidDiskInfo(reason=msg)'
b'nova.exception.InvalidDiskInfo: Disk info file is invalid: qemu-img 
failed to execute on /fake/path : Unexpected error while running command.'
b'Command: 
/home/jaypipes/src/git.openstack.org/openstack/nova/.tox/py36/bin/python -m 
oslo_concurrency.prlimit --as=1073741824 --cpu=30 -- env LC_ALL=C LANG=C 
qemu-img info /fake/path'
b'Exit code: 127'
b"Stdout: ''"
b"Stderr: '/usr/bin/env: \xe2\x80\x98qemu-img\xe2\x80\x99: No such file or 
directory\\n'"
b''

** Affects: nova
 Importance: Low
 Assignee: Jay Pipes (jaypipes)
 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/1765122

Title:
  qemu-img execute not mocked in unit tests

Status in OpenStack Compute (nova):
  New

Bug description:
  

[Yahoo-eng-team] [Bug 1733383] Re: qos_bw_limit_direction extension not properly documented in api-ref

[OpenStack Infra]

Reviewed:  https://review.openstack.org/559562
Committed: 
https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=d144e0172b2e67a7d872083f69cd72afed4fe901
Submitter: Zuul
Branch:master

commit d144e0172b2e67a7d872083f69cd72afed4fe901
Author: Michal Kelner Mishali 
Date:   Sun Apr 8 12:49:03 2018 +0300

Document QoS bandwidth limit direction extension

Closes-Bug: #1733383

Change-Id: I235abd3c44455c5c19ea29404ff1b9c3a8b050aa
Signed-off-by: Michal Kelner Mishali 


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

Title:
  qos_bw_limit_direction extension not properly documented in api-ref

Status in neutron:
  Fix Released

Bug description:
  While the qos_bw_limit_direction extension params are documented in
  the qos api-ref, the extension needs a subsection atop the bw limit
  rule section describing the extension itself. See other api-refs for
  examples.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1733383/+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 1764878] Re: api-ref: confirmResize Preconditions doc has some incorrect information

[OpenStack Infra]

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

commit 203572a8ae671a64c08cc949b9bbc005e3119d2f
Author: Matt Riedemann 
Date:   Tue Apr 17 17:55:41 2018 -0400

Fix docs for confirmResize action

The docs had three things wrong:

1. The server status would be VERIFY_RESIZE, not VERIFY_RESIZED.

2. The RESIZED value is on the OS-EXT-STS:vm_state field, not
   vm_status.

3. The migration record status must be "finished", which is what
   gets set on the migration record in the _finish_resize() method
   in ComputeManager and used in the comptue API.confirm_resize()
   method. "confirming" status is what the API sets the migration
   record to before casting to nova-compute to finish the
   confirmation.

Stepping back, this is too many conditionals for what is really
needed. So rather than fix all three items individually, this
change simply fixes the first one and removes the other two since
the 'status' is based on the 'vm_state' internally, and a non-admin
user cannot list migrations anyway, and the _finish_resize()
method sets the migration status *before* the vm_state.

Closes-Bug: #1764878

Change-Id: Ib751686880ee824cf0693a649f47c828f515b471


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

Title:
  api-ref: confirmResize Preconditions doc has some incorrect
  information

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  There are three things wrong here:

  https://developer.openstack.org/api-ref/compute/#confirm-resized-
  server-confirmresize-action

  "You can only confirm the resized server where the status is
  VERIFY_RESIZED, the vm_status is RESIZED, and the migration_status is
  finished or confirming."

  1. The status must be VERIFY_RESIZE.
  2. The vm_state field is RESIZED, not vm_status.
  3. The migration status would be 'finished', not 'confirming' since 
'confirming' is the migration status after you initiate the confirmResize 
status.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1764878/+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 1751396] Re: DVR: Inter Tenant Traffic between two networks and connected through a shared network not reachable with DVR routers

[Corey Bryant]

** Also affects: neutron (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: neutron (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Also affects: cloud-archive
   Importance: Undecided
   Status: New

** Also affects: cloud-archive/pike
   Importance: Undecided
   Status: New

** Also affects: cloud-archive/queens
   Importance: Undecided
   Status: New

** Changed in: cloud-archive/pike
   Status: New => Triaged

** Changed in: cloud-archive/queens
   Status: New => Triaged

** Changed in: neutron (Ubuntu Artful)
   Status: New => Triaged

** Changed in: neutron (Ubuntu Bionic)
   Status: New => Triaged

** Changed in: cloud-archive/pike
   Importance: Undecided => High

** Changed in: cloud-archive/queens
   Importance: Undecided => High

** Changed in: neutron (Ubuntu Artful)
   Importance: Undecided => High

** Changed in: neutron (Ubuntu Bionic)
   Importance: Undecided => High

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

Title:
  DVR: Inter Tenant Traffic between two networks and connected through a
  shared network not reachable with DVR routers

Status in Ubuntu Cloud Archive:
  Triaged
Status in Ubuntu Cloud Archive pike series:
  Triaged
Status in Ubuntu Cloud Archive queens series:
  Triaged
Status in neutron:
  Fix Released
Status in neutron package in Ubuntu:
  Triaged
Status in neutron source package in Artful:
  Triaged
Status in neutron source package in Bionic:
  Triaged

Bug description:
  Inter Tenant Traffic between Two Tenants on two different private
  networks connected through a common shared network (created by Admin)
  is not route able through DVR routers

  Steps to reproduce it:

  (NOTE: No external, just shared network)
  This is only reproducable in Multinode scenario. ( 1 Controller - 2 compute ).
  Make sure that the two VMs are isolated in two different computes.

  openstack network create --share shared_net

  openstack subnet create shared_net_sn --network shared_net --subnet-
  range 172.168.10.0/24

  
  openstack network create net_A
  openstack subnet create net_A_sn --network net_A --subnet-range 10.1.0.0/24

  
  openstack network create net_B
  openstack subnet create net_B_sn --network net_B --subnet-range 10.2.0.0/24

  
  openstack router create router_A

  openstack port create --network=shared_net --fixed-ip 
subnet=shared_net_sn,ip-address=172.168.10.20 port_router_A_shared_net
  openstack router add port router_A port_router_A_shared_net
  openstack router add subnet router_A net_A_sn

  openstack router create router_B
  openstack port create --network=shared_net --fixed-ip 
subnet=shared_net_sn,ip-address=172.168.10.30 port_router_B_shared_net
  openstack router add port router_B port_router_B_shared_net
  openstack router add subnet router_B net_B_sn

  openstack server create server_A --flavor m1.tiny --image cirros --nic 
net-id=net_A
  openstack server create server_B --flavor m1.tiny --image cirros --nic 
net-id=net_B

  Add static routes to the router.
  openstack router set router_A --route 
destination=10.1.0.0/24,gateway=172.168.10.20
  openstack router set router_B --route 
destination=10.2.0.0/24,gateway=172.168.10.30
  ```

  Ping from one instance to the other times out

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1751396/+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 1751396] Re: DVR: Inter Tenant Traffic between two networks and connected through a shared network not reachable with DVR routers

[Dmitrii Shcherbakov]

** Also affects: neutron (Ubuntu)
   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/1751396

Title:
  DVR: Inter Tenant Traffic between two networks and connected through a
  shared network not reachable with DVR routers

Status in neutron:
  Fix Released
Status in neutron package in Ubuntu:
  New

Bug description:
  Inter Tenant Traffic between Two Tenants on two different private
  networks connected through a common shared network (created by Admin)
  is not route able through DVR routers

  Steps to reproduce it:

  (NOTE: No external, just shared network)
  This is only reproducable in Multinode scenario. ( 1 Controller - 2 compute ).
  Make sure that the two VMs are isolated in two different computes.

  openstack network create --share shared_net

  openstack subnet create shared_net_sn --network shared_net --subnet-
  range 172.168.10.0/24

  
  openstack network create net_A
  openstack subnet create net_A_sn --network net_A --subnet-range 10.1.0.0/24

  
  openstack network create net_B
  openstack subnet create net_B_sn --network net_B --subnet-range 10.2.0.0/24

  
  openstack router create router_A

  openstack port create --network=shared_net --fixed-ip 
subnet=shared_net_sn,ip-address=172.168.10.20 port_router_A_shared_net
  openstack router add port router_A port_router_A_shared_net
  openstack router add subnet router_A net_A_sn

  openstack router create router_B
  openstack port create --network=shared_net --fixed-ip 
subnet=shared_net_sn,ip-address=172.168.10.30 port_router_B_shared_net
  openstack router add port router_B port_router_B_shared_net
  openstack router add subnet router_B net_B_sn

  openstack server create server_A --flavor m1.tiny --image cirros --nic 
net-id=net_A
  openstack server create server_B --flavor m1.tiny --image cirros --nic 
net-id=net_B

  Add static routes to the router.
  openstack router set router_A --route 
destination=10.1.0.0/24,gateway=172.168.10.20
  openstack router set router_B --route 
destination=10.2.0.0/24,gateway=172.168.10.30
  ```

  Ping from one instance to the other times out

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1751396/+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 1765085] [NEW] DataSourceSmartOS ignores sdc:hostname

[Mike Gerdts]

Public bug reported:

In SmartOS, vmadm(1M) documents the hostname property as the way to set
the VM's hostname.  This property is available in the guest via the
sdc:hostname metadata property.  DataSourceSmartOS does not use this
value.  It currently sets the hostname from the following properties,
the first one wins.

1. hostname
2. sdc:uuid

The order should be:

1. sdc:hostname
2. hostname
3. sdc:uuid

** Affects: cloud-init
 Importance: Undecided
 Assignee: Mike Gerdts (mgerdts)
 Status: New

** Changed in: cloud-init
 Assignee: (unassigned) => Mike Gerdts (mgerdts)

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

Title:
  DataSourceSmartOS ignores sdc:hostname

Status in cloud-init:
  New

Bug description:
  In SmartOS, vmadm(1M) documents the hostname property as the way to
  set the VM's hostname.  This property is available in the guest via
  the sdc:hostname metadata property.  DataSourceSmartOS does not use
  this value.  It currently sets the hostname from the following
  properties, the first one wins.

  1. hostname
  2. sdc:uuid

  The order should be:

  1. sdc:hostname
  2. hostname
  3. sdc:uuid

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1765085/+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 1746530] Re: nova-manage api_db sync - NotSupportedWarning ['use_tpool']

[Surya Seetharaman]

IMO, this patch in oslo_db should fix this issue -
https://github.com/openstack/oslo.db/commit/c432d9e93884d6962592f6d19aaec3f8f66ac3a2

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

** Changed in: nova
 Assignee: Surya Seetharaman (tssurya) => (unassigned)

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

Title:
  nova-manage api_db sync - NotSupportedWarning ['use_tpool']

Status in OpenStack Compute (nova):
  Won't Fix

Bug description:
  In the nova queens 17.0.0.0b3 release, I'm seeing the following:

  $ nova-manage api_db sync
  /usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py:332: 
NotSupportedWarning: Configuration option(s) ['use_tpool'] not supported
exception.NotSupportedWarning

  This is with Ubuntu packages, so I've not tried to recreate with pip-
  installed packages.

  In our /etc/nova/nova.conf use_tpool is commented out.

  If I revert the following commit, the error goes away:
  
https://github.com/openstack/nova/commit/910008e2ef5dae1698ff7db791f4816c728c8bd0

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1746530/+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 1736336] Re: Image data stays in backend if image signature verification fails

[OpenStack Infra]

Reviewed:  https://review.openstack.org/529083
Committed: 
https://git.openstack.org/cgit/openstack/glance/commit/?id=7c3a9c83da0b673b293131db74f6ca35613a1815
Submitter: Zuul
Branch:master

commit 7c3a9c83da0b673b293131db74f6ca35613a1815
Author: Pranali Deore 
Date:   Tue Dec 19 19:50:01 2017 +0530

Cleaning image data when image signature verification fails

While creating an image, image data stays in backend if image
signature verification fails.

After raising SignatureVerificationError exception, image status is
being set to 'killed' in DB but the image data remains as it is in
the backend.

Adding delete_from_backend() call to cleanup the data from backend when
Singature Verification fails.

Closes-Bug: #1736336
Change-Id: I2a1a7addd33050cc8845aec24479aa4d1bc26ca0


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

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

Title:
  Image data stays in backend if image signature verification fails

Status in Glance:
  Fix Released
Status in Glance queens series:
  Triaged

Bug description:
  If image signature verification is enabled then while creating the
  image if verfication fails then it returns vaild error, deletes image
  from the database but image data stays in the bakend forever.

  Ideally if image verfication fails then it should delete the data from
  the backend as well.

  Pre-requisites:
  1. Ensure Barbican is enabled
  2. Create Keys and Certificate (Reference  
https://etherpad.openstack.org/p/mitaka-glance-image-signing-instructions#90)
  3. Create Signature (Reference 
https://etherpad.openstack.org/p/mitaka-glance-image-signing-instructions#184) 
and note down output of 'signature_64'
  4. Create context and upload certificate using context (Reference 
https://etherpad.openstack.org/p/glance-image-signing-create-context) and note 
down output of 'cert_uuid'

  
  Steps to reproduce:
  1. Upload Image to Glance, with Signature Metadata
 img_signature_certificate_uuid = 'fb67edd2-95ef-404b-9af2-910708c6d9b7'
 img_signature_hash_method = 'SHA-256'
 img_signature_key_type = 'RSA-PSS'
 img_signature = 
'ezccBYtJEdj2gOrN09woioHwi2rDVvBsmRI0i+9EYAYdE7E6FV8jzJD9BImcq/m7Dm6yZZPkCUHz+y4HBKeYqK0+otcz921zaeqcKGBvU1t7J9AL0hEgJbWg0RY6RXqDXpsOQrrkrHuna4O+BUOp6sPwb3j2eFYbbsqW6d/obgM='
 (different which is noted in Pre-requisites section Point 4 as 'signature_64')

 $ glance image-create --property
  name=cirrosSignedImage_goodSignature --property is-public=true
  --container-format bare --disk-format qcow2 --property
  
img_signature='abcdBYtJEdj2gOrN09woioHwi2rDVvBsmRI0i+9EYAYdE7E6FV8jzJD9BImcq/m7Dm6yZZPkCUHz+y4HBKeYqK0+otcz921zaeqcKGBvU1t7J9AL0hEgJbWg0RY6RXqDXpsOQrrkrHuna4O+BUOp6sPwb3j2eFYbbsqW6d/obgM='
  --property img_signature_certificate_uuid='fb67edd2-95ef-404b-
  9af2-910708c6d9b7' --property img_signature_hash_method='SHA-256'
  --property img_signature_key_type='RSA-PSS' --file
  cirros-0.3.2-source.tar.gz

  Note:
  'img_signature' starts with 'ezcc...' but in create command I have passed as 
'abcd..'

  Actual Output:
  
++--+
  | Property   | Value  
  |
  
++--+
  | checksum   | None   
  |
  | container_format   | bare   
  |
  | created_at | 2017-12-05T07:04:38Z   
  |
  | disk_format| qcow2  
  |
  | id | 6e8bec71-2176-4bcc-a732-2f76c5ac589f   
  |
  | img_signature  | 
abcdBYtJEdj2gOrN09woioHwi2rDVvBsmRI0i+9EYAYdE7E6FV8jzJD9BImcq/m7Dm6yZZPkCUHz+y4H
 |
  || 
BKeYqK0+otcz921zaeqcKGBvU1t7J9AL0hEgJbWg0RY6RXqDXpsOQrrkrHuna4O+BUOp6sPwb3j2eFYb
 |
  || bsqW6d/obgM=   
  |
  | img_signature_certificate_uuid | fb67edd2-95ef-404b-9af2-910708c6d9b7   
  |
  | img_signature_hash_method  | SHA-256
  |
  | img_signature_key_type | RSA-PSS
  |
  | is-public  

[Yahoo-eng-team] [Bug 1765024] [NEW] requires_keypair does not affect NG interface

[Dmitriy R.]

Public bug reported:

Hi,

Setting "'requires_keypair': True" in OPENSTACK_HYPERVISOR_FEATURES does
not affect new server creation form (angular one). So it is impossible
to make key_pair as a required field now with this setting. Meanwhile
this approach still works in the legacy form.

It is reproduced in environments with horizon versions 13.0.0 and 12.0.2

** Affects: horizon
 Importance: Undecided
 Status: New


** Tags: angularjs pike queens

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

Title:
  requires_keypair does not affect NG interface

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Hi,

  Setting "'requires_keypair': True" in OPENSTACK_HYPERVISOR_FEATURES
  does not affect new server creation form (angular one). So it is
  impossible to make key_pair as a required field now with this setting.
  Meanwhile this approach still works in the legacy form.

  It is reproduced in environments with horizon versions 13.0.0 and
  12.0.2

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1765024/+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 1764976] [NEW] Install and configure (Ubuntu) in glance: config error

[Realtime]

Private bug reported:

This bug tracker is for errors with the documentation, use the following
as a template and remove or add fields as you see fit. Convert [ ] into
[x] to check boxes:

- [X] This doc is inaccurate in this way: __

In this Docu the following line appears two times:

auth_uri = http://controller:5000
auth_url = http://controller:5000

This is obviously an error (even it would not break the installation).

- [ ] This is a doc addition request.
- [ ] I have a fix to the document that I can paste below including example: 
input and output. 

If you have a troubleshooting or support issue, use the following
resources:

 - Ask OpenStack: http://ask.openstack.org
 - The mailing list: http://lists.openstack.org
 - IRC: 'openstack' channel on Freenode

---
Release: 16.0.1.dev16 on 'Thu Apr 12 19:15:43 2018, commit 42fe71f'
SHA: 42fe71f9d770c70211f8e83759c7232f5ff2b75e
Source: 
https://git.openstack.org/cgit/openstack/glance/tree/doc/source/install/install-ubuntu.rst
URL: https://docs.openstack.org/glance/queens/install/install-ubuntu.html

** Affects: glance
 Importance: Undecided
 Status: Invalid

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

Title:
  Install and configure (Ubuntu) in glance: config error

Status in Glance:
  Invalid

Bug description:
  This bug tracker is for errors with the documentation, use the
  following as a template and remove or add fields as you see fit.
  Convert [ ] into [x] to check boxes:

  - [X] This doc is inaccurate in this way: __

  In this Docu the following line appears two times:

  auth_uri = http://controller:5000
  auth_url = http://controller:5000

  This is obviously an error (even it would not break the installation).

  - [ ] This is a doc addition request.
  - [ ] I have a fix to the document that I can paste below including example: 
input and output. 

  If you have a troubleshooting or support issue, use the following
  resources:

   - Ask OpenStack: http://ask.openstack.org
   - The mailing list: http://lists.openstack.org
   - IRC: 'openstack' channel on Freenode

  ---
  Release: 16.0.1.dev16 on 'Thu Apr 12 19:15:43 2018, commit 42fe71f'
  SHA: 42fe71f9d770c70211f8e83759c7232f5ff2b75e
  Source: 
https://git.openstack.org/cgit/openstack/glance/tree/doc/source/install/install-ubuntu.rst
  URL: https://docs.openstack.org/glance/queens/install/install-ubuntu.html

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