[Yahoo-eng-team] [Bug 1492547] Re: ICMP codes can't be set in range [0, 255] when set firewall rules

[Bao Fangyan]

** Changed in: neutron
   Status: In Progress => 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/1492547

Title:
  ICMP codes can't be set  in range [0,255] when set firewall rules

Status in neutron:
  Invalid

Bug description:
   when setting firewall rules, I  select imcp protocol and set  port/port 
range.
  but get error report "Source, destination ports are not allowed when protocol 
 is set to ICMP."

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1492547/+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 1492547] Re: ICMP codes can't be set in range [0, 255] when set firewall rules

[Bao Fangyan]

** Changed in: neutron
   Status: Invalid => In Progress

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

Title:
  ICMP codes can't be set  in range [0,255] when set firewall rules

Status in neutron:
  In Progress

Bug description:
   when setting firewall rules, I  select imcp protocol and set  port/port 
range.
  but get error report "Source, destination ports are not allowed when protocol 
 is set to ICMP."

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1492547/+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 1496273] [NEW] String formatting wrong in nova/api/metadata/vendordata_json.py

[Andreas Jaeger]

Public bug reported:

The string contains a missing "s" for "%(variable)s" - and the missing
spaces confuse users.

See http://lists.openstack.org/pipermail/openstack-
i18n/2015-September/001359.html for the initial report.

** Affects: nova
 Importance: Undecided
 Assignee: Andreas Jaeger (jaegerandi)
 Status: In Progress

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

Title:
  String formatting wrong in nova/api/metadata/vendordata_json.py

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  The string contains a missing "s" for "%(variable)s" - and the missing
  spaces confuse users.

  See http://lists.openstack.org/pipermail/openstack-
  i18n/2015-September/001359.html for the initial report.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1496273/+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 1302080] Re: Host is accessible from instance using Linux bridge IPv6 address

[Ihar Hrachyshka]

** Also affects: nova
   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/1302080

Title:
  Host is accessible from instance using Linux bridge IPv6 address

Status in neutron:
  Confirmed
Status in OpenStack Compute (nova):
  New
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  Opening this as a security bug just in case - but I doubt it is.

  If a compute node has enabled auto configuration for IPv6 addresses on
  all interfaces, then the Linux bridges used for connecting instances
  will get IPv6 addresses too. Then an instance can reach the host using
  the address of the bridge it is connected to.

  Eg with the ovs-agent and hybrid VIF driver after booting an instance
  in devstack connected to the "private" network:

  vagrant@devstack:~$ brctl show
  bridge name   bridge id   STP enabled interfaces
  br-ex .9619b7f0614b   no  qg-97601dc1-77
  br-int.cad7ebe11e46   no  qr-edf68f52-f9
     qvoe8eabd6a-46
     tap09437e57-45
  qbre8eabd6a-468000.0e8e27c7cdfa   no  
qvbe8eabd6a-46
     tape8eabd6a-46

  vagrant@devstack:~$ ip address show dev qbre8eabd6a-46
  15: qbre8eabd6a-46:  mtu 1500 qdisc noqueue 
state UP
  link/ether 0e:8e:27:c7:cd:fa brd ff:ff:ff:ff:ff:ff
  inet6 fe80::dcc6:30ff:fe27:37a1/64 scope link
     valid_lft forever preferred_lft forever

  Note: the address fe80::dcc6:30ff:fe27:37a1 and login to instance:

  $ ssh ubuntu@172.24.4.3
  ubuntu@vm1:~$ ip address show dev eth0
  2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
  link/ether fa:16:3e:d1:7e:fe brd ff:ff:ff:ff:ff:ff
  inet 10.0.0.9/24 brd 10.0.0.255 scope global eth0
  inet6 fe80::f816:3eff:fed1:7efe/64 scope link
     valid_lft forever preferred_lft forever

  ubuntu@vm1:~$ ping6 -c4 -I eth0 ff02::1
  PING ff02::1(ff02::1) from fe80::f816:3eff:fed1:7efe eth0: 56 data bytes
  64 bytes from fe80::f816:3eff:fed1:7efe: icmp_seq=1 ttl=64 time=16.9 ms
  64 bytes from fe80::dcc6:30ff:fe27:37a1: icmp_seq=1 ttl=64 time=38.4 ms (DUP!)
  64 bytes from fe80::f816:3eff:fed1:7efe: icmp_seq=2 ttl=64 time=1.44 ms
  64 bytes from fe80::dcc6:30ff:fe27:37a1: icmp_seq=2 ttl=64 time=3.88 ms (DUP!)
  64 bytes from fe80::f816:3eff:fed1:7efe: icmp_seq=3 ttl=64 time=8.63 ms
  64 bytes from fe80::dcc6:30ff:fe27:37a1: icmp_seq=3 ttl=64 time=14.0 ms (DUP!)
  64 bytes from fe80::f816:3eff:fed1:7efe: icmp_seq=4 ttl=64 time=0.476 ms

  ubuntu@vm1:~$ ping6 -c1 -I eth0 fe80::dcc6:30ff:fe27:37a1
  PING fe80::dcc6:30ff:fe27:37a1(fe80::dcc6:30ff:fe27:37a1) from 
fe80::f816:3eff:fed1:7efe eth0: 56 data bytes
  64 bytes from fe80::dcc6:30ff:fe27:37a1: icmp_seq=1 ttl=64 time=2.86 ms

  ubuntu@vm1:~$ ssh fe80::dcc6:30ff:fe27:37a1%eth0
  The authenticity of host 'fe80::dcc6:30ff:fe27:37a1%eth0 
(fe80::dcc6:30ff:fe27:37a1%eth0)' can't be established.
  ECDSA key fingerprint is 11:5d:55:29:8a:77:d8:08:b4:00:9b:a3:61:93:fe:e5.
  Are you sure you want to continue connecting (yes/no)?

  I thought the anti-spoof rules should block packets from the fe80
  address, but looking at the ip6tables-save (attached) the spoof chain
  and its default DROP rule are missing. That must be because there is
  no IPv6 subnet on the "private" network - maybe that's another
  problem. I inserted them manually, but that did not work becuase these
  packets hit the host's INPUT chain and the security group filters are
  on the FORWARD chain.

  So maybe all that is needed is a note in the doc to say that auto
  config should be disabled by default and selectively enabled on
  interfaces if needed. E.g.:

  net.ipv6.conf.all.autoconf=0
  net.ipv6.conf.all.disable_ipv6=1
  net.ipv6.conf.default.disable_ipv6=1
  # enable on lo and eth1
  net.ipv6.conf.lo.disable_ipv6=0
  net.ipv6.conf.eth1.disable_ipv6=0

  Or maybe the VIF drivers should disable IPv6 on the bridge when
  creating it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1302080/+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 1496334] [NEW] Nova-compute launch slowly because lots of instances is init one by one

[Rui Chen]

Public bug reported:

1. code base

$ git log -1
commit b492942744e09276e3ba4dcf0196143c521a1662
Merge: 920abc9 9706454
Author: Jenkins 
Date:   Thu Sep 3 00:05:04 2015 +

Merge "Fix bodies on consolidate-console-api"

2. Reproduce steps:

The issue happen on VMware driver, think about the following case:
* 200 active instances run in one nova-compute host that map to one vCenter 
Cluster, batch delete all instances, all of them are in "deleting" task_state.
* nova-compute process stop and restart when all instances are in "deleting" 
task_state.
* nova-compute start to init 200 deleting instances one by one. The workflow of 
VMware driver is power-off instance, then wait task finish, then delete the 
instance.
* After all the deleting instances are handled, nova-compute is set to "up" 
state, continue to work.

step 3 will spend lots of time on serial init_instance. In my
performance test environment, the nova-compute spend about 15 minutes to
finish init_instance.

In other drivers, like: libvirt, nova-compute manage less instances than
VMware driver (maybe less than 50 instances), so these drivers have less
chance to face the issue.

** Affects: nova
 Importance: Undecided
 Assignee: Rui Chen (kiwik-chenrui)
 Status: In Progress

** Changed in: nova
 Assignee: (unassigned) => Rui Chen (kiwik-chenrui)

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

Title:
  Nova-compute launch slowly because lots of instances is init one by
  one

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  1. code base

  $ git log -1
  commit b492942744e09276e3ba4dcf0196143c521a1662
  Merge: 920abc9 9706454
  Author: Jenkins 
  Date:   Thu Sep 3 00:05:04 2015 +

  Merge "Fix bodies on consolidate-console-api"

  2. Reproduce steps:

  The issue happen on VMware driver, think about the following case:
  * 200 active instances run in one nova-compute host that map to one vCenter 
Cluster, batch delete all instances, all of them are in "deleting" task_state.
  * nova-compute process stop and restart when all instances are in "deleting" 
task_state.
  * nova-compute start to init 200 deleting instances one by one. The workflow 
of VMware driver is power-off instance, then wait task finish, then delete the 
instance.
  * After all the deleting instances are handled, nova-compute is set to "up" 
state, continue to work.

  step 3 will spend lots of time on serial init_instance. In my
  performance test environment, the nova-compute spend about 15 minutes
  to finish init_instance.

  In other drivers, like: libvirt, nova-compute manage less instances
  than VMware driver (maybe less than 50 instances), so these drivers
  have less chance to face the issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1496334/+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 1456439] Re: Disable Disassociate Floating IP to an instance in error state

[Timur Sufiev]

Kyrylo, please keep MOS bugs separate from Horizon bugs, otherwise
Mirantis gerrit will add comments here that make no sense for anyone
from upstream.

** No longer affects: mos

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

Title:
  Disable Disassociate Floating IP to an instance in error state

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  
  "Disassociate Floating IP" button should be disabled for instances in error 
state.

  As per the following bug, it has disabled only Associate Floating IP. 
  https://bugs.launchpad.net/horizon/+bug/1374576

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1456439/+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 1496138] Re: logging a warning when someone accesses / seems unnecessary and wasteful

