[Yahoo-eng-team] [Bug 1423900] [NEW] Don't try to query dbus if the credentials are in the environment variables

2015-02-20 Thread Arthur Lutz (Logilab) 
Public bug reported:

I use nova with credentials as environment variables, and was suprised
to get the following traceback :

# nova list
Traceback (most recent call last):
  File "/usr/bin/nova", line 6, in 
from novaclient.shell import main
  File "/usr/lib/python2.7/dist-packages/novaclient/shell.py", line 38, in 

import keyring
  File "/usr/lib/python2.7/dist-packages/keyring/__init__.py", line 12, in 

from .core import (set_keyring, get_keyring, set_password, get_password,
  File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 180, in 
init_backend()
  File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 59, in 
init_backend
set_keyring(load_config() or _get_best_keyring())
  File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 67, in 
_get_best_keyring
keyrings = backend.get_all_keyring()
  File "/usr/lib/python2.7/dist-packages/keyring/util/__init__.py", line 24, in 
wrapper
func.always_returns = func(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/keyring/backend.py", line 127, in 
get_all_keyring
exceptions=TypeError))
  File "/usr/lib/python2.7/dist-packages/keyring/util/__init__.py", line 35, in 
suppress_exceptions
for callable in callables:
  File "/usr/lib/python2.7/dist-packages/keyring/backend.py", line 119, in 
is_class_viable
keyring_cls.priority
  File "/usr/lib/python2.7/dist-packages/keyring/util/properties.py", line 22, 
in __get__
return self.fget.__get__(None, owner)()
  File "/usr/lib/python2.7/dist-packages/keyring/util/XDG.py", line 18, in 
wrapper
return func(*args, **kwargs) * self.multiplier
  File "/usr/lib/python2.7/dist-packages/keyring/backends/SecretService.py", 
line 32, in priority
list(secretstorage.get_all_collections(bus))
  File "/usr/lib/python2.7/dist-packages/secretstorage/collection.py", line 
158, in get_all_collections
service_obj = bus_get_object(bus, SECRETS, SS_PATH)
  File "/usr/lib/python2.7/dist-packages/secretstorage/util.py", line 50, in 
bus_get_object
return bus.get_object(name, object_path, introspect=False)
  File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 241, in get_object
follow_name_owner_changes=follow_name_owner_changes)
  File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 248, in __init__
self._named_service = conn.activate_name_owner(bus_name)
  File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 180, in 
activate_name_owner
self.start_service_by_name(bus_name)
  File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 278, in 
start_service_by_name
'su', (bus_name, flags)))
  File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in 
call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.TimedOut: Activation 
of org.freedesktop.secrets timed out

This might be an explanation of why my nova commands have been slugish
lately. Would it be possible for nova not to try dbus if it finds the
credentials in the environment ?

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

Title:
  Don't try to query dbus if the credentials are in the environment
  variables

Status in OpenStack Compute (Nova):
  New

Bug description:
  I use nova with credentials as environment variables, and was suprised
  to get the following traceback :

  # nova list
  Traceback (most recent call last):
File "/usr/bin/nova", line 6, in 
  from novaclient.shell import main
File "/usr/lib/python2.7/dist-packages/novaclient/shell.py", line 38, in 

  import keyring
File "/usr/lib/python2.7/dist-packages/keyring/__init__.py", line 12, in 

  from .core import (set_keyring, get_keyring, set_password, get_password,
File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 180, in 

  init_backend()
File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 59, in 
init_backend
  set_keyring(load_config() or _get_best_keyring())
File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 67, in 
_get_best_keyring
  keyrings = backend.get_all_keyring()
File "/usr/lib/python2.7/dist-packages/keyring/util/__init__.py", line 24, 
in wrapper
  func.always_returns = func(*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/keyring/backend.py", line 127, in 
get_all_keyring
  exceptions=TypeError))
File "/usr/lib/python2.7/dist-packages/keyring/util/__init__.py", line 35, 
in suppress_exceptions
  for callable in callables:
File "/usr/lib/python2.7/dist-packages/keyring/backend.py", line 119, in 
is_class_viable
  keyring_cls.priority
File "/usr/lib/python2.7/dist-packages/keyring/util/properties.py", line 
22, in __get__
  return self.fget.__get__(None, owner)()
File "/usr/lib/python2.7/dist-pack

[Yahoo-eng-team] [Bug 1411215] [NEW] Add an option to replicator to select which images to compare/copy

2015-01-15 Thread Arthur Lutz (Logilab) 
Public bug reported:

It would be nice to add some sort of filter to images considered by
glance-replicator.

Two types of a filters would be nice :

* a list of ids
* a list of names

(and maybe some sort of regexp on the names, for example --filter
"ubuntu-*")

A quick look at the code makes me think this can easily be added in the
def get_images just before the yield.

