Concurrency is hard, let's blame the tools!
Any lib that we use in python is going to have a set of trade-offs.
Looking at a couple of the options on the table:
1. Threads: Great! code doesn't have to change too much, but now that
code *will* be preempted at any time, so now we have to worry a
Hi Shyam,
If I am reading your ring output correctly, it looks like only the devices
in node .202 have a weight set, and thus why all of your objects are going
to that one node. You can update the weight of the other devices, and
rebalance, and things should get distributed correctly.
--
Chuck
There is a review for swift [1] that is requesting to set the max header
size to 16k to be able to support v3 keystone tokens. That might be fine
if you measure you request rate in requests per minute, but this is
continuing to add significant overhead to swift. Even if you *only* have
10,000 req
Just a FYI for those interested in the next eventlet version. It also
looks like they have a python 3 branch ready to start testing with.
--
Chuck
-- Forwarded message --
From: Sergey Shepelev
Date: Fri, Jun 13, 2014 at 1:18 PM
Subject: [Eventletdev] Eventlet 0.15 pre-release te
>
>
> I agree this is quite an issue but I also think that pretending that
> we'll be able to let OpenStack grow with a minimum set of databases,
> brokers and web servers is a bit unrealistic. The set of supported
> technologies won't be able to fulfill the needs of all the
> yet-to-be-discovered
Howdy,
Now that swift has aligned with the other projects to use requests in
python-swiftclient, we have lost a couple of features.
1. Requests doesn't support expect: 100-continue. This is very useful for
services like swift or glance where you want to make sure a request can
continue before y
On Fri, Apr 4, 2014 at 9:44 AM, Donald Stufft wrote:
> requests should work fine if you used the event let monkey patch the
> socket module prior to import requests.
>
That's what I had hoped as well (and is what swift-bench did already), but
it performs the same if I monkey patch or not.
--
Ch
On Fri, Apr 4, 2014 at 11:18 AM, Donald Stufft wrote:
>
> On Apr 4, 2014, at 10:56 AM, Chuck Thier wrote:
>
> On Fri, Apr 4, 2014 at 9:44 AM, Donald Stufft wrote:
>
>> requests should work fine if you used the event let monkey patch the
>> socket module prior to imp
else looked into that?
--
Chuck
On Fri, Apr 4, 2014 at 9:41 AM, Chuck Thier wrote:
> Howdy,
>
> Now that swift has aligned with the other projects to use requests in
> python-swiftclient, we have lost a couple of features.
>
> 1. Requests doesn't support expect: 100-
I'm with Chmouel though. It seems to me that EC policy should be chosen by
the provider and not the client. For public storage clouds, I don't think
you can make the assumption that all users/clients will understand the
storage/latency tradeoffs and benefits.
On Thu, Jul 18, 2013 at 8:11 AM, Jo
ves users the
> ability to flexibly store their data with a nice interface yet still have
> the ability to get at some of the pokey bits underneath.
>
> --John
>
>
>
> On Jul 18, 2013, at 10:31 AM, Chuck Thier wrote:
>
> > I'm with Chmouel though. It seems
I think most are missing the point a bit. The question that should really
be asked is, what is right for Swift to continue to scale. Since the
inception of Openstack, Swift has had to solve for problems of scale that
generally are not shared with the rest of Openstack.
When we first set out to w
12 matches
Mail list logo
