[Yahoo-eng-team] [Bug 1743212] Re: SSL Cert for cloud-init.org invalid

2018-01-15 Thread David Britton 
Cert has been fixed.

** Changed in: cloud-init
   Status: Confirmed => Fix Released

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

Title:
  SSL Cert for cloud-init.org invalid

Status in cloud-init:
  Fix Released

Bug description:
  If I visit cloud-init.org i get a cert that is only valid for cloud-init.io.
  Is the .org site legitimate or a bogus site? Is it a simple misconfiguration?
  I reached the .org site through Google, so it must be popular in some sense.
  A picture is worth a thousand words, so have a look at the attached 
screenshot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1743212/+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 1731623] Re: many UT cases are broken due to "AttributeError: type object 'Route' has no attribute 'foreign_keys'"

2018-01-15 Thread YAMAMOTO Takashi 
** Changed in: networking-midonet
   Status: New => Fix Released

** Changed in: networking-midonet
Milestone: None => 6.0.0

** Changed in: networking-midonet
 Assignee: (unassigned) => YAMAMOTO Takashi (yamamoto)

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

Title:
  many UT cases are broken due to "AttributeError: type object 'Route'
  has no attribute 'foreign_keys'"

Status in networking-midonet:
  Fix Released
Status in neutron:
  Fix Released

Bug description:
  eg. http://logs.openstack.org/24/518824/1/gate/openstack-tox-
  py27/6ea4c06/job-output.txt.gz

  2017-11-11 07:19:32.914772 | ubuntu-xenial | {2} 
midonet.neutron.tests.unit.test_extension_taas.TestMidonetTaasCaseML2.test_delete_tap_service_error_delete_neutron_resource
 [0.865560s] ... ok
  2017-11-11 07:19:32.931319 | ubuntu-xenial | INFO  
[alembic.runtime.migration] Running upgrade 24f28869838b -> 41b509d10b5e, 
VPNaaS endpoint groups
  2017-11-11 07:19:32.947636 | ubuntu-xenial | add_router_interface failed: No 
details.
  2017-11-11 07:19:32.947704 | ubuntu-xenial | Traceback (most recent call 
last):
  2017-11-11 07:19:32.947748 | ubuntu-xenial |   File 
"/home/zuul/src/git.openstack.org/openstack/neutron/neutron/api/v2/resource.py",
 line 98, in resource
  2017-11-11 07:19:32.947775 | ubuntu-xenial | result = 
method(request=request, **args)
  2017-11-11 07:19:32.947812 | ubuntu-xenial |   File 
"/home/zuul/src/git.openstack.org/openstack/neutron/neutron/db/api.py", line 
92, in wrapped
  2017-11-11 07:19:32.947837 | ubuntu-xenial | setattr(e, 
'_RETRY_EXCEEDED', True)
  2017-11-11 07:19:32.947889 | ubuntu-xenial |   File 
"/home/zuul/src/git.openstack.org/openstack/networking-midonet/.tox/py27/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
 line 220, in __exit__
  2017-11-11 07:19:32.947946 | ubuntu-xenial | self.force_reraise()
  2017-11-11 07:19:32.948002 | ubuntu-xenial |   File 
"/home/zuul/src/git.openstack.org/openstack/networking-midonet/.tox/py27/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
 line 196, in force_reraise
  2017-11-11 07:19:32.948029 | ubuntu-xenial | six.reraise(self.type_, 
self.value, self.tb)
  2017-11-11 07:19:32.948086 | ubuntu-xenial |   File 
"/home/zuul/src/git.openstack.org/openstack/neutron/neutron/db/api.py", line 
88, in wrapped
  2017-11-11 07:19:32.948117 | ubuntu-xenial | return f(*args, **kwargs)
  2017-11-11 07:19:32.948169 | ubuntu-xenial |   File 
"/home/zuul/src/git.openstack.org/openstack/networking-midonet/.tox/py27/local/lib/python2.7/site-packages/oslo_db/api.py",
 line 150, in wrapper
  2017-11-11 07:19:32.948191 | ubuntu-xenial | ectxt.value = e.inner_exc
  2017-11-11 07:19:32.948259 | ubuntu-xenial |   File 
"/home/zuul/src/git.openstack.org/openstack/networking-midonet/.tox/py27/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
 line 220, in __exit__
  2017-11-11 07:19:32.948291 | ubuntu-xenial | self.force_reraise()
  2017-11-11 07:19:32.948363 | ubuntu-xenial |   File 
