On 09/08/2014 06:22 AM, Robert Collins wrote:
On 8 September 2014 05:57, Nejc Saje 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 fr
On 8 September 2014 05:57, Nejc Saje 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. Whats th
On 09/04/2014 11:24 PM, Robert Collins wrote:
On 4 September 2014 23:42, Nejc Saje 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
'di
On 4 September 2014 23:42, Nejc Saje 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 higher the v
On 09/04/2014 11:51 AM, Robert Collins wrote:
On 4 September 2014 19:53, Nejc Saje 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'
> >> > 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
On 4 September 2014 19:53, Nejc Saje 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 times you ha
On 09/04/2014 01:37 AM, Robert Collins wrote:
On 4 September 2014 00:13, Eoghan Glynn 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
On 4 September 2014 08:13, Robert Collins wrote:
> On 3 September 2014 23:50, Nejc Saje 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 I
On 4 September 2014 00:13, Eoghan Glynn 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?
>>
>> Dis
On 3 September 2014 23:50, Nejc Saje 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
> that tests consi
On Wed, Sep 3, 2014 at 12:50 PM, Nejc Saje 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?
>
>
> Disc
> 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
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 differen
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 lin
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 unf
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?
The Ironic hash_ring implementation uses a hash:
def _get_partition(self, data):
try:
return (struct
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 no
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 ri
19 matches
Mail list logo
