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
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
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
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
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
.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
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
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
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
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
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
11 matches
Mail list logo