"/home/zuul/src/git.openstack.org/openstack/networking-midonet/.tox/py27/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
 line 196, in force_reraise
  2017-11-11 07:19:32.948393 | ubuntu-xenial | six.reraise(self.type_, 
self.value, self.tb)
  2017-11-11 07:19:32.948444 | ubuntu-xenial |   File 
"/home/zuul/src/git.openstack.org/openstack/networking-midonet/.tox/py27/local/lib/python2.7/site-packages/oslo_db/api.py",
 line 138, in wrapper
  2017-11-11 07:19:32.948466 | ubuntu-xenial | return f(*args, **kwargs)
  2017-11-11 07:19:32.948504 | ubuntu-xenial |   File 
"/home/zuul/src/git.openstack.org/openstack/neutron/neutron/db/api.py", line 
127, in wrapped
  2017-11-11 07:19:32.948533 | ubuntu-xenial | LOG.debug("Retry wrapper got 
retriable exception: %s", e)
  2017-11-11 07:19:32.948586 | ubuntu-xenial |   File 
"/home/zuul/src/git.openstack.org/openstack/networking-midonet/.tox/py27/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
 line 220, in __exit__
  2017-11-11 07:19:32.948607 | ubuntu-xenial | self.force_reraise()
  2017-11-11 07:19:32.948659 | ubuntu-xenial |   File 
"/home/zuul/src/git.openstack.org/openstack/networking-midonet/.tox/py27/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
 line 196, in force_reraise
  2017-11-11 07:19:32.948686 | ubuntu-xenial | six.reraise(self.type_, 
self.value, self.tb)
  2017-11-11 07:19:32.948723 | ubuntu-xenial |   File 
"/home/zuul/src/git.openstack.org/openstack/neutron/neutron/db/api.py", line 
123, in wrapped
  2017-11-11 07:19:32.948746 | ubuntu-xenial | return f(*dup_args, 
**dup_kwargs)
  2017-11-11 07:19:32.948786 | ubuntu-xenial |   File 
"/home/zuul/src/git.openstack.org/openstack/neutron/neutron/api/v2/base.py", 
line 247, in _handle_action
  2017-11-11 07:19:32.948817 | ubuntu-xenial | ret_value =

[Yahoo-eng-team] [Bug 1743493] [NEW] Start dashboard fails with django template syntax error

2018-01-15 Thread Emma Hogan 
Public bug reported:

I was trying to start a new dashboard following the instructions from
https://docs.openstack.org/horizon/latest/contributor/tutorials/dashboard.html.
When I ran the command

$ tox -e manage -- startdash mydashboard \
  --target openstack_dashboard/dashboards/mydashboard

the python files were created but not the template files. The
dashboard.py file was created with a .tmpl file extension. The terminal
gave an error code:

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

I was running the new master horizon.

** Affects: horizon
 Importance: Undecided
 Status: New

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

Title:
  Start dashboard fails with django template syntax error

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  I was trying to start a new dashboard following the instructions from
  
https://docs.openstack.org/horizon/latest/contributor/tutorials/dashboard.html.
  When I ran the command

  $ tox -e manage -- startdash mydashboard \
--target openstack_dashboard/dashboards/mydashboard

  the python files were created but not the template files. The
  dashboard.py file was created with a .tmpl file extension. The
  terminal gave an error code:

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

  I was running the new master horizon.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1743493/+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 1743480] [NEW] No way to differenciate beween floating IP networks and external provider networks

2018-01-15 Thread Sam Morrison 
Public bug reported:

We have a bunch of external shared provider networks that users can
attach a port to and get direct access to the Internet.

We also have a bunch of floating IP networks that users can use for
floating IPs.

The two types of networks are shared and external.


The issue is that our users can't develop code against our cloud to figure out 
what network to use for floating IPs.

Luckily for us our provider networks use a different
provider:network_type to our floating IP networks so they can do:

search_opts = {'provider:network_type': 'midonet', 'router:external': True}
client.list_networks(**search_opts).get('networks')

But this is not very nice and by no means portable with other openstack
clouds they use.

I think https://bugs.launchpad.net/neutron/+bug/1721305 is related to
this bug

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

Title:
  No way to differenciate beween floating IP networks and external
  provider networks

Status in neutron:
  New

Bug description:
  We have a bunch of external shared provider networks that users can
  attach a port to and get direct access to the Internet.

  We also have a bunch of floating IP networks that users can use for
  floating IPs.

  The two types of networks are shared and external.

  
  The issue is that our users can't develop code against our cloud to figure 
