Hi everyone,
I released a new version of the Burrow message queue service today,
tagged in the diablo-4 milestone. You can find it here:
https://launchpad.net/burrow
The work during diablo has focused on finishing the conversion of
prototype to a real project and increasing test coverage, docs,
Hi everyone,
I gave my notice today at Rackspace, and I'll be moving on to another
job not OpenStack related. Since PPB elections are happening right now,
I figured it would be best for me to give up the remaining 6-month
term to someone else who will be more involved with the project.
It has
On Mon, Jul 11, 2011 at 12:27:16PM +0200, Soren Hansen wrote:
2011/7/11 Ewan Mellor ewan.mel...@eu.citrix.com:
No, not string vs guid. Current AWS IDs are 32 bits. Being a small key
space, this means that you either need to allocate them incrementally
(implying a distributed transaction
On Mon, Jul 11, 2011 at 05:17:05PM +, Sandy Walsh wrote:
How is
nova-account-instance uuid
any different than:
----
Where // (or some subset of them) are reserved/regulated?
Nothing, if -- is a full UUID. If we
, nova-uuid is sufficient.
On Jul 11, 2011, at 12:42 PM, Eric Day wrote:
Agreed, anyone could inject UUIDs that collide. UUIDs alone are not
sufficient, you need a namespace prefix as well (something I brought
up many times before on other ID threads). The full ID needs
, at 12:01 PM, Ed Leafe wrote:
On Jul 11, 2011, at 2:04 PM, Eric Day wrote:
How is
nova-account-instance uuid
any different than:
----
Where // (or some subset of them) are reserved/regulated?
Nothing, if -
Hi Jay,
On Wed, May 25, 2011 at 03:40:27PM -0400, Jay Pipes wrote:
On Wed, May 25, 2011 at 3:32 PM, Greg Holt gh...@rackspace.com wrote:
select w from x where y marker order by y limit z
This gives you consistent pagination, means the database doesn't have to
count matching rows to
Also keep in mind that UUIDs alone may not be sufficient. As was
discussed previously in a marathon ID rename thread, we have to
handle the case of federated zones gone bad that could purposefully
produce UUIDs that collide. We may want any extra namespace such as
account:uuid or zone:uuid, but of
Assuming you are using Swift for storage, the Swift ring configuration
can specify zones and minimum number of replicas, which could handle
all this logic and bit pushing for you.
-Eric
On Tue, May 17, 2011 at 06:36:38PM +, Glen Campbell wrote:
That's probably the easiest to implement. This
I've been thinking of doing the same to focus on Burrow since I've
not been following many of the nova discussions lately and there are
so many new folks involved in -core. I think I'll follow your lead,
but I'll still be around for reviews where I'm useful.
-Eric
On Wed, May 11, 2011 at
SNS vs. SQS, except this isn't a cloud service but a mechanism for
notifying interested party of cloud changes.
-George
On May 10, 2011, at 1:49 PM, Eric Day wrote:
We may also want to put in some kind version or self-documenting URL
so it's easier to accommodate message format
, Eric Day e...@oddments.org wrote:
Hi George,
Understood, but burrow can act as both. At the core, the difference
between SQS and SNS are notification workers and a lower default
message TTL. Matt mentioned that Nova will push to RabbitMQ or some
other MQ and workers pull from the queue
Can we make it 6? The zone talk is at 5:30 and most of us should probably be
there.
On Apr 27, 2011 1:28 PM, Jonathan Bryce jbr...@jbryce.com wrote:
Can everyone make it at 5:45 tonight at the lounge area of the lobby?
There are a couple of things I know I've heard people would like to talk
Hi everyone!
Last week I released the first version of Burrow, a message queue
being designed for public clouds, for Cactus. It's still very early
on and should only be considered as a development release (don't run
off to put it into production), but it still is able to show how the
project is
Is the existing OpenStack dashboard project modular enough to
support other applications? So far it seems to mostly be a Nova
dashboard, but it would be nice if each project didn't need its own
application/dashboard. Instead each project could have a tab or section
within the OpenStack dashboard.
Looks good! I'm looking forward to the summit discussions. Beyond
pluggable backends, I would make sure other layers remain pluggable
as well (the auth mechanism, protocols to verify, etc). The use cases
I have in mind are:
* All common forms of HTTP auth.
* OpenID, OAuth, and any other open
Hi Thomas,
I think ideally nova-manage would simply be a command line client using
the exposed API in bin/nova-api. So what we really need is nova-api
additions to encapsulate the nova-manage functionality, and you could
hit that directly. There has been a lot of API functionality added
in this
I'm mostly unavailable Thursday as well (at conference), so anytime
Friday would be better for me too.
-Eric
On Wed, Apr 13, 2011 at 09:49:40AM -0500, Jonathan Bryce wrote:
Ewan, Jesse, Vish and I are all unavailable at our regular meeting time
tomorrow. I could do it on Friday at the
Well, GitHub issues may be a bit more suitable for our needs now:
https://github.com/blog/831-issues-2-0-the-next-generation
-Eric
On Fri, Apr 08, 2011 at 05:21:20PM -0400, Jay Pipes wrote:
All,
In an effort to speed up our code development processes, reduce the
friction amongst existing
On Thu, Apr 07, 2011 at 11:54:26AM +, Sandy Walsh wrote:
Well, they should start off with what the request specifies. For
the 1.1 API, this takes the for of POST /v1.1/owner/servers/ so
owner would be the owner. This could be anything depending on what
the authenticated user has access
I agree we should be able to specify network resource when launching
an instance to get around the vlan-per-owner issue. This gets
to the bigger issue of splitting out nova network as a different
network-as-a-service project and enabling more functionality there
(such as allow other resource types
On Wed, Apr 06, 2011 at 11:31:35AM +, Sandy Walsh wrote:
Myself and Eric were chatting a little more about this on IRC yesterday
http://paste.openstack.org/show/1108/
Eric made an interesting observation that we don't need to call them Resource
Groups, since they're just collections of
that maintains some usability.
On Apr 4, 2011, at 4:02 PM, Eric Day wrote:
Hi Sandy,
Thanks for putting this together, it really helps to facilitate the
discussion. I do have a couple concerns though with this latest design.
The AuthZ services talk to each other. I don't see why this should
On Tue, Apr 05, 2011 at 01:53:46AM +, Sandy Walsh wrote:
From: Vishvananda Ishaya [vishvana...@gmail.com]
Eric:
I agree that your suggestion is simpler, but I think we are too limited if
we remove multi-membership and per-
object overrides. Imagine that alice is an organization that
Hi Ed,
On Wed, Mar 23, 2011 at 08:15:54AM -0400, Ed Leafe wrote:
On Mar 23, 2011, at 1:55 AM, Eric Day wrote:
If we provide some structure to the IDs, such as DNS names, we not only
solve this namespacing problem but we also get a much more efficient
routing mechanism.
When I
I asked for further details in IRC, which started a discussion
there. To sum up, most folks agree migrations within a zone won't
require a new instance ID. Nothing changes except the compute host
it's running on. Migrations outside of a zone would require a new
instance ID, but this should be
On Wed, Mar 23, 2011 at 07:40:20PM +, Ed Leafe wrote:
Migrations outside of a zone would require a new
instance ID, but this should be fine, since other things would also
change (such as IP, available volumes, ...).
That's probably true in the Rackspace use case, as zones would
Well said Vish, this would be a great wiki entry for folks to reference
in the future. :)
While Nova probably needs the most coordination due to it's developer
base, these of course apply to all other projects.
-Eric
On Tue, Mar 22, 2011 at 11:55:17PM -0700, Vishvananda Ishaya wrote:
After
On Thu, Mar 24, 2011 at 12:23:42AM +, Sandy Walsh wrote:
From: Eric Day [e...@oddments.org]
Do we want this namespace per zone, deployment, resource owner, or some
other dimension?
Good question. We can prevent collisions at the zone level and within a
deployment (single provider
Hi Sandy,
On Thu, Mar 24, 2011 at 01:01:18AM +, Sandy Walsh wrote:
From: Eric Day [e...@oddments.org]
Within that zone Nova will prevent collisions, but if things are really
broken (accident or on purpose)
and it starts returning duplicate resource IDs, peer zones can choose to just
Ok. :) The original statement felt like it was written with negative
connotations, and I just wanted to say I think it's all been positive.
-Eric
On Wed, Mar 23, 2011 at 10:09:50PM -0400, Ed Leafe wrote:
On Mar 23, 2011, at 9:54 PM, Eric Day wrote:
I don't think anyone is arguing, all
On Tue, Mar 22, 2011 at 12:40:21PM -0400, Ed Leafe wrote:
The two obvious solutions are a) a single, shared database and b) using
a UUID instead of an integer for the ID. Both of these approaches have been
discussed and rejected, so let's not bring them back up now.
We shouldn't
On Tue, Mar 22, 2011 at 10:48:09AM -0700, Justin Santa Barbara wrote:
We can square the circle however - if we want numbers, let's use UUIDs -
they're 128 bit numbers, and won't in practice collide. I'd still prefer
strings though...
If we use a number/uuid without a zone prefix,
See my previous response to Justin's email as to why UUIDs alone are
not sifficient.
-Eric
On Tue, Mar 22, 2011 at 04:06:14PM -0400, Brian Schott wrote:
+1
Sounds like some IPV6 discussions back when the standards were being debated.
We could debate bit-allocation forever. Why can't we use
We can handle pagination whether we have a single database, multiple
databases with cache, or query each zone on each request. In the last
case an instance would be identified with the zone it exists in (for
example, the marker would be a fully qualified zone:instance name)
and we can just pick up
It's always a trade-off with generic vs context-specific caching. You
can usually be more efficient and provide a better UX with
context-specific caching, but it can be a bit more work.
For Nova (and any distributed application along these lines) I think
we need to use context-specific active
On Wed, Mar 16, 2011 at 06:47:03PM +, Ed Leafe wrote:
With our approach to pagination, without caching, the answer is always
correct: each query always returns the next {limit} values whose ID is =
{start-id}.
But for this example, you have to traverse *all* the zones in order
, 2011 at 01:32:55PM -0800, Eric Day wrote:
I ran the tests again to verify:
500k requests - 10 processes each running 50k requests.
time req/s cs us sy id
2 thread/proc
echo c++ 7.19 69541 142182 23 77 0
echo erlang 9.53 52465 105871 39 61 0
echo python
layer)
we can optimize specific areas.
Just for sure, might be better for someone else to recheck. That way
we have done our due diligence.
Cheers
k/
Original Message
Subject: [Openstack] Queue Service Implementation Thoughts
From: Eric
Hi everyone,
When deciding to move forward with Erlang, I first tried out the Erlang
REST framework webmachine (it is built on top of mochiweb and used
by projects like Riak). After some performance testing, I decided to
write a simple wrapper over the HTTP packet parsing built into Erlang
(also
We should support old versions. The API layers should be a very thin
layer over what the Nova internal API provides, so even if we have
v1.0, v1.1, etc. subdirectories in the API and do full code copying,
it should be a fairly minimal mapping. We can of course share as
much common code (like
Message-
From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net
[mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net]
On Behalf Of Eric Day
Sent: 03 March 2011 17:21
To: Brian Waldon
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Multiple Versions
Mellor ewan.mel...@eu.citrix.com
Sent: Thursday, March 3, 2011 4:29pm
To: Eric Day e...@oddments.org
Cc: Brian Waldon brian.wal...@rackspace.com,
openstack@lists.launchpad.net openstack@lists.launchpad.net
Subject: RE: [Openstack] Multiple Versions in Openstack API
That's fine
On Thu, Mar 03, 2011 at 12:03:28PM -0800, Vishvananda Ishaya wrote:
Rationale: Openstack components need a common solution for Authentication
(authn) and Authorization (authz). Mailing list discussions tend to devolve
into hypotheticals, so we decided to put together a proposal and prototype,
Taking this from the MP to ML for wider audience.
On Thu, Mar 03, 2011 at 11:29:43PM -, Monsyne Dragon wrote:
Actually, the OpenStack API only defines compute methods, it punts on
auth currently (as it should). There is no definitive OpenStack Auth
document or service right now, which
different services, as
Eric Day
proposes
3) Should be introduced as an extension, which can later be promoted to the
core...or not :-)
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe
On Wed, Mar 02, 2011 at 05:07:04AM -0600, Michael Barton wrote:
Swift
Swift has the concept of accounts, users, and groups. An account
contains users, and a user can belong to groups. Accounts names have an
abstraction layer, so while you may login with account example.com,
the account
things like me not knowing the intricacies of the OpenStack
database which might make my first example more difficult. Also, some people
like URLs to be readable and/or memorable.
-Original Message-
From: Eric Day e...@oddments.org
Sent: Tuesday, March 1, 2011 9:14pm
To: Justin
the user-metadata quota. Do we want to
require deployments to alter the DB schema, provide a service-metadata
table, or use reserved prefixes in the same table as user-metadata?
I'm split between the last two.
-Eric
-Original Message-
From: Eric Day e...@oddments.org
Sent: Wednesday
On Wed, Mar 02, 2011 at 10:27:33AM -0800, Justin Santa Barbara wrote:
I'm not wedded to the idea of putting service metadata into the same
collection as user metadata; it just seems like a reasonable approach to
me. *But it's more important to me that we agree on something, than that
) across
multiple accounts.
On 3/1/11 8:14 PM, Eric Day e...@oddments.org wrote:
For that query you would, but not all. If you want to create a new
instance for project1 you would:
nova.openstack.org/v1.1/project1/servers
Or if you wanted to reboot instance X in project1
I havn't seen much activity on this, so though I'd do a quick brain
dump of what I'm aware of:
Auth/global:
* Ability to lockout a user for some time period after failed auth.
* Describe zones and regions (replaced with Sandy's zone work).
Admin
* Describe instance types (list flavors).
* CRUD
Hi everyone,
I thought I'd take a moment to summarize the state of auth
in the various OpenStack projects. With the recent discussion
of OpenStack API auth in nova (bug+revert), how to structure
accounts/users/projects/etc., and with Glance and Burrow needing
auth solutions, now seems like a good
Hi Justin,
On Tue, Mar 01, 2011 at 05:14:42PM -0800, Justin Santa Barbara wrote:
However, what I don't understand is how I can query my servers in project1
and project2 (but not those in project3). *The only way I could see is
doing something like this:
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
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. :)
, great.
Sorry about that!
Gabe
On Monday, February 28, 2011 4:57pm, Eric Day e...@oddments.org said:
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
Hi Raphael,
On Sun, Feb 27, 2011 at 11:18:35AM +, Raphael Cohn wrote:
OpenStack's QueueService seems very interesting. As we have an existing
message queue implementation, we'd be happy to help you guys out. We're
about making messaging cloud-scale, so that everyone benefits.
down).
-Eric
On Fri, Feb 25, 2011 at 08:27:24AM -0600, Ed Leafe wrote:
On Feb 24, 2011, at 2:02 PM, Eric Day wrote:
I agree with Vish, I think the correct approach is 3. I have some
ideas on terminology and how to think about this. A scheduler
should not be it's own top-level service
For copyright headers, just add a new Copyright 2011 OpenStack,
LLC. line for existing files under the old copyright line. You can add
a new license for new code for existing files, but that gets messy. For
new files, just do as we usually do for new files (copyright + license
brief). You can also
In regards to openstack tools, we certainly have some options. We
could do everything from one big package with all tools for all
languages/services to one project for each language/service (and all
permutations in between). IMHO, I think it makes the most sense to
keep the client tools for all
I would encourage using all lowercase for command line tools
(oscompute), I don't really care what the name is though. :)
-Eric
On Thu, Feb 24, 2011 at 05:42:56PM +, Sandy Walsh wrote:
Perfect.
Objections? (naming bun-fights discouraged ;)
-S
I agree. I propose we always keep lp:nova (or lp:project) stable,
and instead create trunks like lp:nova/testing that all the
test/regression systems can be run against. This is pretty similar to
how we did things with Drizzle, a commit would bounce down the line,
finlly landing in lp:project when
for the full text.
-Eric
On Thu, Feb 24, 2011 at 08:20:16PM +0100, Thierry Carrez wrote:
Eric Day wrote:
For copyright headers, just add a new Copyright 2011 OpenStack,
LLC. line for existing files under the old copyright line. You can add
a new license for new code for existing files
=openstack@lists.launchpad.net] On Behalf
Of Jay Pipes
Sent: Thursday, February 24, 2011 12:20 PM
To: Eric Day
Cc: Josh Kearney; so...@openstack.org; Andy Smith;
openstack@lists.launchpad.net; John Purrier; Rick Clark
Subject: Re: [Openstack] Novatools ...
On Thu, Feb 24, 2011 at 1:00
Hi Sandy,
On Thu, Feb 24, 2011 at 07:42:34PM +, Sandy Walsh wrote:
Looks like a fun project Eric. I only got caught up on the ML this weekend
and I'm behind again already.
It's a never-ending battle. I find routing all messages from jaypipes
into /dev/null helps. :)
1. Will broadcast
On Thu, Feb 24, 2011 at 03:48:25PM -0500, Jay Pipes wrote:
I just don't want to end up with:
os-describe-images
os-describe-image-attribute
os-describe-instances
os-describe-groups
os-describe-zones
os-describe-keypairs
os-describe-volumes
os-describe-snapshots
The above is asinine,
The extra branches are just an implementation detail, we can have
them or not. It's really a matter of if it's possible and/or easier
to have jenkins fire off new jobs with arbitrary branches that need
to be merged with trunk for each job vs merging and pushing to a
staging branch and have the
++
On Thu, Feb 24, 2011 at 02:33:42PM -0800, Devin Carlen wrote:
This is a bit nitpicky but I'd rather see it called just nova, as in:
nova describe images
Who has strong opinions?
On Feb 24, 2011, at 1:30 PM, Jay Pipes wrote:
On Thu, Feb 24, 2011 at 4:06 PM, Eric Day e
of automated systems?
On Thu, Feb 24, 2011 at 4:33 PM, Eric Day e...@oddments.org wrote:
The extra branches are just an implementation detail, we can have
them or not. It's really a matter of if it's possible and/or easier
to have jenkins fire off new jobs with arbitrary branches
.
On Thu, Feb 24, 2011 at 4:41 PM, Eric Day e...@oddments.org wrote:
Yup. Right now when a project-core member clicks 'Approve'
after code review, tarmac picks it up and pushes to trunk assuming
unittests pass. Instead it could push to staging and trigger a hook
in jenkins
PM, Eric Day e...@oddments.org wrote:
That is how it works now, but if we need to run tests that are not
on the tarmac machine, we need to push that local branch somewhere
so other things can test the same thing.
Monty Taylor will have a much better idea of how
it called just nova, as in:
nova describe images
Who has strong opinions?
On Feb 24, 2011, at 1:30 PM, Jay Pipes wrote:
On Thu, Feb 24, 2011 at 4:06 PM, Eric Day e...@oddments.org wrote:
On Thu, Feb 24, 2011 at 03:48:25PM -0500, Jay Pipes wrote:
I just don't want to end up with:
os
together a sample client with tests and before
I knew it the whole server was written too. I agree now that this
helps in the process, so Andy and the other folks advocating for a
prototype were correct.
-Eric
Vish
On Feb 21, 2011, at 11:04 PM, Eric Day wrote:
I decided to implement the current
Hi everyone,
I'd like to thank every who put in their opinion on the various queue
service threads over the past couple weeks. It seems Erlang had the
most enthusiasm from the language discussions, so we'll be going with
that. We'll be able to move quickly with Erlang, which also means
we'll be
worker was
able to see them, at least until the hide value expires.
-Eric
On Sat, Feb 19, 2011 at 02:13:49PM -0500, Mark Washenberger wrote:
Can you give me some examples of the kinds of update all messages in a
queue requests you're thinking of?
Thanks,
Mark
Eric Day e...@oddments.org
Hi Todd,
That's the multicast example, for a normal 1-1 queue, look at the
first example:
Worker: POST /account/queue?wait=60hide=60detail=all
(long-polling worker, request blocks until a message is ready)
Client: PUT /account/queue
(message inserted, returns unique id that was created)
Hi Mike,
On Sat, Feb 19, 2011 at 07:42:12PM -0600, Michael Barton wrote:
On Fri, Feb 18, 2011 at 9:38 PM, Eric Day e...@oddments.org wrote:
Hi Mike,
You make a good point, I apologize for not documenting some of the
ideas sooner. The architecture I had in mind borrows from other
queue
On Fri, Feb 18, 2011 at 11:20:23AM -0600, Monsyne Dragon wrote:
Secondly, could we leverage existing opensource codebases to
accomplish this? I know AMQP was having issues over WAN links, and
likely isn't suited for disconnected operations (I've seen one
multitenant hosted queueing service
Thanks to everyone who gave great feedback on the first queue service
thread. I've updated the wiki page to include the suggestions.
http://wiki.openstack.org/QueueService
With a decent vision of what we want to build, the next step is
figuring out how. In a previous thread it was suggested that
Hi Sandy,
On Wed, Feb 16, 2011 at 06:19:52PM +, Sandy Walsh wrote:
Hmm. You wouldn't really need to re-marshall the request. Just
copy the needed headers url, and pass along the body as you received
it. Basically you are just
acting as a sort of http proxy.
On Wed, Feb 16, 2011 at 01:02:22PM -0500, Jay Pipes wrote:
[Sorry, yes the instance name is passed in on the request, but the
instance ID is what's needed (assuming of course instance ID is unique
across zones.)]
The ID is determined early in the process; well before the request
On Wed, Feb 16, 2011 at 04:33:06PM -0500, Jay Pipes wrote:
While I would agree with this most of the time, there are some cases
where optimizing later just doesn't work. Or, optimizing means
rewriting everything you've done and replacing it with something
that will scale seamlessly. I've
Hi Muriel,
On Tue, Feb 15, 2011 at 10:04:20AM +0100, Muriel wrote:
i'm completely new to openstack but i started working on something
similar to eucalyptus. In the coming months we will begin a project
to bring our work on openstack and share it with you.
Cool, looking forward to it!
The
On Sun, Feb 13, 2011 at 01:37:29PM -0500, Todd Willey wrote:
On Wed, Feb 9, 2011 at 1:38 PM, Eric Day e...@oddments.org wrote:
* Firehouse - So far we've not discussed this too much, but I
think when we did there was agreement that we need it. As more
service come into the picture, we
appropriate
for the task).
Async queues provide specialization of tasks, help lower response time,
and make horizontal scale-out much easier, among other things.
-Eric
On Mon, Feb 14, 2011 at 11:20:41AM -0700, Pete Zaitcev wrote:
On Mon, 14 Feb 2011 09:51:42 -0800
Eric Day e...@oddments.org wrote
wrote:
Eric,
Just looking at the http operations. Shouldn't the calls be around the
account then the queue?
GET /$account_id/queue/id to list all the queues
GET /$account_id/queue/id/message/id
Am I off here? Thoughts?
pvo
On 2/14/11 5:07 PM, Eric Day e...@oddments.org wrote
, they just
exist when there is an active message in it.
-Eric
On 2/14/11 5:54 PM, Eric Day e...@oddments.org wrote:
Yeah, for anonymous access that would be the case. Those are not needed
when the request comes in with OpenStack Auth headers (like nova).
Do you think we should be repeating
We can always start this as part of nova for developer convenience
until the guest agent APIs stabilize. It's trivial to break this out
into another project later on once other options start to emerge.
-Eric
On Fri, Feb 11, 2011 at 06:51:40PM +, Chris Behrens wrote:
On Feb 11, 2011, at
, but I think it's a good idea.
Keep it coming!
-Sandy
_
___
From: Eric Day [e...@oddments.org]
Sent: Wednesday, February 09, 2011 1:17 PM
To: Sandy Walsh
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Multi Clusters in a Region
On Mon, Feb 07, 2011 at 08:50:28AM -0500, Jay Pipes wrote:
No, I think you've missed my point. Comments inline...
Actually, I think I did get all your points, we're just not connecting
somewhere. :)
On Mon, Feb 7, 2011 at 12:35 AM, Eric Day e...@oddments.org wrote:
I disagree with your
be pushing events to an OpenStack firehose and let billing/audit tap
into that, but of course I'll defer to the group decision.
-Eric
On Mon, Feb 07, 2011 at 03:22:06PM -0500, Jay Pipes wrote:
On Mon, Feb 7, 2011 at 2:46 PM, Eric Day e...@oddments.org wrote:
Perhaps we can be a bit more explicit
I disagree with your disagreement. :)
When we have string based ID's like this, it doesn't need to translate
directly into a varchar column for operations. First, auth data may not
be stored as SQL at all for some systems and could be broken out into
key/value pairs with some indexed. It could
Having been a mentor before for other projects, I strongly agree
that we should do this. It's a great way to get more folks involved
in the project.
-Eric
On Fri, Feb 04, 2011 at 02:37:18PM -0600, Stephen Spector wrote:
OpenStack Developers:
Now that you have a few days off (just
I also agree, except for the last part. While you can break a test
case but not a feature, we fail at providing adequate coverage for
the feature (one of the criteria stated below). Not everyone will have
the ability to verify functionality without test cases, so we should
not depend on manual
95 matches
Mail list logo
