[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?

[Openstack] Fwd: error when create volume use nova volume-create

2011-10-24 Thread DeadSun
Hi.Razique, I am livemoon I have install tgt via package. Now I have nova volume-create a volume. * openstack@node2:/data/nova$ sudo tgtadm --lld iscsi --op show --mode target Target 8: iqn.2010-10.org.openstack:volume-0001 System

Re: [Openstack] error when create volume use nova volume-create

2011-10-24 Thread DeadSun
Now I can export lun: $ sudo iscsiadm -m discovery -t sendtargets -p node2 10.11.3.64:3260,1 iqn.2010-10.org.openstack:volume-0001 but errors still show: 2011-10-24 17:04:01,015 DEBUG nova.utils [-] Running cmd (subprocess): sudo iscsiadm -m discovery -t sendtargets -p node2 from

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

[Openstack] high availability deployment

2011-10-24 Thread Yun Mao
Hi stackers, is there a document somewhere that talks about the deployment strategy for high availability? There seems to be a few single point of failures in the nova architecture -- the controller, which has the API and the scheduler, the rabbitmq server, and the mysql server. Google helped me

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

[Openstack] Most current diablo swift pkgs?

2011-10-24 Thread andi abes
I'm a bit confused with the state of affairs for swift diablo. I've seen notes and checkins for backports to nova from essex, and found https://launchpad.net/~openstack-release/+archive/2011.3 which seems to be the repo for the patched packages... Is that right? Is this the location that will be

[Openstack] volume cannot be attached to a server

2011-10-24 Thread DeadSun
I have create a volume sucessfully. When I use it to attach a server, the nova-compute log show :ERROR nova.compute.manager [df1f81f6-66b4-441e-8996-690e74265fef admin 1] instance 7: attach failed /dev/vdc, removing how to fix it? Thank you; $ nova --debug volume-attach 7 3 /dev/vdc

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

[Openstack] API Versioning and Extensibility

2011-10-24 Thread Mark Nottingham
tl;dr * OpenStack should use the Server, User-Agent and perhaps Via headers for debugging implementation issues. We may want to consider requiring a User-Agent header from clients. * Versions in API discussions should mean backwards-incompatible changes in the API, as distinct from versions