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. Whats the concern with having replicas a part >> of the API? > > > Because they don't really make sense conceptually. Hash ring itself doesn't > actually 'make' any replicas. The replicas parameter in the current Ironic > implementation is used solely to limit the amount of buckets returned. > Conceptually, that seems to me the same as take(<replicas>, > iterate_nodes()). I don't know python internals enough to know what problems > this would cause though, can you please clarify?
I could see replicas being a parameter to a function call, but take(N, generator) has the same poor behaviour - generators in general that won't be fully consumed rely on reference counting to be freed. Sometimes thats absolutely the right tradeoff. >> its absolutely a partition of the hash space - each spot we hash a >> bucket onto is thats how consistent hashing works at all :) > > > Yes, but you don't assign the number of partitions beforehand, it depends on > the number of buckets. What you do assign is the amount of times you hash a > single bucket onto the ring, which is currently named 'replicas' in > Ceilometer code, but I suggested 'distribution_quality' or something > similarly descriptive in an earlier e-mail. I think you misunderstand the code. We do assign the number of partitions beforehand - its approximately fixed and independent of the number of buckets. More buckets == less times we hash each bucket. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev