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
18 matches
Mail list logo