For interfacing I would add :

 --filter-by-name 'item1,item2,item3"
 --filter-by-name 'ubuntu-*'
 --filter-by-id 'id1,id2,id3' 

Am willing to contribute a patch if feature request is adopted (we are
going to implement it anyway).

** Affects: glance
 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/1411215

Title:
  Add an option to replicator to select which images to compare/copy

Status in OpenStack Image Registry and Delivery Service (Glance):
  New

Bug description:
  It would be nice to add some sort of filter to images considered by
  glance-replicator.

  Two types of a filters would be nice :

  * a list of ids
  * a list of names

  (and maybe some sort of regexp on the names, for example --filter
  "ubuntu-*")

  A quick look at the code makes me think this can easily be added in
  the def get_images just before the yield.

  For interfacing I would add :

   --filter-by-name 'item1,item2,item3"
   --filter-by-name 'ubuntu-*'
   --filter-by-id 'id1,id2,id3' 

  Am willing to contribute a patch if feature request is adopted (we are
  going to implement it anyway).

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1411215/+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 1400266] [NEW] Provide a way to set default network to be used when launching a instance

2014-12-08 Thread Arthur Lutz (Logilab) 
Public bug reported:

This is a feature request to be able to configure for a user having
multiple networks available, having a setting on which one would be set
by default so that a user doesn't have to go into the "Networking" tab
every time he wants to launch an instance.

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

Title:
  Provide a way to set default network to be used when launching a
  instance

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  This is a feature request to be able to configure for a user having
  multiple networks available, having a setting on which one would be
  set by default so that a user doesn't have to go into the "Networking"
  tab every time he wants to launch an instance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1400266/+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 1400265] [NEW] Provide a way to set default public key to be used when launching a instance

2014-12-08 Thread Arthur Lutz (Logilab) 
Public bug reported:

This is a feature request to be able to configure for a user having
multiple public keys which one would be set by default so that a user
doesn't have to go into the "Access & Security" tab every time he wants
to launch an instance.

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

Title:
  Provide a way to set default public key to be used when launching a
  instance

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  This is a feature request to be able to configure for a user having
  multiple public keys which one would be set by default so that a user
  doesn't have to go into the "Access & Security" tab every time he
  wants to launch an instance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1400265/+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 1378233] [NEW] Provide an option to ignore suspended VMs in the resource count

2014-10-07 Thread Arthur Lutz (Logilab) 
Public bug reported:

It would be very useful for our case scenario to be able to have an
option that enables not counting suspended machines as consuming
resources. The use case is having little memory available and still
being able to launch new VMs when old VMs are in suspended mode. We
understand that once the compute node's memory is full we won't be able
to resume these machines, but that is OK with the way we're using our
cloud.

For example a compute node with 8G of RAM, launch 1 VM with 4G and
another with 2G, then suspend them both, one could then launch a new VM
with 4G of RAM (the actual memory on the compute node is free).

On essex we had the following patch for this scenario to work :

Index: nova/nova/scheduler/host_manager.py
===
--- nova.orig/nova/scheduler/host_manager.py
+++ nova/nova/scheduler/host_manager.py
@@ -337,6 +337,8 @@ class HostManager(object):
 if not host:
 continue
 host_state = host_state_map.get(host, None)
+if instance.get('power_state', 1) != 1: # power_state.RUNNING
+continue
 if not host_state:
 continue
 host_state.consume_from_instance(instance)

We're looking into patching icehouse for the same behaviour but would
like to add it as an option this time.

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

Title:
  Provide an option to ignore suspended VMs in the resource count

Status in OpenStack Compute (Nova):
  New

Bug description:
  It would be very useful for our case scenario to be able to have an
  option that enables not counting suspended machines as consuming
  resources. The use case is having little memory available and still
  being able to launch new VMs when old VMs are in suspended mode. We
  understand that once the compute node's memory is full we won't be
  able to resume these machines, but that is OK with the way we're using
  our cloud.

  For example a compute node with 8G of RAM, launch 1 VM with 4G and
  another with 2G, then suspend them both, one could then launch a new
  VM with 4G of RAM (the actual memory on the compute node is free).

  On essex we had the following patch for this scenario to work :

  Index: nova/nova/scheduler/host_manager.py
  ===
  --- nova.orig/nova/scheduler/host_manager.py
  +++ nova/nova/scheduler/host_manager.py
  @@ -337,6 +337,8 @@ class HostManager(object):
   if not host:
   continue
   host_state = host_state_map.get(host, None)
  +if instance.get('power_state', 1) != 1: # power_state.RUNNING
  +continue
   if not host_state:
   continue
   host_state.consume_from_instance(instance)

  We're looking into patching icehouse for the same behaviour but would
  like to add it as an option this time.

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