[Flavio Percoco]

** Also affects: glance/liberty
   Importance: High
 Assignee: Erno Kuvaja (jokke)
   Status: In Progress

** Also affects: glance/kilo
   Importance: Undecided
   Status: New

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

Title:
  logging a warning when someone accesses / seems unnecessary and
  wasteful

Status in Glance:
  In Progress
Status in Glance kilo series:
  New
Status in Glance liberty series:
  In Progress

Bug description:
  Our load balancer health checks (and other folks too) just load the
  main glance URL and look for an http status of 300 to determine if
  glance is okay. Starting I think in Kilo, glance changed and now logs
  a warning. This is highly unnecessary and ends up generating gigs of
  useless logs which make diagnosing real issues more difficult.

  At the least this should be an INFO, but ideally there's no point in
  logging this at all.

  2015-08-04 17:42:43.058 24075 WARNING 
glance.api.middleware.version_negotiation [-] Unknown version. Returning 
version choices.
  2015-08-04 17:42:43.577 24071 WARNING 
glance.api.middleware.version_negotiation [-] Unknown version. Returning 
version choices.
  2015-08-04 17:42:45.083 24076 WARNING 
glance.api.middleware.version_negotiation [-] Unknown version. Returning 
version choices.
  2015-08-04 17:42:45.317 24064 WARNING 
glance.api.middleware.version_negotiation [-] Unknown version. Returning 
version choices.
  2015-08-04 17:42:47.092 24074 WARNING 
glance.api.middleware.version_negotiation [-] Unknown version. Returning 
version choices.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1496138/+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 1456439] Re: Disable Disassociate Floating IP to an instance in error state

[Kyrylo Romanenko]

Reproduced this bug on MOS 7.0 iso 288.
We can see default action for failed instances is "Disassociate Floating IP".

VERSION:
  feature_groups:
- mirantis
  production: "docker"
  release: "7.0"
  openstack_version: "2015.1.0-7.0"
  api: "1.0"
  build_number: "288"
  build_id: "288"
  nailgun_sha: "93477f9b42c5a5e0506248659f40bebc9ac23943"
  python-fuelclient_sha: "1ce8ecd8beb640f2f62f73435f4e18d1469979ac"
  fuel-agent_sha: "082a47bf014002e515001be05f99040437281a2d"
  fuel-nailgun-agent_sha: "d7027952870a35db8dc52f185bb1158cdd3d1ebd"
  astute_sha: "a717657232721a7fafc67ff5e1c696c9dbeb0b95"
  fuel-library_sha: "121016a09b0e889994118aa3ea42fa67eabb8f25"
  fuel-ostf_sha: "1f08e6e71021179b9881a824d9c57fcc7045"
  fuelmain_sha: "6b83d6a6a75bf7bca3177fcf63b2eebbf1ad0a85"


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

** Changed in: mos
 Assignee: (unassigned) => MOS Horizon (mos-horizon)

** Changed in: mos
Milestone: None => 8.0

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

** Attachment added: "Instances - OpenStack Dashboard - Google Chrome_083.png"
   
https://bugs.launchpad.net/mos/+bug/1456439/+attachment/4465958/+files/Instances%20-%20OpenStack%20Dashboard%20-%20Google%20Chrome_083.png

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

Title:
  Disable Disassociate Floating IP to an instance in error state

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  
  "Disassociate Floating IP" button should be disabled for instances in error 
state.

  As per the following bug, it has disabled only Associate Floating IP. 
  https://bugs.launchpad.net/horizon/+bug/1374576

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1456439/+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 1496370] [NEW] deleted vm data should not be stored in database for ever

[huangpengtaohw]

Public bug reported:

the deleted vm data is no useful if the vm is true deleted maybe immediately or 
sometime later,
which should not be stored in database for ever.it should be deleted

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

Title:
  deleted vm data should not be stored in database for ever

Status in OpenStack Compute (nova):
  New

Bug description:
  the deleted vm data is no useful if the vm is true deleted maybe immediately 
or sometime later,
  which should not be stored in database for ever.it should be deleted

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1496370/+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 1496410] [NEW] Create separate queue for state reports with dedicated workers

[Eugene Nikanorov]

Public bug reported:

In big clusters having hundreds of nodes, neutron rpc workers could be
consumed by rpc requests so much that they can't process state reports
from agents on time.

That lead to a condition when agents begin to "flap", appear dead and
alive. This in turn causes rescheduling which loads neutron-server even
more, creating self-sustaining loop.

** Affects: neutron
 Importance: Undecided
 Assignee: Eugene Nikanorov (enikanorov)
 Status: New


** Tags: neutron-core

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

Title:
  Create separate queue for state reports with dedicated workers

Status in neutron:
  New

Bug description:
  In big clusters having hundreds of nodes, neutron rpc workers could be
  consumed by rpc requests so much that they can't process state reports
  from agents on time.

  That lead to a condition when agents begin to "flap", appear dead and
  alive. This in turn causes rescheduling which loads neutron-server
  even more, creating self-sustaining loop.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1496410/+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 1496122] Re: CRITICAL nova [-] ImportError: No module named middleware.request_id

[Mark Doffman]

LIkey a support request, not likely a bug with nova but possibly a
support question or problem with openstack-chef.  Could you try asking
for support from openstack-chef.

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

Title:
  CRITICAL nova [-] ImportError: No module named middleware.request_id

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  I'm attempting to deploy openstack using chef. I'm using cookbook
  version 12.0 on the liberty deb repository and the os-compute-single-
  controller-no-network role. I'm having an issue where nova-api-os-
  compute is failing to start. Here is the stack trace.

  =2015-09-15 19:27:54.203 98118 WARNING keystonemiddleware.auth_token [-] Use 
of the auth_admin_prefix, auth_host, auth_port, auth_protocol, identity_uri, 
admin_token, admin_user, admin_password, and admin_tenant_name configuration 
options is deprecated in favor of auth_plugin and related options and may be 
removed in a future release.
  2015-09-15 19:27:54.204 98118 CRITICAL nova [-] ImportError: No module named 
middleware.request_id
  2015-09-15 19:27:54.204 98118 ERROR nova Traceback (most recent call last):
  2015-09-15 19:27:54.204 98118 ERROR nova   File 
"/usr/bin/nova-api-os-compute", line 10, in 
  2015-09-15 19:27:54.204 98118 ERROR nova sys.exit(main())
  2015-09-15 19:27:54.204 98118 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/nova/cmd/api_os_compute.py", line 45, in main
  2015-09-15 19:27:54.204 98118 ERROR nova server = 
service.WSGIService('osapi_compute', use_ssl=should_use_ssl)
  2015-09-15 19:27:54.204 98118 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/nova/service.py", line 322, in __init__
  2015-09-15 19:27:54.204 98118 ERROR nova self.app = 
self.loader.load_app(name)
  2015-09-15 19:27:54.204 98118 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/nova/wsgi.py", line 533, in load_app
  2015-09-15 19:27:54.204 98118 ERROR nova return 
deploy.loadapp("config:%s" % self.config_path, name=name)
  2015-09-15 19:27:54.204 98118 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 247, in 
loadapp
  2015-09-15 19:27:54.204 98118 ERROR nova return loadobj(APP, uri, 
name=name, **kw)
  2015-09-15 19:27:54.204 98118 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 272, in 
loadobj
  2015-09-15 19:27:54.204 98118 ERROR nova return context.create()
  2015-09-15 19:27:54.204 98118 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 710, in create
  2015-09-15 19:27:54.204 98118 ERROR nova return 
self.object_type.invoke(self)
  2015-09-15 19:27:54.204 98118 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 144, in invoke
  2015-09-15 19:27:54.204 98118 ERROR nova **context.local_conf)
  2015-09-15 19:27:54.204 98118 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/util.py", line 55, in fix_call
  2015-09-15 19:27:54.204 98118 ERROR nova val = callable(*args, **kw)
  2015-09-15 19:27:54.204 98118 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/nova/api/openstack/urlmap.py", line 160, in 
urlmap_factory
  2015-09-15 19:27:54.204 98118 ERROR nova app = loader.get_app(app_name, 
global_conf=global_conf)
  2015-09-15 19:27:54.204 98118 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 350, in 
get_app
  2015-09-15 19:27:54.204 98118 ERROR nova name=name, 
global_conf=global_conf).create()
  2015-09-15 19:27:54.204 98118 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 710, in create
  2015-09-15 19:27:54.204 98118 ERROR nova return 
self.object_type.invoke(self)
  2015-09-15 19:27:54.204 98118 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 144, in invoke
  2015-09-15 19:27:54.204 98118 ERROR nova **context.local_conf)
  2015-09-15 19:27:54.204 98118 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/util.py", line 55, in fix_call
  2015-09-15 19:27:54.204 98118 ERROR nova val = callable(*args, **kw)
  2015-09-15 19:27:54.204 98118 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/nova/api/auth.py", line 86, in 
pipeline_factory_v21
  2015-09-15 19:27:54.204 98118 ERROR nova return _load_pipeline(loader, 
local_conf[CONF.auth_strategy].split())
  2015-09-15 19:27:54.204 98118 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/nova/api/auth.py", line 60, in _load_pipeline
  2015-09-15 19:27:54.204 98118 ERROR nova filters = [loader.get_filter(n) 
for n in pipeline[:-1]]
  2015-09-15 19:27:54.204 98118 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 354, in 
get_filter
  2015-09-15 19:27:54.204 

[Yahoo-eng-team] [Bug 1483159] Re: Canonical naming for non-x86 architectures

[James Page]

** Changed in: nova
   Status: In Progress => 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/1483159

Title:
  Canonical naming for non-x86 architectures

Status in OpenStack Compute (nova):
  Invalid
Status in simplestreams:
  Fix Committed
Status in nova package in Ubuntu:
  Triaged

Bug description:
  Various non-x86 architectures (POWER and ARM) don't correctly
  canonicalize into things that libvirt natively understands.

  The attached patches normalizes some alternative architecture strings
  into standardized ones for Nova/libvirt.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1483159/+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 1496406] [NEW] Let RPC workers serve L3 queues too

[Eugene Nikanorov]

Public bug reported:

This is important for DVR clusters with lots of L3 agents.

Right now L3 queue is only consumed by parent process of neutron-server.

** Affects: neutron
 Importance: Undecided
 Assignee: Eugene Nikanorov (enikanorov)
 Status: New


** Tags: neutron-core

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

Title:
  Let RPC workers serve L3 queues too

Status in neutron:
  New

Bug description:
  This is important for DVR clusters with lots of L3 agents.

  Right now L3 queue is only consumed by parent process of neutron-
  server.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1496406/+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 1496394] [NEW] misleadingly named parameter in metadata_to_dict utility function

[Brian Rosmaita]

Public bug reported:

Apologies in advance for what's going to be a very long story for a
simple change in nova/utils.py.

Change b7e9a64416ff239a4c1b8501f398796b02c46ce7 introduces a
filter_deleted flag into the metadata_to_dict function.   The name
implies (to me anyway) that when the flag is False (as it is by
default), deleted items will NOT be filtered out of the dict returned by
the function.  However, that's not what happens: when
filter_deleted=False, deleted items ARE excluded.

Point 1: this is a naming issue, not a code issue.  Here's what we've got:
Original code: returns a dict of the non-deleted metadata.

def metadata_to_dict(metadata):
result = {}
for item in metadata:
if not item.get('deleted'):
   result[item['key']] = item['value']
   return result

Current code: adds a new parameter with a default value ... so you'd
expect the behavior with the default parameter setting to be the same as
the original function.

def metadata_to_dict(metadata, filter_deleted=False):
result = {}
for item in metadata:
if not filter_deleted and item.get('deleted'):
continue
result[item['key']] = item['value']
return result

Summary of Point 1:
If the default value is used, deleted items will not be included in the 
returned dict, so original behavior is preserved.
If filter_deleted=True is passed to the function, the 'if' will fail and 
deleted metadata will be included, which is new behavior.
Hence, the code is OK ... but it would be much clearer if the parameter were 
named 'include_deleted'.  See the next point for why this matters.

Point 2: the naming issue is important.

Three utility functions call the metadata_to_dict function:
(a) def instance_meta(instance) -> calls without setting the parameter, so no 
change in behavior: Correct
(b) def instance_sys_meta(instance) -> sets filter_deleted=True -> change in 
behavior (now includes deleted instance_system_metadata)
(c) def get_image_from_system_metadata(system_meta) -> sets filter_deleted=True 
-> change in behavior (now includes deleted instance_system_metadata)

The change in behavior for (b) and (c) is a breaking change for a
utility function, which is a bad practice.  I think what's going on is
that when the functions were changed to use the new function signature
for metadata_to_dict(), filter_deleted was set to True so that the
functions would filter out deleted stuff, thereby preserving their
original behavior.  But the opposite happened, namely, now they include
deleted stuff.  Actually, the intention doesn't matter here--a breaking
change to a utility function should not occur.  My real point is that
when you look at functions (b) and (c) in isolation, filter_deleted=True
appears to be what you'd want to pass to metadata_to_dict, whereas you
need to pass filter_deleted=False to get the correct behavior.

This bug:
All I want to do is rename filter_deleted in the function metadata_to_dict() to 
'include_deleted'.  (I'll file a separate bug to correct the utility functions 
that use the metadata_to_dict() function.)

References:
The function is here: 
https://github.com/openstack/nova/blob/a2d5492e8a15cdc13ada61b03f6293c709160505/nova/utils.py#L847-L853
The change was introduced by https://review.openstack.org/#/c/109201/
The change is b7e9a64416ff239a4c1b8501f398796b02c46ce7

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

Title:
  misleadingly named parameter in metadata_to_dict utility function

Status in OpenStack Compute (nova):
  New

Bug description:
  Apologies in advance for what's going to be a very long story for a
  simple change in nova/utils.py.

  Change b7e9a64416ff239a4c1b8501f398796b02c46ce7 introduces a
  filter_deleted flag into the metadata_to_dict function.   The name
  implies (to me anyway) that when the flag is False (as it is by
  default), deleted items will NOT be filtered out of the dict returned
  by the function.  However, that's not what happens: when
  filter_deleted=False, deleted items ARE excluded.

  Point 1: this is a naming issue, not a code issue.  Here's what we've got:
  Original code: returns a dict of the non-deleted metadata.

  def metadata_to_dict(metadata):
  result = {}
  for item in metadata:
if not item.get('deleted'):
   result[item['key']] = item['value']
 return result

  Current code: adds a new parameter with a default value ... so you'd
  expect the behavior with the default parameter setting to be the same
  as the original function.

  def metadata_to_dict(metadata, filter_deleted=False):
  result = {}
  for item in metadata:
  if not filter_deleted and item.get('deleted'):
  continue
  result[item['key']] = item['value']
  return result

  Summary of Point 

[Yahoo-eng-team] [Bug 1496417] [NEW] Inline edit checkbox value does not match cell value

[Justin Pomeroy]

Public bug reported:

This can be seen in the Projects table and the Metadata Definitions
table.  If you click the pencil to edit any of the Yes/No boolean
fields, the checkbox is always checked no matter the actual value of the
cell.  The checked state of the checkbox should match the value of the
cell.

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

Title:
  Inline edit checkbox value does not match cell value

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  This can be seen in the Projects table and the Metadata Definitions
  table.  If you click the pencil to edit any of the Yes/No boolean
  fields, the checkbox is always checked no matter the actual value of
  the cell.  The checked state of the checkbox should match the value of
  the cell.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1496417/+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 1496085] Re: network_data.json links can have None as MTU

[Mark Doffman]

https://blueprints.launchpad.net/neutron/+spec/mtu-selection-and-
advertisement

Blueprint for Neutron goes in to detail about how instances should get
the correct MTU value (Via DHCP or otherwise). If the MTU value is not
supplied for Neutron then the instance has no way of determining what
the correct MTU will be. The instance will use the default linux value,
which may or may not be correct. Setting to 1500 is not safe, and is no
better than using whatever the default linux value is.

Probably not a nova bug. MTU value should be broadcast by neutron if
having issues.

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

Title:
  network_data.json links can have None as MTU

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  If a Neutron network does not have an MTU set, the MTU for the links
  in network_data.json will be set to None. The spec seems to indicate
  all links will have an MTU. Either we should drop the key from the
  link if MTU isn't set, or set it to a safe default value like 1500.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1496085/+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 1461242] Re: cloud-init does not generate ed25519 keys

[Chris J Arges]

Hello Ben, or anyone else affected,

Accepted cloud-init into trusty-proposed. The package will build now and
be available at https://launchpad.net/ubuntu/+source/cloud-
init/0.7.5-0ubuntu1.11 in a few hours, and then in the -proposed
repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed.  Your feedback will aid us getting this update
out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-needed to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed.  In either case, details of your testing will help
us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

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

** Tags added: verification-needed

** Changed in: cloud-init (Ubuntu Utopic)
   Status: Confirmed => Invalid

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

Title:
  cloud-init does not generate ed25519 keys

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Trusty:
  Fix Committed
Status in cloud-init source package in Utopic:
  Invalid
Status in cloud-init source package in Vivid:
  Confirmed
Status in cloud-init source package in Wily:
  Fix Released

Bug description:
  Cloud-init does not generate ed25519 hosts keys as expected. Ubuntu
  14.04 and later have SSH configurations expecting ed25519 keys by
  default.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1461242/+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 1496424] [NEW] gate-neutron-python27(34)-constraints jobs blowing up in gate due to misconfig

[Matt Riedemann]

Public bug reported:

These look like new jobs but they are not working in the gate:

http://logs.openstack.org/13/223713/2/gate/gate-neutron-
python27-constraints/f3ea159/console.html#_2015-09-16_13_48_00_329

http://logs.openstack.org/13/223713/2/gate/gate-neutron-
python34-constraints/fd61c44/console.html#_2015-09-16_13_48_01_379

http://logstash.openstack.org/#eyJzZWFyY2giOiIobWVzc2FnZTpcIkVSUk9SOiB1bmtub3duIGVudmlyb25tZW50ICdweTI3LWNvbnN0cmFpbnRzJ1wiIE9SIG1lc3NhZ2U6XCJFUlJPUjogdW5rbm93biBlbnZpcm9ubWVudCAncHkzNC1jb25zdHJhaW50cydcIikgQU5EIHRhZ3M6XCJjb25zb2xlXCIgQU5EIHByb2plY3Q6XCJvcGVuc3RhY2svbmV1dHJvblwiIiwiZmllbGRzIjpbXSwib2Zmc2V0IjowLCJ0aW1lZnJhbWUiOiI2MDQ4MDAiLCJncmFwaG1vZGUiOiJjb3VudCIsInRpbWUiOnsidXNlcl9pbnRlcnZhbCI6MH0sInN0YW1wIjoxNDQyNDE0ODc4MDU5LCJtb2RlIjoiIiwiYW5hbHl6ZV9maWVsZCI6IiJ9

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

Title:
  gate-neutron-python27(34)-constraints jobs blowing up in gate due to
  misconfig

Status in neutron:
  New

Bug description:
  These look like new jobs but they are not working in the gate:

  http://logs.openstack.org/13/223713/2/gate/gate-neutron-
  python27-constraints/f3ea159/console.html#_2015-09-16_13_48_00_329

  http://logs.openstack.org/13/223713/2/gate/gate-neutron-
  python34-constraints/fd61c44/console.html#_2015-09-16_13_48_01_379

  