out what network to use for floating IPs.

  Luckily for us our provider networks use a different
  provider:network_type to our floating IP networks so they can do:

  search_opts = {'provider:network_type': 'midonet', 'router:external': True}
  client.list_networks(**search_opts).get('networks')

  But this is not very nice and by no means portable with other
  openstack clouds they use.

  I think https://bugs.launchpad.net/neutron/+bug/1721305 is related to
  this bug

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1743480/+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 1743463] [NEW] linuxbridge scenario job fails with: "AttributeError: 'LinuxbridgeAgentExtensionAPI' object has no attribute 'request_int_br'"

2018-01-15 Thread Ihar Hrachyshka 
Public bug reported:

log extension is not compatible with linuxbridge agent. We should, short
term, avoid configuring it there; and long term, make it compatible with
the agent. (It should be doable because the agent uses the same iptables
firewall).

** Affects: neutron
 Importance: High
 Status: 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/1743463

Title:
  linuxbridge scenario job fails with: "AttributeError:
  'LinuxbridgeAgentExtensionAPI' object has no attribute
  'request_int_br'"

Status in neutron:
  Confirmed

Bug description:
  log extension is not compatible with linuxbridge agent. We should,
  short term, avoid configuring it there; and long term, make it
  compatible with the agent. (It should be doable because the agent uses
  the same iptables firewall).

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1743463/+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 1743458] [NEW] Device tagging does not work for PF passthrough

2018-01-15 Thread Artom Lifshitz 
Public bug reported:

Description
===

When booting an instance with a PF passed through, device tags applied
to the PF do not appear in the metadata.

Steps to reproduce
==

Create a PF neutron port:

$ neutron port-create sriov --binding:vnic-type direct-physical --name
pf

Boot a VM with that port:

$ nova test-sriov_vf_2 [...] --nic port-
id=88691de9-1a20-4f86-9931-e694786b5bdf,tag=ticky

>From inside the guest, access the metadata:

$ curl http://169.254.169.254/openstack/latest/meta_data.json

Expected result
===

A device with role tag 'ticky' appears in the metadata.

Actual result
=

No device with role tag 'ticky' in the metadata.

Environment
===

1. Exact version of OpenStack you are running.

This was originally reported in Red Hat OpenStack 10 (Newton), but I
believe the problem still exists on master.

2. Which hypervisor did you use?


libvirt+kvm

3. Which networking type did you use?

neutron

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

Title:
  Device tagging does not work for PF passthrough

Status in OpenStack Compute (nova):
  New

Bug description:
  Description
  ===

  When booting an instance with a PF passed through, device tags applied
  to the PF do not appear in the metadata.

  Steps to reproduce
  ==

  Create a PF neutron port:

  $ neutron port-create sriov --binding:vnic-type direct-physical --name
  pf

  Boot a VM with that port:

  $ nova test-sriov_vf_2 [...] --nic port-
  id=88691de9-1a20-4f86-9931-e694786b5bdf,tag=ticky

  From inside the guest, access the metadata:

  $ curl http://169.254.169.254/openstack/latest/meta_data.json

  Expected result
  ===

  A device with role tag 'ticky' appears in the metadata.

  Actual result
  =

  No device with role tag 'ticky' in the metadata.

  Environment
  ===

  1. Exact version of OpenStack you are running.

  This was originally reported in Red Hat OpenStack 10 (Newton), but I
  believe the problem still exists on master.

  2. Which hypervisor did you use?

  
  libvirt+kvm

  3. Which networking type did you use?

  neutron

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1743458/+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 1743445] [NEW] Switch from msgpack-python to msgpack

2018-01-15 Thread Dirk Mueller 
Public bug reported:

msgpack-python has been renamed to msgpack, see
https://pypi.python.org/pypi/msgpack-python/0.5.1:


This package is deprecated. Install msgpack instead.

** Affects: keystone
 Importance: Undecided
 Status: New

** Affects: openstack-requirements
 Importance: Undecided
 Status: New

** Affects: oslo.privsep
 Importance: Undecided
 Status: New

** Affects: oslo.serialization
 Importance: Undecided
 Status: New

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

** Also affects: oslo.privsep
   Importance: Undecided
   Status: New

** Also affects: oslo.serialization
   Importance: Undecided
   Status: New

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

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

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

Title:
  Switch from msgpack-python to msgpack

Status in OpenStack Identity (keystone):
  New
Status in OpenStack Global Requirements:
  New
Status in oslo.privsep:
  New
Status in oslo.serialization:
  New
Status in tooz:
  New

Bug description:
  msgpack-python has been renamed to msgpack, see
  https://pypi.python.org/pypi/msgpack-python/0.5.1:

  
  This package is deprecated. Install msgpack instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1743445/+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 1743425] [NEW] Changes to VLAN mapping results in "is not mapped" error

2018-01-15 Thread Tyler Bishop 
Public bug reported:

With neutron-server if you enable the type_drivers = vlan and set a
mapping in [ml2_type_vlan] then install the neutron database, the
service will start and map successfully.

However if you change the mapping after and restart the service you will
receive error:

2018-01-15 11:50:36.875 9764 ERROR neutron   File 
"/usr/lib/python2.7/site-packages/neutron/plugins/ml2/drivers/type_vlan.py", 
line 133, in _sync_vlan_allocations
2018-01-15 11:50:36.875 9764 ERROR neutron ctx.session.delete(alloc)
2018-01-15 11:50:36.875 9764 ERROR neutron   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/session.py", line 1744, in 
delete
2018-01-15 11:50:36.875 9764 ERROR neutron raise 
exc.UnmappedInstanceError(instance)
2018-01-15 11:50:36.875 9764 ERROR neutron UnmappedInstanceError: Class 
'neutron.objects.plugins.ml2.vlanallocation.VlanAllocation' is not mapped
2018-01-15 11:50:36.875 9764 ERROR neutron 


plugin.ini:
[ml2]
type_drivers = vlan
tenant_network_types = vlan
mechanism_drivers = openvswitch

[ml2_type_vlan]
network_vlan_ranges = physnet0:2:4000

sync DB:
 su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf 
--config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head" neutron

Start neutron-server, Success!

Now change plugin.ini to the following:

[ml2_type_vlan]
network_vlan_ranges = physnet1:2:4000

Restart neutron-server.  Failure!

Versions:
openstack-neutron-11.0.2-3.el7.noarch
openstack-neutron-ml2-11.0.2-3.el7.noarch
openstack-neutron-common-11.0.2-3.el7.noarch
openstack-neutron-openvswitch-11.0.2-3.el7.noarch
openstack-neutron-linuxbridge-11.0.2-3.el7.noarch
python-neutron-11.0.2-3.el7.noarch
python-neutron-lib-1.9.1-1.el7.noarch
python2-neutronclient-6.5.0-1.el7.noarch

pip
neutron==11.0.2
neutron-lib==1.9.1
python-neutronclient==6.5.0

CentOS 7 @ 3.10.0-693.11.6.el7.x86_64

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

Title:
  Changes to VLAN mapping results in "is not mapped" error

Status in neutron:
  New

Bug description:
  With neutron-server if you enable the type_drivers = vlan and set a
  mapping in [ml2_type_vlan] then install the neutron database, the
  service will start and map successfully.

  However if you change the mapping after and restart the service you
  will receive error:

  2018-01-15 11:50:36.875 9764 ERROR neutron   File 
"/usr/lib/python2.7/site-packages/neutron/plugins/ml2/drivers/type_vlan.py", 
line 133, in _sync_vlan_allocations
  2018-01-15 11:50:36.875 9764 ERROR neutron ctx.session.delete(alloc)
  2018-01-15 11:50:36.875 9764 ERROR neutron   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/session.py", line 1744, in 
delete
  2018-01-15 11:50:36.875 9764 ERROR neutron raise 
exc.UnmappedInstanceError(instance)
  2018-01-15 11:50:36.875 9764 ERROR neutron UnmappedInstanceError: Class 
'neutron.objects.plugins.ml2.vlanallocation.VlanAllocation' is not mapped
  2018-01-15 11:50:36.875 9764 ERROR neutron 

  
  plugin.ini:
  [ml2]
  type_drivers = vlan
  tenant_network_types = vlan
  mechanism_drivers = openvswitch

  [ml2_type_vlan]
  network_vlan_ranges = physnet0:2:4000

  sync DB:
   su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf 
--config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head" neutron

  Start neutron-server, Success!

  Now change plugin.ini to the following:

  [ml2_type_vlan]
  network_vlan_ranges = physnet1:2:4000

  Restart neutron-server.  Failure!

  Versions:
  openstack-neutron-11.0.2-3.el7.noarch
  openstack-neutron-ml2-11.0.2-3.el7.noarch
  openstack-neutron-common-11.0.2-3.el7.noarch
  openstack-neutron-openvswitch-11.0.2-3.el7.noarch
  openstack-neutron-linuxbridge-11.0.2-3.el7.noarch
  python-neutron-11.0.2-3.el7.noarch
  python-neutron-lib-1.9.1-1.el7.noarch
  python2-neutronclient-6.5.0-1.el7.noarch

  pip
  neutron==11.0.2
  neutron-lib==1.9.1
  python-neutronclient==6.5.0

  CentOS 7 @ 3.10.0-693.11.6.el7.x86_64

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1743425/+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 1673090] Re: Swap disk on stopped instance fails silently

