count (from
http://nova.openstack.org/~soren/stats/nova-review-stats.html) the following
people have been very low on reviews over the past few months:
Brian Lamar (12)
Jesse Andrews (12)
Joshua McKenty (0)
Monsyne Dragon (12)
Monty Taylor (4)
Paul Voccio (7)
Soren Hansen (10)
termie (0)
Todd Willey
Can anyone enlighten me as to why the gate-melange-unittests-python26 job is
only running a single test? The first time it ran it correctly found all 500+
tests but now it seems to be just running one. :(
This is happening locally for me too and I'm not quite sure where the
disconnect is. I
On Mar 23, 2012, at 11:22 AM, Kevin L. Mitchell wrote:
On Fri, 2012-03-23 at 08:55 -0300, Sandy Walsh wrote:
I don't doubt for a second the db is the culprit for many of our woes.
The thing I like about internal caching using established tools is
that
it works for db issues too without
How is MySQL access handled in eventlet? Presumably it's external C
library so it's not going to be monkey patched. Does that make every
db access call a blocking call? Thanks,
Nope, it goes through a thread pool.
I feel like this might be an over-simplification. If the question is:
How is
Yuriy,
Nova is currently in the essex-4 part of the development cycle which includes a
Feature Freeze. No branches containing features should be merged in until the
next part of the cycle. You can submit a feature freeze exception request or
wait for the Folsom branch to be active (early
with the
following state of affairs:
** The official OpenStack Chef cookbooks **
https://github.com/openstack/openstack-chef
These chef cookbooks are the ones maintained mostly by Dan Prince and
Brian Lamar and these are the cookbooks used by the SmokeStack project.
The cookbooks contained in the above
From what I understand, Nova is in the middle of a transition from gflags to
optparse.
It's difficult to tell exactly what is going on, but the flags file is still
being read by gflags and then optparse seems to take over from there.
Regardless, both libraries are still being used and the
Hey Monty/All,
The original goal of my eventlet connection pooling patch was to increase
overall throughput of the OpenStack API. By itself, SQLAlchemy provides a lot
of nifty features such as connection pooling and connection timeout limits, but
all of these were being lost on us because of
Hey Josh,
Has there been any thought on having a nova-db service that responds to
requests for
information from the db (or something like a db).
No plans that I'm aware of, there is a Database-as-a-Service project called
'Red Dwarf' which might fit this bill however. I honestly haven't
Hey Matt,
I don't have the how and why something gets approved, but I do know that I
asked for a timeline when proposals opened and this is what I got from Thierry:
Propose sessions (Sep 6 - Sep 27)
Review sessions (Sep 12 - Sep 29)
Schedule sessions (Sep 27 - Oct 2)
So it looks like this was
This method is supported only by libvirt.
This means that currently live migration is only implemented in the
Nova-libvirt driver. We have a number of different drivers in Nova, and one of
them uses libvirt as the underlying hypervisor connection.
The libvirt project supports connecting to
Authentication is the act of acquiring a valid token from Keystone. That
token can be used to prove that you have recently been authenticated. I see one
point where you call this token an authorization token. This might be one of
the issues because I would most certainly refer to that token as
I've heard this a couple times recently and it's a fine idea. That being said
I'm not aware of anyone currently working on this. This would be a great thing
to add for Essex and a great topic in general for the upcoming Design Summit in
October.
Is this something you want to work on? Either
I see this happening more and more when deadlines are coming up:
There is a merge proposal which has 2+ Core Approvals and 1+ Core Needs Fixings
and the branch is marked as 'Approved'. This is fine, in my opinion, if you've
talked to the person and they have given verbal approval or if the
All,
I love the idea of having an openstack-common project. However, the prospect of
creating such a project is daunting and quite difficult.
It's my belief that standardizing/collecting common logic into a single module
will be beneficial to our current code-base and allow for future projects
(There is a summary at the bottom!)
Jay/Kei/Everyone,
I thought the exact same thing but I had completely forgotten to respond.
The term 'snapshot', as it is currently being used IMO is incorrect and/or
misleading. Perhaps it's a burden of knowledge, but I start equating anything
generated
Only a small scream on PUT /zones/server/
PUT would work in my mind if we allowed users to create their own
ReservationIDs, but since (I assume) we're generating them it would make more
sense to me to use POST on /zones/server.
-Original Message-
From: Sandy Walsh
Dave,
While I'm not Vish, I have been working on/around authentication for the past
couple weeks and I'll provide my thoughts.
EC2 and OpenStack Nova APIs should not be affected by the authentication work
going on. The Keystone project is the only candidate I'm aware of, and it seems
like it
I like this idea, but I have some concerns about the feasibility of
successfully differentiating between users and projects. While it's easy to
query one data store and then the next, perhaps we can avoid this issue by
assigning unique identifiers to resources?
Show all servers in project1:
, February 28, 2011 6:59pm
To: Brian Lamar brian.la...@rackspace.com
Subject: Re: [Openstack] server affinity
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
Would a less structured approach work to make billing/reporting more flexible
for the community? I was thinking something along the lines of tags. With an
arbitrary set of tags, instances could have a tag saying they belong to a
certain organisation and/or an enterprise.
Reports could be
21 matches
Mail list logo
