Re: [openstack-dev] [Openstack-operators] [Openstack] Rescinding the M name decision

2015-07-11 Thread Chenhong Liu
+1 for this

On Fri, Jul 10, 2015 at 5:20 PM Thierry Carrez thie...@openstack.org
wrote:

 Adam Lawson wrote:
  The alternative of course is to just number the releases since names
  ultimately don't mean anything but it seems there are problems with that
  level of simplicity. I personally prefer Tristan's suggestion to keep it
  as simple as possible. In a few years we'll run out of letters anyway.

 Part of the confusion here is that we are not naming releases. We are
 naming release *cycles*. We are giving a name to a period of time,
 basically. In that period of time, various version numbers for various
 components will be released. Saying Glance 12.0.0 was released in
 OpenStack 13 cycle is not really helping.

 We won't run out of letters, because the names can cycle back to A
 (potentially using a new theme, away from geographic features near
 where the corresponding design summit happened).

 So while we could technically name a release cycle 14, I feel it's a
 bit more difficult to rally around a number than a name. Also, numbers
 wouldn't really solve the perceived issues with names: numbers happen to
 also be culturally meaningful. You don't have a 13th floor in many US
 buildings. In China, building miss the 4th floor instead. 9 is feared in
 Japan. And don't talk about 39 to Afghans.

 I think growing up is accepting the pain that comes with picking a
 good name, rather than sidestepping the issue.

 --
 Thierry Carrez (ttx)

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [keystone]Why not common definition about normal HTTP status code like 2xx and 3xx?

2015-06-02 Thread Chenhong Liu
There is keystone/exception.py which contains Exceptions defined and used
inside keystone provide 4xx and 5xx status code. And we can use it like:
exception.Forbidden.code, exception.forbiddent.title
exception.NotFound.code, exception.NotFound.title

This makes the code looks pretty and avoid error prone. But I can't find
definition for other status code, like 200, 201, 204, 302, and so on. The
code in keystone, especially the unit test cases,  just write these status
code and title explicitly.

How about add those definitions?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [devstack][keystone] Don't use devstack master branch with stable/kilo

2015-05-17 Thread Chenhong Liu
I encountered the same problem when I run keystone with eventlet server by
using *keystone-all* command.

The failure caused by func *load_driver* in *keystone.common.manager*.

try:
driver_manager = stevedore.DriverManager(namespace,
 driver_name,
 invoke_on_load=True,
 invoke_args=args)
return driver_manager.driver
except RuntimeError:
# Ignore failure to load driver using stevedore and continue on.
pass

stevedore failed to load the module, and the RuntimeError's error message
is:
No 'keystone.identity' driver found, looking for 'sql'
while 'keystone.identity' is the value of namespace, and 'sql' is the value
of driver, boht of them are right. I also check the setup.cfg file, it
contains the right lines:

keystone.identity =
ldap = keystone.identity.backends.ldap:Identity
sql = keystone.identity.backends.sql:Identity

Then I build another environment by cloning newest repo and reinstall the
virtualenv. Then, the server starting successfully. *So, I don't know why
stevedore failed.*

But I indeed found there is a bug: If stevedore failed to load a driver,
the backward way doesn't help:

def _load_using_import(driver_name, *args):
return importutils.import_object(driver_name, *args)

# For backwards-compatibility, an unregistered class reference can
# still be used.
return _load_using_import(driver_name, *args)

These code will try to import a driver_name = 'sql', and it failed.

On Sun, May 17, 2015 at 4:25 PM Chenhong Liu liuchenh...@unitedstack.com
wrote:


 I encountered the same problem when I run keystone with eventlet server by
 using *keystone-all* command.

 The failure caused by func *load_driver* in *keystone.common.manager*.

 try:
 driver_manager = stevedore.DriverManager(namespace,
  driver_name,
  invoke_on_load=True,
  invoke_args=args)
 return driver_manager.driver
 except RuntimeError:
 # Ignore failure to load driver using stevedore and continue on.
 pass

 stevedore failed to load the module, and the RuntimeError's error message
 is:
 No 'keystone.identity' driver found, looking for 'sql'
 while 'keystone.identity' is the value of namespace, and 'sql' is the
 value of driver, boht of them are right. I also check the setup.cfg file,
 it contains the right lines:

 keystone.identity =
 ldap = keystone.identity.backends.ldap:Identity
 sql = keystone.identity.backends.sql:Identity

 Then I build another environment by cloning newest repo and reinstall the
 virtualenv. Then, the server starting successfully. *So, I don't know why
 stevedore failed.*

 But I indeed found there is a bug: If stevedore failed to load a driver,
 the backward way doesn't help:

 def _load_using_import(driver_name, *args):
 return importutils.import_object(driver_name, *args)

 # For backwards-compatibility, an unregistered class reference can
 # still be used.
 return _load_using_import(driver_name, *args)

 These code will try to import a driver_name = 'sql', and it failed.

 On Sun, May 17, 2015 at 6:55 AM Scott Drennan sco...@nuagenetworks.net
 wrote:

 Perhaps an obvious statement, but devstack master was working with
 stable/kilo until recently, and as of today, it isn't any more (at least
 for me).

 The devstack commit Use stevedore for keystone backends on 2014-05-15
 changes the way backends are set, and when I did a fresh install today I
 ended up with keystone.conf entries like this:

 [assignment]
 driver = sql
 ...
 [identity]
 driver = sql
 ...
 [token]
 driver = sql


 rather than fully specified module names (e.g. driver =
 keystone.identity.backends.sql.Identity)

 This caused keystone to fail, with errors
 in /var/log/apache2/keystone.log like this:

 2015-05-16 21:16:25.786955 mod_wsgi (pid=9296): Exception occurred
 processing WSGI script '/var/www/keystone/main'.
 2015-05-16 21:16:25.787114 Traceback (most recent call last):
 2015-05-16 21:16:25.787189   File /var/www/keystone/main, line 25, in
 module
 2015-05-16 21:16:25.787409 application =
 wsgi_server.initialize_application(name)
 2015-05-16 21:16:25.787437   File
 /opt/stack/keystone/keystone/server/wsgi.py, line 51, in
 initialize_application
 2015-05-16 21:16:25.787600 startup_application_fn=loadapp)
 2015-05-16 21:16:25.787625   File
 /opt/stack/keystone/keystone/server/common.py, line 41, in setup_backends
 2015-05-16 21:16:25.787769 drivers = backends.load_backends()
 2015-05-16 21:16:25.787795   File
 /opt/stack/keystone/keystone/backends.py, line 39, in load_backends
 2015-05-16 21:16:25.787946 _IDENTITY_API = identity.Manager()
 2015-05-16 21:16:25.789345   File
 /opt/stack