http://logstash.openstack.org/#eyJzZWFyY2giOiIobWVzc2FnZTpcIkVSUk9SOiB1bmtub3duIGVudmlyb25tZW50ICdweTI3LWNvbnN0cmFpbnRzJ1wiIE9SIG1lc3NhZ2U6XCJFUlJPUjogdW5rbm93biBlbnZpcm9ubWVudCAncHkzNC1jb25zdHJhaW50cydcIikgQU5EIHRhZ3M6XCJjb25zb2xlXCIgQU5EIHByb2plY3Q6XCJvcGVuc3RhY2svbmV1dHJvblwiIiwiZmllbGRzIjpbXSwib2Zmc2V0IjowLCJ0aW1lZnJhbWUiOiI2MDQ4MDAiLCJncmFwaG1vZGUiOiJjb3VudCIsInRpbWUiOnsidXNlcl9pbnRlcnZhbCI6MH0sInN0YW1wIjoxNDQyNDE0ODc4MDU5LCJtb2RlIjoiIiwiYW5hbHl6ZV9maWVsZCI6IiJ9

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1496424/+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 1496220] Re: error in setup command: Invalid environment marker: (python_version=='2.7' # MPL)

[Dolph Mathews]

This is neither a bug in keystone nor there a fix In Progress in
keystone.

** Project changed: keystone => pbr

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

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

Title:
  error in setup command: Invalid environment marker:
  (python_version=='2.7' # MPL)

Status in PBR:
  New

Bug description:
  https://review.openstack.org/#/c/222000/ introduced a change in 
keystone/setup.cfg:
  ---
  @@ -24,7 +24,7 @@ packages =
   [extras]
   ldap =
 python-ldap>=2.4:python_version=='2.7'
  -  ldappool>=1.0 # MPL
  +  ldappool>=1.0:python_version=='2.7' # MPL
   memcache =
 python-memcached>=1.56
   mongodb =
  -

  and CI failed with below error:
  --
  " error in setup command: Invalid environment marker: (python_version=='2.7' 
# MPL)"
  

  Seems there's something wrong with comment handling.

  This is similar to https://bugs.launchpad.net/pbr/+bug/1487835 but
  it's not the same.

  we should remove the '# ... ' comments

To manage notifications about this bug go to:
https://bugs.launchpad.net/pbr/+bug/1496220/+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 1496554] [NEW] bug in ipam_backend_mixin delete_port

[Aaron Rosen]

Public bug reported:

It's possible for a port to be deleted concurrently in which case here:

https://github.com/openstack/neutron/blob/master/neutron/db/ipam_backend_mixin.py#L417


None will be passed to context.session.delete() This results in this error 
being raised: 


http://logs.openstack.org/25/224225/2/check/gate-tempest-dsvm-networking-ovn/8719aa6/logs/screen-q-svc.txt.gz?level=TRACE#_2015-09-16_18_38_59_368

** Affects: neutron
 Importance: Undecided
 Assignee: Aaron Rosen (arosen)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) => Aaron Rosen (arosen)

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

Title:
  bug in ipam_backend_mixin delete_port

Status in neutron:
  New

Bug description:
  It's possible for a port to be deleted concurrently in which case
  here:

  
https://github.com/openstack/neutron/blob/master/neutron/db/ipam_backend_mixin.py#L417

  
  None will be passed to context.session.delete() This results in this error 
being raised: 

  
  
http://logs.openstack.org/25/224225/2/check/gate-tempest-dsvm-networking-ovn/8719aa6/logs/screen-q-svc.txt.gz?level=TRACE#_2015-09-16_18_38_59_368

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1496554/+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 1496553] [NEW] bug in ipam_backend_mixin delete_port

[Aaron Rosen]

Public bug reported:

It's possible for a port to be deleted concurrently in which case here:

https://github.com/openstack/neutron/blob/master/neutron/db/ipam_backend_mixin.py#L417


None will be passed to context.session.delete() This results in this error 
being raised: 


http://logs.openstack.org/25/224225/2/check/gate-tempest-dsvm-networking-ovn/8719aa6/logs/screen-q-svc.txt.gz?level=TRACE#_2015-09-16_18_38_59_368

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

Title:
  bug in ipam_backend_mixin delete_port

Status in neutron:
  New

Bug description:
  It's possible for a port to be deleted concurrently in which case
  here:

  
https://github.com/openstack/neutron/blob/master/neutron/db/ipam_backend_mixin.py#L417

  
  None will be passed to context.session.delete() This results in this error 
being raised: 

  
  
http://logs.openstack.org/25/224225/2/check/gate-tempest-dsvm-networking-ovn/8719aa6/logs/screen-q-svc.txt.gz?level=TRACE#_2015-09-16_18_38_59_368

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1496553/+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 1495887] Re: VMware driver:reconnection didn't work

[Davanum Srinivas (DIMS)]

** Project changed: nova => oslo.vmware

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

Title:
  VMware driver:reconnection didn't work

Status in oslo.vmware:
  New

Bug description:
  Detailed Process:
  1. nova-compute can not connect to rabbitMQ and nova-compute does not execute 
any regular task because of some reason. 
  2. the session will expire after a few hours.
  3. regular task collects nodes hardware info and fail
  4. nova-compute try to judge  session is active
  5._is_current_session_active will get faultmsg.
  6.when executing str(msg), msg is encoded by utf-8,  my vCenter is chinese 
version. so throw  UnicodeEncodeError
  7.reconnection will not work. Then we have to restart nova-compute

  Stack:
  TRACE oslo.vmware.api Traceback (most recent call last):
  TRACE oslo.vmware.api   File 
"/usr/lib/python2.7/site-packages/oslo/vmware/api.py", line 94, in _func
  TRACE oslo.vmware.api result = f(*args, **kwargs)
  TRACE oslo.vmware.api   File 
"/usr/lib/python2.7/site-packages/oslo/vmware/api.py", line 298, in _invoke_api
  TRACE oslo.vmware.api if self._is_current_session_active():
  TRACE oslo.vmware.api   File 
"/usr/lib/python2.7/site-packages/oslo/vmware/api.py", line 354, in 
_is_current_session_active
  TRACE oslo.vmware.api userName=self._session_username)
  TRACE oslo.vmware.api   File 
"/usr/lib/python2.7/site-packages/oslo/vmware/service.py", line 197, in 
request_handler
  TRACE oslo.vmware.api excep, details)
  TRACE oslo.vmware.api   File 
"/usr/lib/python2.7/site-packages/oslo/vmware/exceptions.py", line 81, in 
__init__
  TRACE oslo.vmware.api super(VimFaultException, self).__init__(message, 
cause)
  TRACE oslo.vmware.api   File 
"/usr/lib/python2.7/site-packages/oslo/vmware/exceptions.py", line 52, in 
__init__
  TRACE oslo.vmware.api self.msg = str(message)
  TRACE oslo.vmware.api UnicodeEncodeError: 'ascii' codec can't encode 
characters in position 0-10: ordinal not in range(128)

  Suggested Solution:
  when logging to vCenter, we set local to 'en'.  we will not encounter 
encode/decode problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oslo.vmware/+bug/1495887/+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 1496539] [NEW] Ceilometer dashboard send requests with redundant timestamp queries

[Ilya Tyaptin]

Public bug reported:

For requests with many resources horizon sends too many timestamp query for 
statistics request. It caused by incorrect using of mutable variable in next 
lines:
https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/ceilometer.py#L570

In this code we append data for existing resource.query list, what causes 
invalid requests.
 
Example: 
/v2/meters/network.outgoing.packets.rate/statistics?q.field=project_id=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=eq=ge=le=ge=le=ge=le=ge=le=ge=le=ge=le=ge=le=ge=le=ge=le=ge=le=ge=le=ge=le==bdc3e00de2ea4503bae975b7fc950c8b=2015-09-15+13:16:22.010352+00:00=2015-
 
09-16+13:16:22.010352+00:00=2015-09-15+13:16:25.877340+00:00=2015-09-16+13:16:25.877340+00:00=2015-09-16+12:24:49.708256+00:00=2015-09-16+13:24:49.708256+00:00=2015-08-31+13:24:52.704234+00:00=2015-09-16+13:24:52.704234+00:00=2015-08-31+13:24:59.378379+00:00=2015-09-16+13:24:59.378379+00:00=2015-08-31+13:25:06.624019+00:00=2015-09-16+13:25:06.624019+00:00=2015-09-15+13:25:08.039085+00:00=2015-09-16+13:25:08.039085+00:00=2015-09-16+13:26:05.604847+00:00=2015-09-16+14:26:05.604847+00:00=2015-09-16+13:26:08.275199+00:00=2015-09-16+14:26:08.275199+00:00=2015-09-09+14:31:20.469065+00:00=2015-09-16+14:31:20.469065+00:00=2015-09-09+14:31:36.214890+00:00=2015-09-16+14:31:36.214890+00:00=2015-09-09+14:32:37.745697+00:00=2015-09-16+14:32:37.745697+00:00=86400

** Affects: horizon
 Importance: Undecided
 Assignee: Ilya Tyaptin (ityaptin)
 Status: In Progress

** Changed in: horizon
 Assignee: (unassigned) => Ilya Tyaptin (ityaptin)

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

Title:
  Ceilometer dashboard send requests with redundant timestamp queries

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  For requests with many resources horizon sends too many timestamp query for 
statistics request. It caused by incorrect using of mutable variable in next 
lines:
  
https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/ceilometer.py#L570

  In this code we append data for existing resource.query list, what causes 
invalid requests.
   
  Example: 
  
/v2/meters/network.outgoing.packets.rate/statistics?q.field=project_id=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=timestamp=eq=ge=le=ge=le=ge=le=ge=le=ge=le=ge=le=ge=le=ge=le=ge=le=ge=le=ge=le=ge=le==bdc3e00de2ea4503bae975b7fc950c8b=2015-09-15+13:16:22.010352+00:00=201
 