2018-01-15 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/389798
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=b40d949b3137473227949b597b2a61da41752ee5
Submitter: Zuul
Branch:master

commit b40d949b3137473227949b597b2a61da41752ee5
Author: Mark Giles 
Date:   Mon Jul 24 12:46:21 2017 -0400

Do not attempt volume swap when guest is stopped/suspended

A swap on a stopped or suspended instance will fail silently. Remove
these allowed instance states on swap_volume:

suspended, stopped, soft_deleted

Change-Id: Iff17f7cee7a56037b35d1a361a0b3279d0a885d6
Closes-Bug: #1673090


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

Title:
  Swap disk on stopped instance fails silently

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Using either the cli or API, if you attempt to swap disks (nova
  volume-update, compute.api.swap_volume) on a stopped instance, the
  command appears to succeed, but the swap is not performed. The way you
  can tell what didn't happen is that the volume status's of the 2
  volumes remain as they were before the operation.

  It would be better to throw an exception when a swap is attempted on a
  stopped instance. (this can get tricky since an instance can stop at
  any time during the swap operation. btw, it seems odd that attach and
  detach are supported on a stopped instance but swap is not. would it
  be better to support swap on a stopped instance?)

  In the compute log is this exception:

  2017-03-15 09:20:13.729 ERROR nova.compute.manager 
