On 09/08/2014 06:22 AM, Robert Collins wrote:
On 8 September 2014 05:57, Nejc Saje ns...@redhat.com wrote:
\
That generator API is pretty bad IMO - because it means you're very
heavily dependent on gc and refcount behaviour to keep things clean -
and there isn't (IMO) a use case for walking
On 09/04/2014 11:24 PM, Robert Collins wrote:
On 4 September 2014 23:42, Nejc Saje ns...@redhat.com wrote:
On 09/04/2014 11:51 AM, Robert Collins wrote:
It doesn't contain that term precisely, but it does talk about replicating
the buckets. What about using a descriptive name for this
On 8 September 2014 05:57, Nejc Saje ns...@redhat.com wrote:
\
That generator API is pretty bad IMO - because it means you're very
heavily dependent on gc and refcount behaviour to keep things clean -
and there isn't (IMO) a use case for walking the entire ring from the
perspective of an item.
On 09/04/2014 01:37 AM, Robert Collins wrote:
On 4 September 2014 00:13, Eoghan Glynn egl...@redhat.com wrote:
On 09/02/2014 11:33 PM, Robert Collins wrote:
The implementation in ceilometer is very different to the Ironic one -
are you saying the test you linked fails with Ironic, or that
On 4 September 2014 19:53, Nejc Saje ns...@redhat.com wrote:
I used the terms that are used in the original caching use-case, as
described in [1] and are used in the pypi lib as well[2]. With the correct
approach, there aren't actually any partitions, 'replicas' actually denotes
the number of
The implementation in ceilometer is very different to the Ironic one -
are you saying the test you linked fails with Ironic, or that it fails
with the ceilometer code today?
Disclaimer: in Ironic terms, node = conductor, key = host
The test I linked fails with Ironic hash ring
On 09/04/2014 11:51 AM, Robert Collins wrote:
On 4 September 2014 19:53, Nejc Saje ns...@redhat.com wrote:
I used the terms that are used in the original caching use-case, as
described in [1] and are used in the pypi lib as well[2]. With the correct
approach, there aren't actually any
On 4 September 2014 23:42, Nejc Saje ns...@redhat.com wrote:
On 09/04/2014 11:51 AM, Robert Collins wrote:
It doesn't contain that term precisely, but it does talk about replicating
the buckets. What about using a descriptive name for this parameter, like
'distribution_quality', where the
On 09/02/2014 11:19 PM, Gregory Haynes wrote:
Excerpts from Nejc Saje's message of 2014-09-01 07:48:46 +:
Hey guys,
in Ceilometer we're using consistent hash rings to do workload
partitioning[1]. We've considered generalizing your hash ring
implementation and moving it up to oslo, but
On 09/02/2014 11:33 PM, Robert Collins wrote:
The implementation in ceilometer is very different to the Ironic one -
are you saying the test you linked fails with Ironic, or that it fails
with the ceilometer code today?
Disclaimer: in Ironic terms, node = conductor, key = host
The test I
Sorry, forgot to link the reference:
[1]
https://github.com/openstack/ironic/blob/b56db42aa39e855e558a52eb71e656ea14380f8a/ironic/common/hash_ring.py#L72
On 09/03/2014 01:50 PM, Nejc Saje wrote:
On 09/02/2014 11:33 PM, Robert Collins wrote:
The implementation in ceilometer is very
On 09/02/2014 11:33 PM, Robert Collins wrote:
The implementation in ceilometer is very different to the Ironic one -
are you saying the test you linked fails with Ironic, or that it fails
with the ceilometer code today?
Disclaimer: in Ironic terms, node = conductor, key = host
The
On Wed, Sep 3, 2014 at 12:50 PM, Nejc Saje ns...@redhat.com wrote:
On 09/02/2014 11:33 PM, Robert Collins wrote:
The implementation in ceilometer is very different to the Ironic one -
are you saying the test you linked fails with Ironic, or that it fails
with the ceilometer code today?
On 3 September 2014 23:50, Nejc Saje ns...@redhat.com wrote:
Forgive my slowness :).
Disclaimer: in Ironic terms, node = conductor, key = host
Sadly not inside the hash_ring code :/. host == conductor, key == data.
The test I linked fails with Ironic hash ring code (specifically the part
On 4 September 2014 00:13, Eoghan Glynn egl...@redhat.com wrote:
On 09/02/2014 11:33 PM, Robert Collins wrote:
The implementation in ceilometer is very different to the Ironic one -
are you saying the test you linked fails with Ironic, or that it fails
with the ceilometer code today?
On 4 September 2014 08:13, Robert Collins robe...@robertcollins.net wrote:
On 3 September 2014 23:50, Nejc Saje ns...@redhat.com wrote:
Forgive my slowness :).
Disclaimer: in Ironic terms, node = conductor, key = host
Sadly not inside the hash_ring code :/. host == conductor, key == data.
Excerpts from Nejc Saje's message of 2014-09-01 07:48:46 +:
Hey guys,
in Ceilometer we're using consistent hash rings to do workload
partitioning[1]. We've considered generalizing your hash ring
implementation and moving it up to oslo, but unfortunately your
implementation is not
Hey guys,
in Ceilometer we're using consistent hash rings to do workload
partitioning[1]. We've considered generalizing your hash ring
implementation and moving it up to oslo, but unfortunately your
implementation is not actually consistent, which is our requirement.
Since you divide your
18 matches
Mail list logo