5-09-16+13:16:22.010352+00:00=2015-09-15+13:16:25.877340+00:00=2015-09-16+13:16:25.877340+00:00=2015-09-16+12:24:49.708256+00:00=2015-09-16+13:24:49.708256+00:00=2015-08-31+13:24:52.704234+00:00=2015-09-16+13:24:52.704234+00:00=2015-08-31+13:24:59.378379+00:00=2015-09-16+13:24:59.378379+00:00=2015-08-31+13:25:06.624019+00:00=2015-09-16+13:25:06.624019+00:00=2015-09-15+13:25:08.039085+00:00=2015-09-16+13:25:08.039085+00:00=2015-09-16+13:26:05.604847+00:00=2015-09-16+14:26:05.604847+00:00=2015-09-16+13:26:08.275199+00:00=2015-09-16+14:26:08.275199+00:00=2015-09-09+14:31:20.469065+00:00=2015-09-16+14:31:20.469065+00:00=2015-09-09+14:31:36.214890+00:00=2015-09-16+14:31:36.214890+00:00=2015-09-09+14:32:37.745697+00:00=2015-09-16+14:32:37.745697+00:00=86400

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1496539/+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 1496530] [NEW] debug note in error response inaccurate

[Brant Knudson]

Public bug reported:

If I do a GET /v3/auth/tokens with no token and keystone is configured
with debug I get a message back saying I'm not authorized and to disable
debug mode to suppress details:

$ curl http://localhost:5000/v3/auth/tokens
{"error": {"message": "The request you have made requires authentication. 
(Disable debug mode to suppress these details.)", "code": 401, "title": 
"Unauthorized"}}


If I set debug=False, the message changes:

{"error": {"message": "The request you have made requires
authentication.", "code": 401, "title": "Unauthorized"}}


No details have been suppressed. The only difference is that the note about 
disabling debug mode has been removed. The message shouldn't be saying to 
disable debug mode to suppress details when there's no details to suppress.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: New

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

Title:
  debug note in error response inaccurate

Status in Keystone:
  New

Bug description:
  If I do a GET /v3/auth/tokens with no token and keystone is configured
  with debug I get a message back saying I'm not authorized and to
  disable debug mode to suppress details:

  $ curl http://localhost:5000/v3/auth/tokens
  {"error": {"message": "The request you have made requires authentication. 
(Disable debug mode to suppress these details.)", "code": 401, "title": 
"Unauthorized"}}

  
  If I set debug=False, the message changes:

  {"error": {"message": "The request you have made requires
  authentication.", "code": 401, "title": "Unauthorized"}}

  
  No details have been suppressed. The only difference is that the note about 
disabling debug mode has been removed. The message shouldn't be saying to 
disable debug mode to suppress details when there's no details to suppress.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1496530/+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 1496565] [NEW] Nova instance create fails when passing PCI alias

[Vik]

Public bug reported:

Running kilo master devstack on ubuntu 15.04. Created pci-whitelist and
alias in local.conf and is visible in nova.conf per
https://wiki.openstack.org/wiki/Pci_passthrough

Added PCI alias to a nova flavor. When lauching instance with that flavor, it 
fails saying alias not found.
n-api log attached

nova boot --image 0f586895-ea84-48ed-a527-0b2fcbe79d05  --flavor m1.small i1
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-03607684-2cf3-461e-97cc-2359a7a1c916)

>From local.conf
pci_passthrough_whitelist={ 
"vendor_id":"15b3","product_id":"1004","address":"0004:01:00.*", 
"physical_network":"physnet1"}
pci_alias={"vendor_id":"15b3", "product_id":"1004", "name":"m1"}


 nova flavor-show 2
++---+
| Property   | Value |
++---+
| OS-FLV-DISABLED:disabled   | False |
| OS-FLV-EXT-DATA:ephemeral  | 0 |
| disk   | 20|
| extra_specs| {"pci_passthrough:alias": "m1:1"} |
| id | 2 |
| name   | m1.small  |
| os-flavor-access:is_public | True  |
| ram| 2048  |
| rxtx_factor| 1.0   |
| swap   |   |
| vcpus  | 1 |


git log -1
commit 7594b100128bdd4f6397dacf8de4d4c3059f6bb3
Merge: 1d0b0d3 4b115ad
Author: Jenkins 
Date:   Thu Sep 3 22:24:40 2015 +

Merge "Convert identity defaults to keystone v3 api"

n-api
7050>>' _process_stack /opt/stack/nova/nova/api/openstack/wsgi.py:792
2015-09-16 19:34:40.597 INFO nova.osapi_compute.wsgi.server 
[req-c8f4dbbb-00c0-44a8-b4ce-ad9187c151e1 admin admin] 10.222.173.71 "GET 
/v2.1/012991f796ad4cbb92b9ff9b8b3bcbf1/flavors/2 HTTP/1.1" status: 200 len: 698 
time: 0.2890520
2015-09-16 19:34:40.647 DEBUG nova.api.openstack.wsgi 
[req-03607684-2cf3-461e-97cc-2359a7a1c916 admin admin] Action: 'create', 
calling method: >, 
body: {"server": {"min_count": 1, "flavorRef": "2", "name": "i1", "imageRef": 
"0f586895-ea84-48ed-a527-0b2fcbe79d05", "max_count": 1}} _process_stack 
/opt/stack/nova/nova/api/openstack/wsgi.py:789
2015-09-16 19:34:43.265 DEBUG nova.api.openstack.compute.servers 
[req-03607684-2cf3-461e-97cc-2359a7a1c916 admin admin] Running 
_create_extension_point for  _create_extension_point 
/opt/stack/nova/nova/api/openstack/compute/servers.py:686
2015-09-16 19:34:43.268 DEBUG nova.api.openstack.compute.servers 
[req-03607684-2cf3-461e-97cc-2359a7a1c916 admin admin] Running 
_create_extension_point for  _create_extension_point 
/opt/stack/nova/nova/api/openstack/compute/servers.py:686
2015-09-16 19:34:43.270 DEBUG nova.api.openstack.compute.servers 
[req-03607684-2cf3-461e-97cc-2359a7a1c916 admin admin] Running 
_create_extension_point for  _create_extension_point 
/opt/stack/nova/nova/api/openstack/compute/servers.py:686
2015-09-16 19:34:43.272 DEBUG nova.api.openstack.compute.servers 
[req-03607684-2cf3-461e-97cc-2359a7a1c916 admin admin] Running 
_create_extension_point for  _create_extension_point 
/opt/stack/nova/nova/api/openstack/compute/servers.py:686
2015-09-16 19:34:43.274 DEBUG nova.api.openstack.compute.servers 
[req-03607684-2cf3-461e-97cc-2359a7a1c916 admin admin] Running 
_create_extension_point for  _create_extension_point 
/opt/stack/nova/nova/api/openstack/compute/servers.py:686
2015-09-16 19:34:43.277 DEBUG nova.api.openstack.compute.servers 
[req-03607684-2cf3-461e-97cc-2359a7a1c916 admin admin] Running 
_create_extension_point for  _create_extension_point 
/opt/stack/nova/nova/api/openstack/compute/servers.py:686
2015-09-16 19:34:43.279 DEBUG nova.api.openstack.compute.servers 
[req-03607684-2cf3-461e-97cc-2359a7a1c916 admin admin] Running 
_create_extension_point for  _create_extension_point 
/opt/stack/nova/nova/api/openstack/compute/servers.py:686
2015-09-16 19:34:43.281 DEBUG nova.api.openstack.compute.servers 
[req-03607684-2cf3-461e-97cc-2359a7a1c916 admin admin] Running 
_create_extension_point for  _create_extension_point 
/opt/stack/nova/nova/api/openstack/compute/servers.py:686
2015-09-16 19:34:43.284 DEBUG nova.api.openstack.compute.servers 
[req-03607684-2cf3-461e-97cc-2359a7a1c916 admin admin] Running 
_create_extension_point for  _create_extension_point 
/opt/stack/nova/nova/api/openstack/compute/servers.py:686
2015-09-16 19:34:43.286 DEBUG nova.api.openstack.compute.servers 
[req-03607684-2cf3-461e-97cc-2359a7a1c916 admin admin] Running 
_create_extension_point 

[Yahoo-eng-team] [Bug 1479162] Re: Need a way to batch async requests

[Travis Tripp]

** Changed in: horizon
   Status: In Progress => Won't Fix

** Changed in: horizon
Milestone: liberty-rc1 => None

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

Title:
  Need a way to batch async requests

Status in OpenStack Dashboard (Horizon):
  Won't Fix

Bug description:
  In order to make multiple async calls in javascript, we need to nest
  them. This makes the code unreadable at some point. There is a better
  way to batch multiple async calls using defer and promises. This patch
  provides a way to batch async calls and handle it once ALL async calls
  are complete.

  Nesting example
  -
    keystoneAPI.getRoles(function(roles) {
  keystoneAPI.getUsers(function(roles) {
    settingAPI.getSetting('SETTING', 'default').then(function(settings){
    // do something here
  });
    });

  Batch example
  --
    var async = {
  keystone: keystoneAPI.getRoles(),
  keystone: keystoneAPI.getUsers(),
  settings: settingAPI.getSetting('SETTING', 'default')
    };
    httpBatch.batch(async).then(function(response) {
  // do something here
    });

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1479162/+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 1496586] [NEW] Avoid the pattern sql select/delete

[Cedric Brandily]

Public bug reported:

The following pattern:

 obj = query.filter(...).one()
 context.session.delete(obj)

 is racy because obj can be deleted between the select and the delete,
we should prefer when possible the pattern:

 count = query.filter(...).delete(synchronize_session=False)
 if not count:
   raise NotFound

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New


** Tags: db

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

Title:
  Avoid the pattern sql select/delete

Status in neutron:
  New

Bug description:
  The following pattern:

   obj = query.filter(...).one()
   context.session.delete(obj)

   is racy because obj can be deleted between the select and the delete,
  we should prefer when possible the pattern:

   count = query.filter(...).delete(synchronize_session=False)
   if not count:
 raise NotFound

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1496586/+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 1496557] [NEW] xenapi boot from volume is broken after move to ImageMeta object if volume passed in

[Andrew Laski]

Public bug reported:

When a request is made to boot an instance from a volume and a volume is
passed in as part of the request, rather than an image to have Nova
create a volume from, the image id is not passed down as part of the
build request.  The boot_meta dict created in compute/api.py does not
store an 'id' key/value in the dict so when it eventually gets down to
the virt layer and the dict is converted to an object the 'id' attribute
can not be accessed.  This causes a failure within the xenapi driver.

2015-09-16 13:02:00.481 24755 DEBUG nova.virt.xenapi.vmops 
[req-14839809--53d088b99b2d dbf01adba9b245369ba32a46d93fdf5f 5930474 - - -] 
[instance: 897942e0] Updating progress to 10 _update_instance_progress 
/opt/rackstack/rackstack.381.6/nova/lib/python2.7/site-packages/nova/virt/xenapi/vmops.py:1017
2015-09-16 13:02:00.696 24755 ERROR nova.utils [req-14839809--53d088b99b2d 
dbf01adba9b245369ba32a46d93fdf5f 5930474 - - -] [instance: 897942e0] Failed to 
spawn, rolling back
2015-09-16 13:02:00.696 24755 ERROR nova.utils [instance: 897942e0] Traceback 
(most recent call last):
2015-09-16 13:02:00.696 24755 ERROR nova.utils [instance: 897942e0]   File 
"/opt/rackstack/rackstack.381.6/nova/lib/python2.7/site-packages/nova/virt/xenapi/vmops.py",
 line 657, in _spawn
2015-09-16 13:02:00.696 24755 ERROR nova.utils [instance: 897942e0] 
name_label)
2015-09-16 13:02:00.696 24755 ERROR nova.utils [instance: 897942e0]   File 
"/opt/rackstack/rackstack.381.6/nova/lib/python2.7/site-packages/nova/virt/xenapi/vmops.py",
 line 212, in inner
2015-09-16 13:02:00.696 24755 ERROR nova.utils [instance: 897942e0] rv = 
f(*args, **kwargs)
2015-09-16 13:02:00.696 24755 ERROR nova.utils [instance: 897942e0]   File 
"/opt/rackstack/rackstack.381.6/nova/lib/python2.7/site-packages/nova/virt/xenapi/vmops.py",
 line 492, in create_disks_step
2015-09-16 13:02:00.696 24755 ERROR nova.utils [instance: 897942e0] 
image_meta.id, disk_image_type,
2015-09-16 13:02:00.696 24755 ERROR nova.utils [instance: 897942e0]   File 
"/opt/rackstack/rackstack.381.6/nova/lib/python2.7/site-packages/oslo_versionedobjects/base.py",
 line 66, in getter
2015-09-16 13:02:00.696 24755 ERROR nova.utils [instance: 897942e0] 
self.obj_load_attr(name)
2015-09-16 13:02:00.696 24755 ERROR nova.utils [instance: 897942e0]   File 
"/opt/rackstack/rackstack.381.6/nova/lib/python2.7/site-packages/oslo_versionedobjects/base.py",
 line 555, in obj_load_attr
2015-09-16 13:02:00.696 24755 ERROR nova.utils [instance: 897942e0] 
_("Cannot load '%s' in the base class") % attrname)
2015-09-16 13:02:00.696 24755 ERROR nova.utils [instance: 897942e0] 
NotImplementedError: Cannot load 'id' in the base class
2015-09-16 13:02:00.696 24755 ERROR nova.utils [instance: 897942e0]

** Affects: nova
 Importance: Undecided
 Assignee: Andrew Laski (alaski)
 Status: In Progress

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

Title:
  xenapi boot from volume is broken after move to ImageMeta object if
  volume passed in

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  When a request is made to boot an instance from a volume and a volume
  is passed in as part of the request, rather than an image to have Nova
  create a volume from, the image id is not passed down as part of the
  build request.  The boot_meta dict created in compute/api.py does not
  store an 'id' key/value in the dict so when it eventually gets down to
  the virt layer and the dict is converted to an object the 'id'
  attribute can not be accessed.  This causes a failure within the
  xenapi driver.

  2015-09-16 13:02:00.481 24755 DEBUG nova.virt.xenapi.vmops 
[req-14839809--53d088b99b2d dbf01adba9b245369ba32a46d93fdf5f 5930474 - - -] 
[instance: 897942e0] Updating progress to 10 _update_instance_progress 
/opt/rackstack/rackstack.381.6/nova/lib/python2.7/site-packages/nova/virt/xenapi/vmops.py:1017
  2015-09-16 13:02:00.696 24755 ERROR nova.utils [req-14839809--53d088b99b2d 
dbf01adba9b245369ba32a46d93fdf5f 5930474 - - -] [instance: 897942e0] Failed to 
spawn, rolling back
  2015-09-16 13:02:00.696 24755 ERROR nova.utils [instance: 897942e0] Traceback 
(most recent call last):
  2015-09-16 13:02:00.696 24755 ERROR nova.utils [instance: 897942e0]   File 
"/opt/rackstack/rackstack.381.6/nova/lib/python2.7/site-packages/nova/virt/xenapi/vmops.py",
 line 657, in _spawn
  2015-09-16 13:02:00.696 24755 ERROR nova.utils [instance: 897942e0] 
name_label)
  2015-09-16 13:02:00.696 24755 ERROR nova.utils [instance: 897942e0]   File 