[^[[01;36mreq-e978c2af-d537-4855-ba5f-58ec1976ad2f 
^[[00;36mtempest-SwapVolumeTestJSON-1034316961 
tempest-SwapVolumeTestJSON-1034316961] ^[[01;35m[instance: 
26fe837e-d72c-4969-8934-09dc92b61897] Failed to swap volume 
11cda3f1-15c3-4195-b404-a7e912f4c517 for 
8b6a1904-3e54-43f4-b498-0fa153d7cf17^[[00m
  2017-03-15 09:20:13.729 TRACE nova.compute.manager ^[[01;35m[instance: 
26fe837e-d72c-4969-8934-09dc92b61897] ^[[00mTraceback (most recent call last):
  2017-03-15 09:20:13.729 TRACE nova.compute.manager ^[[01;35m[instance: 
26fe837e-d72c-4969-8934-09dc92b61897] ^[[00m  File 
"/opt/stack/nova/nova/compute/manager.py", line 4988, in _swap_volume
  2017-03-15 09:20:13.729 TRACE nova.compute.manager ^[[01;35m[instance: 
26fe837e-d72c-4969-8934-09dc92b61897] ^[[00mresize_to)
  2017-03-15 09:20:13.729 TRACE nova.compute.manager ^[[01;35m[instance: 
26fe837e-d72c-4969-8934-09dc92b61897] ^[[00m  File 
"/opt/stack/nova/nova/virt/libvirt/driver.py", line 1300, in swap_volume
  2017-03-15 09:20:13.729 TRACE nova.compute.manager ^[[01;35m[instance: 
26fe837e-d72c-4969-8934-09dc92b61897] ^[[00mself._swap_volume(guest, 
disk_dev, conf.source_path, resize_to)
  2017-03-15 09:20:13.729 TRACE nova.compute.manager ^[[01;35m[instance: 
26fe837e-d72c-4969-8934-09dc92b61897] ^[[00m  File 
"/opt/stack/nova/nova/virt/libvirt/driver.py", line 1257, in _swap_volume
  2017-03-15 09:20:13.729 TRACE nova.compute.manager ^[[01;35m[instance: 
26fe837e-d72c-4969-8934-09dc92b61897] ^[[00mdev.rebase(new_path, copy=True, 
reuse_ext=True)
  2017-03-15 09:20:13.729 TRACE nova.compute.manager ^[[01;35m[instance: 
26fe837e-d72c-4969-8934-09dc92b61897] ^[[00m  File 
"/opt/stack/nova/nova/virt/libvirt/guest.py", line 748, in rebase
  2017-03-15 09:20:13.729 TRACE nova.compute.manager ^[[01;35m[instance: 
26fe837e-d72c-4969-8934-09dc92b61897] ^[[00mself._disk, base, 
self.REBASE_DEFAULT_BANDWIDTH, flags=flags)
  2017-03-15 09:20:13.729 TRACE nova.compute.manager ^[[01;35m[instance: 
26fe837e-d72c-4969-8934-09dc92b61897] ^[[00m  File 
"/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 186, in doit
  2017-03-15 09:20:13.729 TRACE nova.compute.manager ^[[01;35m[instance: 
26fe837e-d72c-4969-8934-09dc92b61897] ^[[00mresult = 
proxy_call(self._autowrap, f, *args, **kwargs)
  2017-03-15 09:20:13.729 TRACE nova.compute.manager ^[[01;35m[instance: 
26fe837e-d72c-4969-8934-09dc92b61897] ^[[00m  File 
"/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 144, in 
proxy_call
  2017-03-15 09:20:13.729 TRACE nova.compute.manager ^[[01;35m[instance: 
26fe837e-d72c-4969-8934-09dc92b61897] ^[[00mrv = execute(f, *args, **kwargs)
  2017-03-15 09:20:13.729 TRACE nova.compute.manager ^[[01;35m[instance: 
26fe837e-d72c-4969-8934-09dc92b61897] ^[[00m  File 
"/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 125, in execute
  2017-03-15 09:20:13.729 TRACE nova.compute.manager ^[[01;35m[instance: 
26fe837e-d72c-4969-8934-09dc92b61897] ^[[00msix.reraise(c, e, tb)
  2017-03-15 09:20:13.729 TRACE nova.compute.manager ^[[01;35m[instance: 
26fe837e-d72c-4969-8934-09dc92b61897] ^[[00m  File 
"/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 83, in

[Yahoo-eng-team] [Bug 1732707] Re: AllocationCandidates.get_by_filters returns candidates containing non connected RPs

2018-01-15 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/522407
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=5e95c807d1d0ca23c4042d6df54c0cdda72b0caa
Submitter: Zuul
Branch:master

commit 5e95c807d1d0ca23c4042d6df54c0cdda72b0caa
Author: Tetsuro Nakamura 
Date:   Thu Nov 23 07:56:12 2017 +0900

Add aggregates check in allocation candidates

Allocation candidates api returned some wrong
combinations of non-sharing resource provider and
shared resource provider, ignoring aggregates.

This patch adds aggregate check when constructing
shared allocation request being aware of non-sharing
resource in _shared_allocation_request_resources.

Change-Id: Ib45fde56706a861df0fc048bbec8a568fd26d85d
Closes-Bug:#1732707


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

Title:
  AllocationCandidates.get_by_filters returns candidates containing non
  connected RPs

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Consider the following setup in placement:

 CN1 (VCPU)  CN2 (VCPU)
/ agg3   \ agg1 / agg1   \ agg2
SS3 (IPV4)   SS1 (DISK_GB)  SS2 (IPV4)

  Then VCPU, DISK_GB  nd IPV4 resources are requested. However besides
  the expected candidates we get invalid candidates mixing CN1 with SS2
  and CN2 with SS3 which are clearly invalid.

  Here is a functional test reproducing the issue:
  https://review.openstack.org/#/c/519617

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1732707/+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 1743233] Re: quota defaults: neutron quota names are not translated

2018-01-15 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/533425
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=b7f24dd39f11d99e70b11f63173a2abe770b475e
Submitter: Zuul
Branch:master

commit b7f24dd39f11d99e70b11f63173a2abe770b475e
Author: Akihiro Motoki 
Date:   Mon Jan 15 00:36:32 2018 +0900

Make neutron quota names translatable

Change-Id: I0cbf31344afe9bf8168b959acc532ddd9deacd6b
Closes-Bug: #1743233


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

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

Title:
  quota defaults: neutron quota names are not translated

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  In the "Defaults" panel of the "Admin" dashboard, neutron quota names
  are not translated.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1743233/+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 1742931] Re: ovs_lib: Custom vxlan udp port is not converted to string

2018-01-15 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/533176
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=622a137974dbe0ffec84149fc36d19e440bd18b2
Submitter: Zuul
Branch:master

commit 622a137974dbe0ffec84149fc36d19e440bd18b2
Author: Jakub Libosvar 
Date:   Fri Jan 12 13:48:33 2018 +0100

ovs-lib: Pass string as udp port to ovsdb

ovsdb maps accept strings as values only. This patch converts integer to
be passed to ovsdb in case vxlan_udp_port config value is used.

Change-Id: Idba77939a80d80a4bc9625d10c8b37b23b91b9c5
Closes-bug: #1742931


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

Title:
  ovs_lib: Custom vxlan udp port is not converted to string

Status in neutron:
  Fix Released

Bug description:
  If vxlan_udp_port is set to custom port in ovs agent config file then
  inserting integer instead of string into ovsdb is attempted.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1742931/+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 1722668] Re: Azure: bouncing of network device/publishing of hostname fails on artful

2018-01-15 Thread Launchpad Bug Tracker 
This bug was fixed in the package cloud-init - 17.2-9-gdf24daa8-0ubuntu1

---
cloud-init (17.2-9-gdf24daa8-0ubuntu1) bionic; urgency=medium

  * New upstream snapshot.
- tests: update apt sources list test [Joshua Powers]
- tests: clean up image properties [Joshua Powers]
- tests: rename test ssh keys to avoid appearance of leaking private keys.
  [Joshua Powers]
- tests: Enable AWS EC2 Integration Testing [Joshua Powers]
- cli: cloud-init clean handles symlinks [Chad Smith] (LP: #1741093)
- SUSE: Add a basic test of network config rendering. [Robert Schweikert]
- Azure: Only bounce network when necessary. [Chad Smith] (LP: #1722668)
- lint: Fix lints seen by pylint version 1.8.1. [Chad Smith]

 -- Scott Moser   Mon, 15 Jan 2018 06:42:30 -0500

** Changed in: cloud-init (Ubuntu)
   Status: Confirmed => Fix Released

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

Title:
  Azure: bouncing of network device/publishing of hostname fails on
  artful

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released

Bug description:
  Launch an instance on Azure (20171005.1) and I find in /var/log/cloud-init.log
  the following:

  2017-10-10 21:16:25,598 - DataSourceAzure.py[WARNING]: Failed publishing 
hostname: Unexpected error while running command.
  Command: ['sh', '-xc', 'i=$interface; x=0; ifdown $i || x=$?; ifup $i || 
x=$?; exit $x']
  Exit code: 127
  Reason: -
  Stdout: -
  Stderr: -
  2017-10-10 21:16:25,598 - util.py[WARNING]: handling set_hostname failed
  2017-10-10 21:16:25,598 - util.py[DEBUG]: handling set_hostname failed
  Traceback (most recent call last):
    File "/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceAzure.py", 
line 286, in bounce_network_with_azure_hostname
  prev_hostname=previous_hostname)
    File "/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceAzure.py", 
line 637, in perform_hostname_bounce
  'env': env})
    File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2238, in 
log_time
  ret = func(*args, **kwargs)
    File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 1847, in subp
  cmd=args)
  cloudinit.util.ProcessExecutionError: Unexpected error while running command.
  Command: ['sh', '-xc', 'i=$interface; x=0; ifdown $i || x=$?; ifup $i || 
x=$?; exit $x']
  Exit code: 127
  Reason: -
  Stdout: -
  Stderr: -

  The command output is  not captured, so we see in /var/log/cloud-init-
  output.log:

  + i=eth0
  + x=0
  + ifdown eth0
  sh: 1: ifdown: not found
  + x=127
  + ifup eth0
  sh: 1: ifup: not found
  + x=127
  + exit 127

  This is not surprising, there is no 'ifup' or 'ifdown', so the attempt to
  "bounce" the network device in order to re-publish the hostname that
  has been set will fail.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: cloud-init 17.1-17-g45d361cb-0ubuntu1
  ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3
  Uname: Linux 4.13.0-12-generic x86_64
  ApportVersion: 2.20.7-0ubuntu2
  Architecture: amd64
  CloudName: Azure
  Date: Tue Oct 10 21:45:09 2017
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  SourcePackage: cloud-init
  UpgradeStatus: No upgrade log present (probably fresh install)
  user_data.txt:

  Related bugs:
   * bug 1674685: hostname ddns update is not done on azure with built-in agent 
path. 
   * bug 1574963: juju2 lxd launch hostname reverse lookup inconsistent

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1722668/+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 1742505] Re: gre_sys set to default 1472 when using path_mtu > 1500 with ovs 2.8.x

2018-01-15 Thread James Page 
** Also affects: linux (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/1742505

Title:
  gre_sys set to default 1472 when using path_mtu > 1500 with ovs 2.8.x

Status in Ubuntu Cloud Archive:
  In Progress
Status in Ubuntu Cloud Archive pike series:
  In Progress
Status in Ubuntu Cloud Archive queens series:
  In Progress
Status in neutron:
  Invalid
Status in linux package in Ubuntu:
  Incomplete
Status in openvswitch package in Ubuntu:
  In Progress
Status in linux source package in Artful:
  Incomplete
Status in openvswitch source package in Artful:
  In Progress
Status in linux source package in Bionic:
  Incomplete
Status in openvswitch source package in Bionic:
  In Progress

Bug description:
  Setup:
  Pike neutron 11.0.2-0ubuntu1.1~cloud0
  OVS 2.8.0
  Jumbo frames setttings per: 
https://docs.openstack.org/mitaka/networking-guide/config-mtu.html
  global_physnet_mtu = 9000
  path_mtu = 9000

  Symptoms:
  gre_sys MTU is 1472
  Instances with MTUs > 1500 fail to communicate across GRE

  Temporary Workaround:
  ifconfig gre_sys MTU 9000
  Note: When ovs rebuilds tunnels, such as on a restart, gre_sys MTU is set 
back to default 1472.

  Note: downgrading from OVS 2.8.0 to 2.6.1 resolves the issue.

  Previous behavior:
  With Ocata or Pike and OVS 2.6.x
  gre_sys MTU defaults to 65490
  It remains at 65490 through restarts.

  This may be related to some combination of the following changes in OVS which 
seem to imply MTUs must be set in the ovs database for tunnel interfaces and 
patches:
  
https://github.com/openvswitch/ovs/commit/8c319e8b73032e06c7dd1832b3b31f8a1189dcd1
  
https://github.com/openvswitch/ovs/commit/3a414a0a4f1901ba015ec80b917b9fb206f3c74f
  
https://github.com/openvswitch/ovs/blob/6355db7f447c8e83efbd4971cca9265f5e0c8531/datapath/vport-internal_dev.c#L186

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1742505/+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 1743351] [NEW] keystone error apt-get upgrade packages version

2018-01-15 Thread admgsic 
Public bug reported:

Good Morning,

I wanted to comment on a problem that has happened to me several times
...

I had the OpenStack version "Newton" recently and I updated the
OpenStack version "Pike", and all right until the keystone in the
controller node did not work well for me as it told me in horizon:

"An error occurred authenticating. Please try again later."

In cli command line: Failed to discover available identity versions when 
contacting http: // controller: 35357 / v3. Attempting to parse version from 
URL.
Internal Server Error (HTTP 500)

In the end I had to do a clean installation of the controller node.

But just a week ago I decided to update the packages because there were
updates and bug fixes in some of them and the same error was shown
again.

Horizon:

"An error occurred authenticating. Please try again later."

In cli command line:

Failed to discover available identity versions when contacting http: // 
controller: 35357 / v3. Attempting to parse version from URL.
Internal Server Error (HTTP 500)

Does anyone know why something like this happens every time an apt-get
upgrade is done?

Greetings and thanks in advance,

** Affects: keystone
 Importance: Undecided
 Status: New

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

Title:
  keystone error apt-get upgrade packages version

Status in OpenStack Identity (keystone):
  New

Bug description:
  Good Morning,

  I wanted to comment on a problem that has happened to me several times
  ...

  I had the OpenStack version "Newton" recently and I updated the
  OpenStack version "Pike", and all right until the keystone in the
  controller node did not work well for me as it told me in horizon:

  "An error occurred authenticating. Please try again later."

  In cli command line: Failed to discover available identity versions when 
contacting http: // controller: 35357 / v3. Attempting to parse version from 
URL.
  Internal Server Error (HTTP 500)

  In the end I had to do a clean installation of the controller node.

  But just a week ago I decided to update the packages because there
  were updates and bug fixes in some of them and the same error was
  shown again.

  Horizon:

  "An error occurred authenticating. Please try again later."

  In cli command line:

  Failed to discover available identity versions when contacting http: // 
controller: 35357 / v3. Attempting to parse version from URL.
  Internal Server Error (HTTP 500)

  Does anyone know why something like this happens every time an apt-get
  upgrade is done?

  Greetings and thanks in advance,

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1743351/+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 1743298] Re: CLOUD VPS not working

2018-01-15 Thread Dimitar 
** 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/1743298

Title:
  CLOUD VPS not working

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  My CLOUD VPS is not working for more than month maybe. One day I tried to 
connect and I was unable to connect. I opened my nodeteria managing page and I 
there also the vps was stuck. The status was ERROR. I wrone an email about the 
problem and no one answered me. I continue get charged and I see new invoices 
and I don't have the service for I am paying!! 
  Now I opened the managing web page again and I see: Manage Your Server
  Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ 
and attach the Nova API log if possible. Where is this NOPA Api log ? 
  Fix my VM or I'll find better VPS provider!

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