[Openstack] Hashing image files

Hi, Michael! I am curious to know: is it necessary for nova to save images in file which names are sha1 hashes from image IDs (UUIDs)? Nova saves root image under its sha1 hash: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/connection.py#L1214 but it saves kernel and ramdisk

[Openstack] Hashing image files

Hi! I am curious to know: is it necessary for nova to save images in file which names are hashes from image IDs (UUIDs)? Nova saves root image under its sha1 hash: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/connection.py#L1214 but it saves kernel and ramdisk under their

[Openstack] Allow keystone users to know their rights

Hi! Currently, user can obtain information about his rights (roles, tenants, endpoints) only saving response to POST /tokens query. If you are a non-privileged user, have a token, and haven't saved the mentioned response, you cannot know your rights - you have to make another POST /tokens query

Re: [Openstack] ssh not authenticating

Hi, Scott! I knew that the password was already on the cirros image. However, we (Grid Dynamics engineers) faced a strange problem: 1) if an instance is launched without an ssh key, you can login using the password (generated by nova in our case); 2) if an instance is launched _with_ an ssh key,

[Openstack] [bug] cannot umount guestfs (Bug #1013689)

Hi! On our machines ins Grid Dynamics (HP ProBooks and miscellaneous servers), repeating unmount if it reported device or resource is busy while spawning a VM is not acceptable. Very often, unmount is reported as _successful_ during the _first_ attempt, but the filesystem remains _unsynchronized_

Re: [Openstack] ssh not authenticating

Hi! That's possible that filesystem of your VM was not cleanly unmounted during update of /etc/shadow and authorized_keys. It may remain in its original state, so, your ssh key is not stored. Please check this bug: https://bugs.launchpad.net/nova/+bug/1013689 Could you quote your nova-compute.log,

Re: [Openstack] Common openstack client library

-common seems to be a stub for a server and there is no client code, isn't it? Sincerely On Tue, Jun 19, 2012 at 8:14 PM, Monty Taylor mord...@inaugust.com wrote: Hi! On 06/19/2012 09:43 AM, Alexey Ababilov wrote: Hi! Unfortunately, nova, keystone, and glance clients are very inconsistent

[Openstack] Common openstack client library

Hi! Unfortunately, nova, keystone, and glance clients are very inconsistent. A lot of code is copied between all these clients instead of moving it to a common library. The code was edited without synchronization between clients, so, they have different behaviour: - all client constructors

[Openstack] Tests failed for glance case sensitivity patch

Hi, Brian! Thank you for advices for my glance patch! I would like to ask your help. I saw the following report for the latest patch edition: - https://jenkins.openstack.org/job/gate-glance-merge/825/ : SUCCESS - https://jenkins.openstack.org/job/gate-glance-pep8/1007/ : SUCCESS -

[Openstack] Bug: keystone middleware is not logged

Hi! keystone.middleware.auth_token logs a lot of essential info (i.e. problems with the service user) that is not saved in log files. This is described in https://bugs.launchpad.net/nova/+bug/988951 . A possible fix is mentioned there, too. Please pay attention to this bug. -- Alessio Ababilov

Re: [Openstack] Monitoring / Billing Architecture proposed

Hi! We have developed Nova Billing v2. Its documentation is currently available at http://aababilov.github.com/nova-billing-doc.github.com/. The documentation includes a glossary and architecture and API descriptions. Nova Billing v2 is a totally new solution. Its API and architecture were