"/opt/rackstack/rackstack.381.6/nova/lib/python2.7/site-packages/nova/virt/xenapi/vmops.py",
 line 212, in inner
  2015-09-16 13:02:00.696 24755 ERROR nova.utils [instance: 897942e0] rv = 
f(*args, **kwargs)
  2015-09-16 13:02:00.696 24755 ERROR nova.utils [instance: 897942e0]   File 

[Yahoo-eng-team] [Bug 1496593] [NEW] Extend Volume dialog asks for new size (instead of the "delta" change to extend) and accepts negatives values as input

[Launchpad Bug Tracker]

You have been subscribed to a public bug:

The Extend Volume panel from the Projects section in horizon seems to have a 
couple related non-intuitive behaviors. 
1. Since the action is extend volume, I expected to provide how much I want to 
"extend" the volume by but instead the panel expects me to specify the new 
total size. 
2. The new size allows for negative numbers as input. If I specify a negative 
number, it does give me a message that the new size must be greater than the 
current size. It would be better if we just did not allow invalid input to 
begin with.

** Affects: horizon
 Importance: Undecided
 Status: New

-- 
Extend Volume dialog asks for new size (instead of the "delta" change to 
extend)  and accepts negatives values as input
https://bugs.launchpad.net/bugs/1496593
You received this bug notification because you are a member of Yahoo! 
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).

-- 
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 1496593] [NEW] Extend Volume dialog asks for new size (instead of the "delta" change to extend) and accepts negatives values as input

[Neela Shah]

Public bug reported:

The Extend Volume panel from the Projects section in horizon seems to have a 
couple related non-intuitive behaviors. 
1. Since the action is extend volume, I expected to provide how much I want to 
"extend" the volume by but instead the panel expects me to specify the new 
total size. 
2. The new size allows for negative numbers as input. If I specify a negative 
number, it does give me a message that the new size must be greater than the 
current size. It would be better if we just did not allow invalid input to 
begin with.

** Affects: horizon
 Importance: Undecided
 Status: New

** Project changed: bagpipe-l2 => horizon

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

Title:
  Extend Volume dialog asks for new size (instead of the "delta" change
  to extend)  and accepts negatives values as input

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  The Extend Volume panel from the Projects section in horizon seems to have a 
couple related non-intuitive behaviors. 
  1. Since the action is extend volume, I expected to provide how much I want 
to "extend" the volume by but instead the panel expects me to specify the new 
total size. 
  2. The new size allows for negative numbers as input. If I specify a negative 
number, it does give me a message that the new size must be greater than the 
current size. It would be better if we just did not allow invalid input to 
begin with.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1496593/+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 1496610] [NEW] Access and Security API access tab doesn't reflect keystone v3 auth url

[Dan Nguyen]

Public bug reported:

Desc:
-
The Access and Security API access tab in Horizon is currently located: 
http:///project/access_and_security/
The table displays services and corresponding service endpoints.

The Identity row shows the endpoint from the keystone catalog in the
session which only contains v2 regardless of what horizon has currently
configured in local_settings.py

This effects both the view rendered on the page and the download openrc
option.

Proposed fix:

Replace this value with what is set in horizon's local_settings.py

** Affects: horizon
 Importance: Undecided
 Assignee: Dan Nguyen (daniel-a-nguyen)
 Status: New

** Changed in: horizon
 Assignee: (unassigned) => Dan Nguyen (daniel-a-nguyen)

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

Title:
  Access and Security API access tab doesn't reflect keystone v3 auth
  url

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Desc:
  -
  The Access and Security API access tab in Horizon is currently located: 
http:///project/access_and_security/
  The table displays services and corresponding service endpoints.

  The Identity row shows the endpoint from the keystone catalog in the
  session which only contains v2 regardless of what horizon has
  currently configured in local_settings.py

  This effects both the view rendered on the page and the download
  openrc option.

  Proposed fix:
  
  Replace this value with what is set in horizon's local_settings.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1496610/+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 1496578] [NEW] SNAT port not found for the given internal port error message seen when gateway is removed for DVR routers.

[Swaminathan Vasudevan]

Public bug reported:

Recently the logstash logs showed traces about "SNAT port not found for
the given internal port".

http://logs.openstack.org/22/219422/13/check/gate-tempest-dsvm-neutron-
dvr/e5243b2/logs/screen-q-l3.txt.gz?level=TRACE#_2015-09-15_12_28_08_880

By analyzing the failure it seems when a gateway is removed, the
"get_snat_port_for_internal_port" is called without the cache value.

This bug was introduced by the patch shown below.

