Hi there from OpenStack Community, After the research done by my colleage Edward Zhang and myself, we have found the following issues for openstack. We have already raised bug https://bugs.launchpad.net/nova/+bug/974810.
1. The ROOT cause that i18n did not work in Nova In Nova, within nova.image, there is a python file glance.py. This file has a line of code GlanceClient = utils.import_class('glance.client.Client'), which calls the class glance.client.Client from Glance project. Each time this line of code is called, the gettext domain will change from nova to glance. But it doesn't recover nova domain after glance client returns the control. So the i18n won't be correctly working in nova. Detailed explanation: Within Nova.__init__.py, there is gettext.install('nova', unicode=1). If we want to make i18n (e.g. Chinese) work, we need to modify it into gettext.install('nova', [path of locale directory], unicode=1). The first parameter "nova" is the domain for i18n within nova project. However, when the code as the right image shows is called, gettext.install('glance', unicode=1) within glance.__init__.py will be called. So the domain switches from 'nova' to 'glance', though we are still running the nova project. Nova project needs 'nova' as the domain. When the domain changes, certainly i18n will fail. 2. Differences between the development mode and the operation mode We are using devstack to run our environment. As we talked about changing gettext.install('nova', unicode=1) into gettext.install('nova', [path of locale directory], unicode=1) before, this may lead to another issue. gettext.install has a default directory, which is where openstack can install its locale files, like all the .mo files. However, devstack does not install locale files in the default directory, which is why we need to make the change. We suggest that openstack have two modes: development and operation. Different modes have different settings for the paths. 3. Improvement of the context management There is blueprint about decoupling client code of glance from the glance project and there is a python-glaceclient under development. It can resolve i18n issue potentially, since nova won't call glance directly and glance domain won't be loaded in nova. In our opinion, we would call it AVOID it rather than RESOLVE it. If we go one step further, this indicates that there is an issue for the context management. OpenStack has different projects and different logging environments, etc, which we call context. It is natual for us to switch context b/w different program, e.g. from nova to glance. In nova, there is no clear management and indication that the context has been changed or clear exist for the context to switch back. The i18n issue is just a tip of the iceberg for the context management. It is a potential improvement for openstack. We hope the above information can help OpenStack become better and we would like to hear more comments from our community. Thank you very much. Best wishes. Vincent Hou (侯胜博) Software Engineer, Standards Growth Team, Emerging Technology Institute, IBM China Software Development Lab Tel: 86-10-82450778 Fax: 86-10-82453660 Notes ID: Sheng Bo Hou/China/IBM@IBMCN E-mail: sb...@cn.ibm.com Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang West Road, Haidian District, Beijing, P.R.C.100193
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp