The current OpenStack paradigm seems to be built around external storage,
which contains user data on attached volumes. However, we wanted to create
distributed storage on the same nodes we are running nova-compute on.
2011/5/26 Peter J. Pouliot ppoul...@novell.com
Greetings Programs,
We to
Thomas Goirand wrote:
P.S to Openstackers: I really would have like to
avoid creating a separate list for the Debian pkgs
of Openstack, especially because I will have to
have a diff in the debian/control (maintainer field
will have to be different) but as you see,
Launchpad prevents me from
On Sat, 28 May 2011 21:05:49 +0800
Thomas Goirand tho...@goirand.fr wrote:
Hi Luca,
thanks for this prompt reply.
- Original message -
Hi Thomas!
Il 28/05/2011 09:00, Thomas Goirand ha scritto:
I previously uploaded Swift to Experimental, but the email I used
was one
Some of the data stored in the cloud has legal requirements to be stored
physically within certain geographical boundary (for example within a country).
Currently OpenStack does not allow to impose restrictions on data location.
It looks like zones can be very handy to achieve data location
This was one of the use cases that drove the design discussion on decoupling
the swift ring implementation from the rest of swift (along with supporting
multiple tiers of hardware). See
https://blueprints.launchpad.net/swift/+spec/swift-pluggable-hashing-ring for
the basic proposal, however,
Hi,
I would like to request clarity on the semantics of the attach resource
to port operation proposed in Quantum in the context of spawning a VM.
Let's discuss this with respect to a specific example. As of today,
nova-compute generates the domain configuration (libvirt.xml), including
the
6 matches
Mail list logo
