Jay Pipes wrote:
> On Mon, Mar 7, 2011 at 10:43 AM, Dan Prince wrote:
>> Bugs vs. Blueprints is sort of a gray area. When a larger blue print is
>> accepted (like the Openstack 1.1 API) should we file component features as
>> bugs or blueprints?
>>
>> In my case I could have easily considered th
Eric Day wrote:
> If we hit performance issues with this type of application, we'll
> probably hit them around the same time with both Erlang and Python
> (then we'll look to C/C++). Since most OpenStack developers are a lot
> more comfortable with Python, I suggest we make the switch. Please
> res
Hello everyone,
As a reminder, our weekly team meeting will take place at 21:00 UTC
this Tuesday in #openstack-meeting on IRC.
Check out how that time translates for *your* timezone:
http://timeanddate.com/s/1zc8
See the meeting agenda, edit the wiki to add new topics for discussion:
http://wiki
Agree with Eric and Thierry on this.
John
On Mar 8, 2011, at 1:09 AM, Thierry Carrez wrote:
> Eric Day wrote:
>> If we hit performance issues with this type of application, we'll
>> probably hit them around the same time with both Erlang and Python
>> (then we'll look to C/C++). Since most Open
Couple of questions.
Where did you come up with 300 bytes per message for ets?
When you say 2 threads for Erlang what do you mean? Do you mean 2 schedulers
and/or 2 run queues, Erlang processes, or Erlang vms.
I wrote a basic queue using the queue module(double ended FIFO) that was
handling a
Hi Curtis,
On Tue, Mar 08, 2011 at 04:31:59PM +, Curtis Carter wrote:
> Couple of questions.
> Where did you come up with 300 bytes per message for ets?
Raw message = key(16) + ttl(8) + hide(8) + body(100) = 132 bytes
I inserted the raw message data as the tuple {key/binary, ttl/integer,
hid
nice.
On Mar 8, 2011, at 1:14 PM, Eric Day wrote:
> Hi Curtis,
>
> On Tue, Mar 08, 2011 at 04:31:59PM +, Curtis Carter wrote:
>> Couple of questions.
>> Where did you come up with 300 bytes per message for ets?
>
> Raw message = key(16) + ttl(8) + hide(8) + body(100) = 132 bytes
>
> I inse
On 3/4/11 7:33 PM, Eric Day wrote:
On Fri, Mar 04, 2011 at 01:35:48PM -0600, Monsyne Dragon wrote:
I think, really, we are getting off on a tangent here. The purpose
of multitenant is to have a label ('account' or 'project' or
whatever ) that we tag resources (instances, etc) in nova with
so
Hi everyone,
I added a sqlite backend to the prototype and ran some tests. Initially
things were very slow, but after some further testing I was able
to figure out where the time was being spent. In order to do this I
added a very simple binary protocol interface to insert only. These
tests are wi
With this switch to python, does it make sense to revisit the concept
of openstack-common for things like logging, flag parsing, etc? What
components would you like to just be able to drop in from nova,
glance, or swift?
-todd[1]
On Tue, Mar 8, 2011 at 4:05 PM, Eric Day wrote:
> Hi everyone,
>
On Tue, Mar 08, 2011 at 04:47:38PM -0500, Todd Willey wrote:
> With this switch to python, does it make sense to revisit the concept
> of openstack-common for things like logging, flag parsing, etc? What
> components would you like to just be able to drop in from nova,
> glance, or swift?
Yes, I'
I'm sure you've seen this:
http://nichol.as/benchmark-of-python-web-servers?source=g
-S
From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of
Eric Day [e...@od
Yup, those are options we can try when we're ready to optimize.
-Eric
On Tue, Mar 08, 2011 at 10:55:34PM +, Sandy Walsh wrote:
> I'm sure you've seen this:
> http://nichol.as/benchmark-of-python-web-servers?source=g
>
> -S
>
> From: openstack-bounces
13 matches
Mail list logo