Icc099c1a97e3e68eeaf4690bc83167ba30d8099a

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


** Tags: l3-dvr-backlog

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

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

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

Title:
  SNAT port not found for the given internal port error message seen
  when gateway is removed for DVR routers.

Status in neutron:
  In Progress

Bug description:
  Recently the logstash logs showed traces about "SNAT port not found
  for the given internal port".

  http://logs.openstack.org/22/219422/13/check/gate-tempest-dsvm-
  neutron-
  dvr/e5243b2/logs/screen-q-l3.txt.gz?level=TRACE#_2015-09-15_12_28_08_880

  By analyzing the failure it seems when a gateway is removed, the
  "get_snat_port_for_internal_port" is called without the cache value.

  This bug was introduced by the patch shown below.

  Icc099c1a97e3e68eeaf4690bc83167ba30d8099a

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1496578/+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 1494819] Re: Russian strings for Actions within Project->Instances page 'More Actions' dropdown are missing

[Doug Fish]

I'm _certain_ this problem is caused by the strange plurality count. I
can make this work by editing the Russian PO file

cd openstack_dashboard/locale/ru/LC_MESSAGES
cp django.po django.po-tmp
grep -v msgstr.2. django.po-tmp > django.po
sed -i s/msgstr.3./msgstr[2]/ django.po

and edit the plurality function to be
"Plural-Forms: nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n"
"%10<=4 && (n%100<12 || n%100>14) ? 1 : 2);\n"

recompile the catalog
./run_tests.sh —compilemessages


** Also affects: openstack-i18n
   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/1494819

Title:
  Russian strings for Actions within Project->Instances page 'More
  Actions' dropdown are missing

Status in OpenStack Dashboard (Horizon):
  Confirmed
Status in openstack i18n:
  New

Bug description:
  The same page translated to other languages where unicode is used
  (Serbian, Japanese) looks ok.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1494819/+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 1496627] [NEW] hz-magic-search-bar does not honor isServer property

[Travis Tripp]

Public bug reported:

If you set a facet as isServer, smart table filtering will still be
done.  In the case of wildcards or more advanced searching that is done
on the server side which requires server logic, the client side
filtering may subsequently wipe out a server response, potentially
hiding results.

The culprit is that hz-magic-search-bar wraps st-magic-search.  st-
magic-search is doing the client side filtering here regardless of the
isServer property.

https://github.com/openstack/horizon/blob/master/horizon/static/framework/widgets
/magic-search/st-magic-search.directive.js#L100

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

Title:
  hz-magic-search-bar does not honor isServer property

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  If you set a facet as isServer, smart table filtering will still be
  done.  In the case of wildcards or more advanced searching that is
  done on the server side which requires server logic, the client side
  filtering may subsequently wipe out a server response, potentially
  hiding results.

  The culprit is that hz-magic-search-bar wraps st-magic-search.  st-
  magic-search is doing the client side filtering here regardless of the
  isServer property.

  
https://github.com/openstack/horizon/blob/master/horizon/static/framework/widgets
  /magic-search/st-magic-search.directive.js#L100

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1496627/+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 1496650] Re: requirement conflict on Babel

[Kevin Benton]

happens during a keystone call so keystone might be affected:
http://logs.openstack.org/37/224337/4/check/gate-grenade-dsvm-
neutron/d0d019a/logs/grenade.sh.txt.gz#_2015-09-17_00_51_25_124

** 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 Keystone.
https://bugs.launchpad.net/bugs/1496650

Title:
  requirement conflict on Babel

Status in grenade:
  New
Status in Keystone:
  New

Bug description:
  message:"pkg_resources.ContextualVersionConflict: (Babel 2.0
  (/usr/local/lib/python2.7/dist-packages),
  Requirement.parse('Babel<=1.3,>=1.3'), set(['oslo.utils']))"

  
http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwicGtnX3Jlc291cmNlcy5Db250ZXh0dWFsVmVyc2lvbkNvbmZsaWN0OiAoQmFiZWwgMi4wICgvdXNyL2xvY2FsL2xpYi9weXRob24yLjcvZGlzdC1wYWNrYWdlcyksIFJlcXVpcmVtZW50LnBhcnNlKCdCYWJlbDw9MS4zLD49MS4zJyksIHNldChbJ29zbG8udXRpbHMnXSkpXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjE3MjgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0NDI0NTE2OTc3ODl9

To manage notifications about this bug go to:
https://bugs.launchpad.net/grenade/+bug/1496650/+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 1246485] Re: non-persistent hostname is the 'short' hostname

[Chirag Arora]

I was trying to check the patch files and mistakenly made the status
change. I apologize in advance.

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

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

Title:
  non-persistent hostname is the 'short' hostname

Status in cloud-init:
  Fix Released

Bug description:
  Distro.set_hostname() uses wrong hostname when calling
  _apply_hostname().

  On initial boot, the hostname is set to the short name, but after
  reboot it's set to the fqdn.

  I happen to be using openstack(config_drive, or metadata) on
  RHEL(technically OEL6u3)  however I don't think that matters much
  here.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1246485/+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 1488311] Re: import task still in progress although there occured an error

[wangxiyuan]

the same bug : https://bugs.launchpad.net/glance/+bug/1495519

** Changed in: glance
   Status: In Progress => Invalid

** Changed in: glance
 Assignee: wangxiyuan (wangxiyuan) => (unassigned)

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

Title:
  import task still in progress although there occured an error

Status in Glance:
  Invalid

Bug description:
  Reproduce:
  Create a import task like:
  {
  "type":"import",
  "input":{
  "import_from":"file://wrong_address", #1. wrong image address

# 2.lack of "import_from_format" , or even "import_from",  
"image_properties"
  "image_properties":{
  "disk_format":"qcow2",
  "container_format":"bare",
  "name":"test-task1"
  }
  }
  }

  It will return an error :
  1. URLError: 
  2. Invalid: Input does not contain 'import_from_format' field

  But  command  'glance task-show task_id'  : return that the task
  status still in progress and will never be chaned.

  Expect result  :  Task status is changed into failure.

  The reason is that glance only checked the parameters before taskflow
  start, but didn't  do any dispose about task status.

  As in taskflow, it has checked the parameters already, we could remove
  the checking before  the taskflow.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1488311/+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 1496650] Re: requirement conflict on Babel

[Sachi King]

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

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

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

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

Title:
  requirement conflict on Babel

Status in grenade:
  Invalid
Status in Keystone:
  Invalid
Status in oslo.utils:
  New

Bug description:
  message:"pkg_resources.ContextualVersionConflict: (Babel 2.0
  (/usr/local/lib/python2.7/dist-packages),
  Requirement.parse('Babel<=1.3,>=1.3'), set(['oslo.utils']))"

  
http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwicGtnX3Jlc291cmNlcy5Db250ZXh0dWFsVmVyc2lvbkNvbmZsaWN0OiAoQmFiZWwgMi4wICgvdXNyL2xvY2FsL2xpYi9weXRob24yLjcvZGlzdC1wYWNrYWdlcyksIFJlcXVpcmVtZW50LnBhcnNlKCdCYWJlbDw9MS4zLD49MS4zJyksIHNldChbJ29zbG8udXRpbHMnXSkpXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjE3MjgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0NDI0NTE2OTc3ODl9

To manage notifications about this bug go to:
https://bugs.launchpad.net/grenade/+bug/1496650/+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 1496650] Re: requirement conflict on Babel

[Armando Migliaccio]

Makes sense. I only looked at the surface.

** No longer affects: grenade

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

Title:
  requirement conflict on Babel

Status in Keystone:
  Invalid
Status in oslo.utils:
  New

Bug description:
  message:"pkg_resources.ContextualVersionConflict: (Babel 2.0
  (/usr/local/lib/python2.7/dist-packages),
  Requirement.parse('Babel<=1.3,>=1.3'), set(['oslo.utils']))"

  
http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwicGtnX3Jlc291cmNlcy5Db250ZXh0dWFsVmVyc2lvbkNvbmZsaWN0OiAoQmFiZWwgMi4wICgvdXNyL2xvY2FsL2xpYi9weXRob24yLjcvZGlzdC1wYWNrYWdlcyksIFJlcXVpcmVtZW50LnBhcnNlKCdCYWJlbDw9MS4zLD49MS4zJyksIHNldChbJ29zbG8udXRpbHMnXSkpXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjE3MjgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0NDI0NTE2OTc3ODl9

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1496650/+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 1472999] Re: filter doesn't handle unicode charaters

[Richard Jones]

Fix for nova https://review.openstack.org/#/c/224431/

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

** Changed in: nova
 Assignee: (unassigned) => Richard Jones (r1chardj0n3s)

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

Title:
  filter doesn't handle unicode charaters

Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Compute (nova):
  New
Status in python-glanceclient:
  New
Status in python-novaclient:
  In Progress

Bug description:
  1 go to project/instances
  2. insert 'ölk' into filter field
  3. enter filter
  4. 
  UnicodeEncodeError at /project/instances/

  'ascii' codec can't encode character u'\xf6' in position 0: ordinal
  not in range(128)

  Request Method:   GET
  Request URL:  http://localhost:8000/project/instances/
  Django Version:   1.8.2
  Exception Type:   UnicodeEncodeError
  Exception Value:  

  'ascii' codec can't encode character u'\xf6' in position 0: ordinal
  not in range(128)

  Exception Location:   /usr/lib64/python2.7/urllib.py in urlencode, line 1347
  Python Executable:/usr/bin/python
  Python Version:   2.7.10
  Python Path:  

  ['/home/mrunge/work/horizon',
   '/usr/lib64/python27.zip',
   '/usr/lib64/python2.7',
   '/usr/lib64/python2.7/plat-linux2',
   '/usr/lib64/python2.7/lib-tk',
   '/usr/lib64/python2.7/lib-old',
   '/usr/lib64/python2.7/lib-dynload',
   '/usr/lib64/python2.7/site-packages',
   '/usr/lib64/python2.7/site-packages/gtk-2.0',
   '/usr/lib/python2.7/site-packages',
   '/home/mrunge/work/horizon/openstack_dashboard']

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1472999/+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 1493270] Re: The dependency of pbr in ryu does not match neutron

