Re: [Openstack] Keystone versioning and tarballs

2011-10-28 Thread Yun Mao
The problem looks like that only users with role ['projectmanager', 'sysadmin'] can run instances. The demo user created by devstack only has Member role. Not sure how it's mapped to the roles described in http://docs.openstack.org/diablo/openstack-compute/admin/content/users-and-projects.html

Re: [Openstack] Keystone versioning and tarballs

2011-10-27 Thread Yun Mao
I think I'm close to figuring this out. You can take a look at the devstack scripts. In particular, https://github.com/cloudbuilders/devstack/blob/master/files/keystone_data.sh Then you can source openrc to get the EC2_* environment variables. However, it only works for euca-describe-instances,

Re: [Openstack] Keystone versioning and tarballs

2011-10-25 Thread David Kranz
Along the same lines, how do you export the shell variables for euca-tools with keystone since nova-manage to create the zipfile does not work? -David On 10/24/2011 8:29 PM, Vishvananda Ishaya wrote: Speaking of keystone diablo tag, it is currently missing the following commit:

[Openstack] Keystone versioning and tarballs

2011-10-24 Thread Mark McLoughlin
Hey, I just noticed a few things when reviewing the Fedora packaging of keystone: - There's no diablo release tarball on https://launchpad.net/keystone like other projects - The 2011.3 tag in git has version=1.0 in setup.py. Which versioning scheme is keystone going to follow?

Re: [Openstack] Keystone versioning and tarballs

2011-10-24 Thread Dolph Mathews
We definitely need to publish a tarball for diablo. I recently refactored/centralized our versioning (we were reporting different versions in different places in the codebase). At the same time, I also set the `keystone.version()` response to 'essex-dev', since we haven't discussed codebase

Re: [Openstack] Keystone versioning and tarballs

2011-10-24 Thread Mark McLoughlin
Hi Dolph, On Mon, 2011-10-24 at 14:35 +, Dolph Mathews wrote: We definitely need to publish a tarball for diablo. Cool. Will the version be 1.0 or 2011.3, though? :) I recently refactored/centralized our versioning (we were reporting different versions in different places in the

Re: [Openstack] Keystone versioning and tarballs

2011-10-24 Thread Dolph Mathews
As long as the versioning scheme is self-consistent, I don't have any opinion on what we use. How do Openstack's named releases (cactus, diablo, essex) not work, though? (they're still sortable, right?) (and what was the .3 in 2011.3 supposed to mean? I assume it's not March, considering the

Re: [Openstack] Keystone versioning and tarballs

2011-10-24 Thread Joseph Heck
.3 means 3rd quarter I noticed that the developer docs aren't grabbing the version correctly to place them in when rendering... is keystone.version() the right place to get that information? If so, I'll make that edit to get it into the developer docs generation. -joe On Oct 24, 2011, at

Re: [Openstack] Keystone versioning and tarballs

2011-10-24 Thread Jay Pipes
On Mon, Oct 24, 2011 at 12:19 PM, Joseph Heck he...@me.com wrote: .3 means 3rd quarter Not quite :) The number after the year is the number of releases done in that year... 2011.3 was the third release in 2011. Cactus was a 3 month release cycle... So, next year, assuming we stay on the same

Re: [Openstack] Keystone versioning and tarballs

2011-10-24 Thread James E. Blair
Vishvananda Ishaya vishvana...@gmail.com writes: Speaking of keystone diablo tag, it is currently missing the following commit: https://github.com/openstack/keystone/commit/2bb474331d73e7c6d2a507cb097c50cfe65ad6b6 This commit is required for the ec2 api to work with keystone. Seems like we