Open Stack

On Tue, Nov 15 2016, gordon chung wrote:

>> I'm stepping in to an area here (gnocchi) that I know very little about,
>> so please forgive me where I mess up.
>>
>> First, as a practical note, stuff in Swift will be /much/ better when
>> you spread it across the entire namespace. It's a lot better to data
>> stored in many containers instead of putting all data into just one
>> container. Spreading the data out takes advantages of Swift's scaling
>> characteristics and makes users and ops happier.
>
> thanks for the tip John! good to know the proposal might actually have 
> additional benefits.

Yup that's good to know. We do that create a container for each metric,
but not for the new measures, that we all stack into one unique
container.

> is the consistent hashing code == hashring code? we actually jacked that 
> from Ironic and used it in Ceilometer already. :) but that's a good idea 
> to leverage it in this case if we proceed. i just noticed jd adding it 
> to tooz[1].

Burned, I was going to say that!

> that's a good point. in Ceilometer, iirc we don't ever change the number 
> of buckets so we arguably didn't need it. in this case, i imagine we'd 
> need to consider overhead of creating a lot of buckets vs letting users 
> attempt to figure out what the right number of buckets is for their system.

Yeah in the case of the Swift driver for Gnocchi, I'm not really sure
how much buckets we should create. Should we make the user pick a random
number like the number of partition in Swift and then create the
containers in Swift? Or can we have something simpler? (I like automagic
things). WDYT Gordon?

And thanks John :)

-- 
Julien Danjou
# Free Software hacker
# https://julien.danjou.info
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161115/60d83160/attachment.pgp>