[Hong Hui Xiao]

Checked that ryu has updated its dependency of pbr, due to this patch
https://github.com/osrg/ryu/commit/992bf7318d06090cc96a21521dbeba62f148d079

Close this bug.

** Changed in: neutron
   Status: New => 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/1493270

Title:
  The dependency of pbr in ryu does not match neutron

Status in neutron:
  Fix Released

Bug description:
  I want to use neutron with latest code. In the [1], ryu was added as
  dependency for neutron. However, when I want to install ryu.  I got
  this error.

  [root@test]# pip install ryu
  Downloading/unpacking ryu
Downloading ryu-3.25.tar.gz (1.3MB): 1.3MB downloaded
Running setup.py egg_info for package ryu
  Traceback (most recent call last):
File "", line 16, in 
File "/tmp/pip_build_root/ryu/setup.py", line 30, in 
  pbr=True)
File "/usr/lib64/python2.7/distutils/core.py", line 112, in setup
  _setup_distribution = dist = klass(attrs)
File "/usr/lib/python2.7/site-packages/setuptools/dist.py", line 265, 
in __init__
  self.fetch_build_eggs(attrs.pop('setup_requires'))
File "/usr/lib/python2.7/site-packages/setuptools/dist.py", line 289, 
in fetch_build_eggs
  parse_requirements(requires), installer=self.fetch_build_egg
File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 630, in 
resolve
  raise VersionConflict(dist,req) # XXX put more info here
  pkg_resources.VersionConflict: (pbr 1.6.0 
(/usr/lib/python2.7/site-packages), Requirement.parse('pbr<1.0'))

  And I can find from [2] that ryu will need pbr < 1.0
  But in my env, the pbr was installed with a newer version. According to [3]. 


  [1] https://review.openstack.org/#/c/153946/136/requirements.txt
  [2] https://github.com/osrg/ryu/blob/master/setup.py#L29
  [3] https://github.com/openstack/neutron/blob/master/requirements.txt#L4

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1493270/+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 1496679] [NEW] Need to translate '-' for non-values in angular HTML

[Travis Tripp]

Public bug reported:

The empty value of '-' needs to be translated.
This adds a filter that can accomplish this and updates existing angular html 
that used the || '-'


To test:

In local_settings.py

LAUNCH_INSTANCE_NG_ENABLED = True

update enabled/_1051_project_ng_images_panel.py
update enabled/_3031_identity_users_panel.py

set disabled=False

Then:
./run_tests.sh --makemessages
./run_tests.sh --pseudo de
./run_tests.sh --compilemessages
./run_tests.sh --runserver 0.0.0.0:8005

Go to: http://localhost:8005/settings/

Change Language to Deutsch (de)

Go to:
 http://localhost:8005/project/ngimages/
 http://localhost:8005/project/ngusers/

Launch an instance.
Go to security groups step.
Expand details for a security group.

All text on page should be fake localized where the english
is surrounded by other characters.
[~-~KanjiChars]

** Affects: horizon
 Importance: Undecided
 Assignee: Travis Tripp (travis-tripp)
 Status: In Progress

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

Title:
  Need to translate '-' for non-values in angular HTML

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  The empty value of '-' needs to be translated.
  This adds a filter that can accomplish this and updates existing angular html 
that used the || '-'

  
  To test:

  In local_settings.py

  LAUNCH_INSTANCE_NG_ENABLED = True

  update enabled/_1051_project_ng_images_panel.py
  update enabled/_3031_identity_users_panel.py

  set disabled=False

  Then:
  ./run_tests.sh --makemessages
  ./run_tests.sh --pseudo de
  ./run_tests.sh --compilemessages
  ./run_tests.sh --runserver 0.0.0.0:8005

  Go to: http://localhost:8005/settings/

  Change Language to Deutsch (de)

  Go to:
   http://localhost:8005/project/ngimages/
   http://localhost:8005/project/ngusers/

  Launch an instance.
  Go to security groups step.
  Expand details for a security group.

  All text on page should be fake localized where the english
  is surrounded by other characters.
  [~-~KanjiChars]

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1496679/+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 1496664] [NEW] V2.1 comp mode behavior should be fixed for diff of v2 and v2.1 APIs

[Ghanshyam Mann]

Public bug reported:

There are some cases where v2.1 is different than v2.0 -
- VIF API  - no net-id in v2.1
- rate limit bits - not present in v2.1
- extension info - namespace diff


For above cases,  current v2.1 compatible mode behaves same as  v2.1 not v2. 
Failure in - 
http://logs.openstack.org/86/224386/1/check/gate-nova-tox-functional/b98e535/testr_results.html.gz

As v2.1 comp mode should behave same as v2 instead of v2.1, we should
fix those cases to return same response as v2 APIs does.

I am not sure about rate limit and extension info things, should we fix
those?

It was found when we start running v2.1 comp mode sample test against v2
sample files instead of v2.1 one. -
https://review.openstack.org/#/c/224386/

** Affects: nova
 Importance: Undecided
 Assignee: Ghanshyam Mann (ghanshyammann)
 Status: New

** Changed in: nova
 Assignee: (unassigned) => Ghanshyam Mann (ghanshyammann)

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

Title:
  V2.1 comp mode behavior should be fixed for diff of v2 and v2.1 APIs

Status in OpenStack Compute (nova):
  New

Bug description:
  There are some cases where v2.1 is different than v2.0 -
  - VIF API  - no net-id in v2.1
  - rate limit bits - not present in v2.1
  - extension info - namespace diff

  
  For above cases,  current v2.1 compatible mode behaves same as  v2.1 not v2. 
  Failure in - 
http://logs.openstack.org/86/224386/1/check/gate-nova-tox-functional/b98e535/testr_results.html.gz

  As v2.1 comp mode should behave same as v2 instead of v2.1, we should
  fix those cases to return same response as v2 APIs does.

  I am not sure about rate limit and extension info things, should we
  fix those?

  It was found when we start running v2.1 comp mode sample test against
  v2 sample files instead of v2.1 one. -
  https://review.openstack.org/#/c/224386/

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1496664/+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 1496495] [NEW] breaking change to utility functions

[Brian Rosmaita]

Public bug reported:

Change b7e9a64416ff239a4c1b8501f398796b02c46ce7 introduces a
filter_deleted flag into the metadata_to_dict function in nova/utils.py
and modified two utility functions to use this flag.  Unfortunately, the
value passed makes these utility functions behave differently:

def instance_sys_meta(instance) -> sets filter_deleted=True -> change in
behavior (now includes deleted instance_system_metadata)

def get_image_from_system_metadata(system_meta) -> sets
filter_deleted=True -> change in behavior (now includes deleted
instance_system_metadata)

It's never a good idea to change the expected behavior of utility
functions.  I propose to fix this as follows:

(1) Fix bug #1496394, which will change the name of the flag from
'filter_deleted' to 'include_deleted' in the base function so hopefully
this problem won't happen again.

(2) Change the signatures of the two functions mentioned above to have
an optional 'include_deleted' parameter whose default setting will
preserve the original behavior of these functions.

(3) The change that introduced the flag was made to support the display
of metadata on deleted instances for server-detail-list calls using the
changes_since parameter, so check usage of the utility functions and
include passing the 'include_deleted' parameter if appropriate.

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

Title:
  breaking change to utility functions

Status in OpenStack Compute (nova):
  New

Bug description:
  Change b7e9a64416ff239a4c1b8501f398796b02c46ce7 introduces a
  filter_deleted flag into the metadata_to_dict function in
  nova/utils.py and modified two utility functions to use this flag.
  Unfortunately, the value passed makes these utility functions behave
  differently:

  def instance_sys_meta(instance) -> sets filter_deleted=True -> change
  in behavior (now includes deleted instance_system_metadata)

  def get_image_from_system_metadata(system_meta) -> sets
  filter_deleted=True -> change in behavior (now includes deleted
  instance_system_metadata)

  It's never a good idea to change the expected behavior of utility
  functions.  I propose to fix this as follows:

  (1) Fix bug #1496394, which will change the name of the flag from
  'filter_deleted' to 'include_deleted' in the base function so
  hopefully this problem won't happen again.

  (2) Change the signatures of the two functions mentioned above to have
  an optional 'include_deleted' parameter whose default setting will
  preserve the original behavior of these functions.

  (3) The change that introduced the flag was made to support the
  display of metadata on deleted instances for server-detail-list calls
  using the changes_since parameter, so check usage of the utility
  functions and include passing the 'include_deleted' parameter if
  appropriate.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1496495/+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 1496512] Re: Misplaced memcache servers in keystone config cause token loss

[Alexander Makarov]

master: https://review.fuel-infra.org/#/c/11662/
7.0: https://review.fuel-infra.org/#/c/8189


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

** Changed in: keystone
 Assignee: (unassigned) => Alexander Makarov (amakarov)

** No longer affects: keystone

** Also affects: mos/7.0.x
   Importance: Undecided
   Status: New

** Changed in: mos/7.0.x
   Status: New => Fix Committed

** Changed in: mos/7.0.x
 Assignee: (unassigned) => Alexander Makarov (amakarov)

** Changed in: mos/7.0.x
Milestone: None => 7.0

** Changed in: mos/7.0.x
   Importance: Undecided => Critical

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

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

Title:
  Misplaced memcache servers in keystone config cause token loss

Status in Mirantis OpenStack:
  In Progress
Status in Mirantis OpenStack 7.0.x series:
  Fix Committed

Bug description:
  If memcache servers specified in [cache] section of keystone config
  are enumerated in different order on cloud controllers, tokens fail to
  validate as keystone searches the wrong memcache server if token issue
  and validation occur on different controllers.

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