Thierry, we could propose libguestfs patch to trunk, but have concerns with
it. First there is no libguestfs package for ubuntu and libguestfs people
still looking for ubuntu mantainer (http://libguestfs.org/FAQ.html#binaries).
We could create PPA if it will be enough for now, but for next
2011/2/28 Thierry Carrez thie...@openstack.org:
- qcow2 support was enabled utilizing libguestfs instead of missing NBD
Though almost everyone knows I don't like the injection business, using
libguestfs instead of NBD sounds like a patch that could be welcome in
trunk, given that NBD can be a
Hi Raphael,
On Mon, Feb 28, 2011 at 10:01:55AM +, Raphael Cohn wrote:
AMQP Observations
Your comments about AMQP seem to mostly be appropriate for one of the
older versions, eg 0-8, and I don't think they particularly apply to later
versions, eg 1-0. AMQP 0-8 did have some
Jay and I have been having an interesting discussion about how to deal with
bugs that mean that unit tests _should_ fail. So, if I find a bug, I should
write a failing unit test first, and fix it (in one merge). However, if I
can't fix it, I can't get a failing unit test merged into the trunk
@brian: the problem with a json field is that searching would be really
expensive if we ever need to pull mac addresses from the db to ensure
uniqueness.
@Ilya: If I make a table, I plan on putting mac address, instance id,
network id, and if zones are about ready, some sort of zone information in
I'm not a big fan of 'known bugs' in unit tests. Unit tests should always pass.
How practical is it that I'm going to invest the time to write a unit tests on
a bug which I'm then not able to fix in the same merge. In many cases writing
the test cases are actually harder than writing the code
Unittest2 lets you define a test case that is expected to fail:
http://docs.python.org/library/unittest.html#unittest.expectedFailure
new in 2.7, but it could be possible to backport - or do something similar...
May have issues with nose:
http://code.google.com/p/python-nose/issues/detail?id=325
John -
Are we just talking about compute aspects? IMO, we should NOT be exposing
block functionality in the OS compute API. In Diablo, we will break out block
into a separate service with it's own OS block API. That means for now, there
may be functionality in nova that isn't exposed (an
Python 2.7 has @unittest.skip and @unittest.skipUnless decorators. Is this
what you want? You could write the failing unit test, and then mark it as
skipped until the bug is fixed. My only concern would be the Python 2.7
dependency - we're using 2.6 still ourselves, so I'd ask that you wrote
I think it is commendable to identify bugs even if you can't fix them at the
time. I hope that we don't create incentives to ignore bugs you find during
development just to get your own merge through.
But I'm worried about staleness and usefulness with known bugs. If the known
bugs test cases
Hey All,
For various reasons, Rackspace has a need to allow customers to request
placement in the same zone as another server. I am trying to figure out if
this is generically useful, or something that should be outside of core. The
idea is that if you don't specify an affinity ID one will
The Skip plugin for nose offers similar functionality which can be used in
Python 2.6:
http://somethingaboutorange.com/mrl/projects/nose/0.11.1/plugins/skip.html
Using this you can write decorators that raise SkipTest if a certain criteria
isn't met.
Hi Gabe,
There has been a lot of discussion about this, along with zone naming,
structure, and so forth. I was propsing we not only make it part of
Nova, but suggest all projects use the same locality zone names/tags
to ensure cross-project locality.
So, yes, and don't make it nova-specific. :)
Hi Erik, today we have compute, block/volume, and network all encompassed in
nova. Along with image and object storage these make the whole of OpenStack
today. The goal is to see where we are at wrt the OpenStack API
(compute/network/volume/image) and coverage of the underlying implementation
as
This seems to overlap heavily with justin's metadata stuff. The idea was that
you could pass in metadata on instance launch saying near: other-object. I
think that is far more useful than an opaque affinity id.
Vish
On Feb 28, 2011, at 2:53 PM, Gabe Westmaas wrote:
Hi Eric,
I probably
We definitely wil need to be able to create volumes at the very least without
using ec2. Justinsb has some prototype code available for this.
Vish
On Feb 28, 2011, at 2:53 PM, John Purrier wrote:
Hi Erik, today we have compute, block/volume, and network all encompassed in
nova. Along with
That all sounds good. My only question is around images. Is glance ready to
be an independent service (and thus have a separate API) in Cactus?
Erik
From: John Purrier j...@openstack.orgmailto:j...@openstack.org
Date: Mon, 28 Feb 2011 16:53:53 -0600
To: Erik Carlin
Yes - the use case I'm working towards is to use metadata to specify
openstack:near=volume-01 when creating a machine, and I will provide a
scheduler that will take that information and will assign you a machine e.g.
in the same rack as the volume storage. It's unclear right now whether this
Yup, Sandy's zone stuff, Justin's metadata stuff, and this is all
pretty much the same (or at least very closely related). First off,
lets move away from the term zone and define location as an arbitrary
grouping of one or more resources, not the traditional availability
zones. Thinking in terms
It's an open question whether 'meaningful tags' are treated as metadata with
a system-reserved prefix (e.g. openstack:), or whether they end up in a
separate area of the API. The aws: prefix is already reserved by AWS in
their API, so we'll probably need to reserve it in ours as well or face
Interesting, I guess I just don't see the point of introducing additional
complexities for gain I don't yet see. My example about 'image type' was meant
to act as a deterrent against using metadata for OpenStack meaningful values.
Instances, in my opinion, should be created explicitly with
Interesting, I guess I just don't see the point of introducing additional
complexities for gain I don't yet see.
We can defer discussion until the patch lands, when you can see the gains
(or not!) :-)
My example about 'image type' was meant to act as a deterrent against using
metadata for
On Mon, Feb 28, 2011 at 6:49 PM, Brian Lamar brian.la...@rackspace.com wrote:
Just because I can't help but asking, when does data specified during
instance creation stop being data and start being metadata? While it seems
like a silly question I'm wrestling with the idea of metadata actually
On Mon, Feb 28, 2011 at 10:45 PM, Jay Pipes jaypi...@gmail.com wrote:
for those of a like-minded curiosity about these things. From the
wikipedia article on this same subject:
The term Metadata is an ambiguous term which is used for two
fundamentally different concepts (Types). Although a
Erik,
Thanks for the clarification. I'd just like to reiterate that official support
for the EC2 API is something that needs to be handled in parallel, since we've
committed to supporting it in the past.
Best,
Devin
On Feb 28, 2011, at 7:53 PM, Erik Carlin wrote:
Devin -
In a
On Mon, Feb 28, 2011 at 8:15 PM, Ewan Mellor ewan.mel...@eu.citrix.com wrote:
If the “known_bugs” list isn’t being well received, how about this:
# TODO(ewanm): Enable once bug #21212 is fixed
if False:
assert(something)
And then put a comment on bug #21212 saying “please also
Thanks Devin for the reiteration. I'm for EC2 API support, I just think that
OS owning our own API specs is key if we are to innovate and drive open,
standard per service interfaces.
Erik
From: Devin Carlen devin.car...@gmail.commailto:devin.car...@gmail.com
Date: Mon, 28 Feb 2011 19:59:38
This is great stuff. It sounds like there is a real distinction to be made
between the data central to the apis and the user-defined properties. Also, as
time and compatibility allow, we should probably change what we were calling
metadata to be called properties or somesuch.
Jay Pipes
I'm also confused because nova (compute/block/network) is in 1 repository
doesn't mean it isn't 3 different services.
We've talked about moving the services inside nova to not reaching inside of
each other via RPC calls and instead making HTTP calls. But they are mostly
already designed in a
Jesse,
I agree that some implementations can want to have a single endpoint. I think
this is doable with a simple proxy that can pass requests back to each service
apis. This can also be accomplished by having configuration variables in your
bindings to talk to something that looks like the
Hi Ewan,
This would then allow you to configure which OSes have NX turned on, etc. Is
this something that you want to tackle, Cory?
I'm already working on a way to do this, which is what prompted me to
ask for input on the various vm-params. :)
Thanks for the feedback. I've consolidated
31 matches
Mail list logo
