Re: [openstack-dev] [Ceilometer] Why alarm name is unique per project?
On 09/24/2014 12:23 PM, Long Suo wrote: Hi, all I am just a little confused why alarm name should be unique per project, anyone knows this? Good point, I admit I can't find a compelling reason for that either. Perhaps someone else can? Also, an interesting use-case comes to mind, where you can have for example an alarm for each instance, all of them named 'cpu_alarm', but with unique action per instance. You could then retrieve all these alarms at once with a proper query. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] (Non-)consistency of the Ironic hash ring implementation
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 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. Ok, I can agree with it being a function call. 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. Ah, your first sentence tipped me off that we're not actually speaking about the same code :). I'm talking about current Ceilometer code and the way the algorithm is described in the original paper. There, the number of times we hash a bucket doesn't depend on the number of buckets at all. The implementation with an array that Ironic used to have definitely needed to define the number of partition, but I don't see the need for it with the new approach as well. Why would you want to limit yourself to a fixed number of partitions if you're limited only by the output range of the hash function? Cheers, Nejc -Rob ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Swift] (Non-)consistency of the Swift hash ring implementation
That's great to hear! I see now that Swift's implementation has some
additional rebalancing logic that Ironic (and the code example from
Gregory's blog) lacked.
Cheers,
Nejc
On 09/08/2014 05:39 AM, John Dickinson wrote:
To test Swift directly, I used the CLI tools that Swift provides for managing
rings. I wrote the following short script:
$ cat remakerings
#!/bin/bash
swift-ring-builder object.builder create 16 3 0
for zone in {1..4}; do
for server in {200..224}; do
for drive in {1..12}; do
swift-ring-builder object.builder add
r1z${zone}-10.0.${zone}.${server}:6010/d${drive} 3000
done
done
done
swift-ring-builder object.builder rebalance
This adds 1200 devices. 4 zones, each with 25 servers, each with 12 drives
(4*25*12=1200). The important thing is that instead of adding 1000 drives in
one zone or in one server, I'm splaying across the placement hierarchy that
Swift uses.
After running the script, I added one drive to one server to see what the
impact would be and rebalanced. The swift-ring-builder tool detected that less
than 1% of the partitions would change and therefore didn't move anything (just
to avoid unnecessary data movement).
--John
On Sep 7, 2014, at 11:20 AM, Nejc Saje ns...@redhat.com wrote:
Hey guys,
in Ceilometer we're using consistent hash rings to do workload
partitioning[1]. We've considered using Ironic's hash ring implementation, but
found out it wasn't actually consistent (ML[2], patch[3]). The next thing I
noticed that the Ironic implementation is based on Swift's.
The gist of it is: since you divide your ring into a number of equal sized
partitions, instead of hashing hosts onto the ring, when you add a new host, an
unbound amount of keys get re-mapped to different hosts (instead of the
1/#nodes remapping guaranteed by hash ring).
Swift's hash ring implementation is quite complex though, so I took the
conceptually similar code from Gregory Holt's blogpost[4] (which I'm guessing
is based on Gregory's efforts on Swift's hash ring implementation) and tested
that instead. With a simple test (paste[5]) of first having 1000 nodes and then
adding 1, 99.91% of the data was moved.
I have no way to test this in Swift directly, so I'm just throwing this out
there, so you guys can figure out whether there actually is a problem or not.
Cheers,
Nejc
[1] https://review.openstack.org/#/c/113549/
[2]
http://lists.openstack.org/pipermail/openstack-dev/2014-September/044566.html
[3] https://review.openstack.org/#/c/118932/4
[4] http://greg.brim.net/page/building_a_consistent_hashing_ring.html
[5] http://paste.openstack.org/show/107782/
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] (Non-)consistency of the Ironic hash ring implementation
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 parameter, like 'distribution_quality', where the higher the value, higher the distribution evenness (and higher memory usage)? I've no objection talking about keys, but 'node' is an API object in Ironic, so I'd rather we talk about hosts - or make it something clearly not node like 'bucket' (which the 1997 paper talks about in describing consistent hash functions). So proposal: - key - a stringifyable thing to be mapped to buckets What about using the term 'item' from the original paper as well? Sure. Item it is. - bucket a worker/store that wants keys mapped to it - replicas - number of buckets a single key wants to be mapped to Can we keep this as an Ironic-internal parameter? Because it doesn't really affect the hash ring. If you want multiple buckets for your item, you just continue your journey along the ring and keep returning new buckets. Check out how the pypi lib does it: https://github.com/Doist/hash_ring/blob/master/hash_ring/ring.py#L119 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? - partitions - number of total divisions of the hash space (power of 2 required) I don't think there are any divisions of the hash space in the correct implementation, are there? I think that in the current Ironic implementation this tweaks the distribution quality, just like 'replicas' parameter in Ceilo implementation. 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. Cheers, Nejc -Rob ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Swift] (Non-)consistency of the Swift hash ring implementation
Hey guys, in Ceilometer we're using consistent hash rings to do workload partitioning[1]. We've considered using Ironic's hash ring implementation, but found out it wasn't actually consistent (ML[2], patch[3]). The next thing I noticed that the Ironic implementation is based on Swift's. The gist of it is: since you divide your ring into a number of equal sized partitions, instead of hashing hosts onto the ring, when you add a new host, an unbound amount of keys get re-mapped to different hosts (instead of the 1/#nodes remapping guaranteed by hash ring). Swift's hash ring implementation is quite complex though, so I took the conceptually similar code from Gregory Holt's blogpost[4] (which I'm guessing is based on Gregory's efforts on Swift's hash ring implementation) and tested that instead. With a simple test (paste[5]) of first having 1000 nodes and then adding 1, 99.91% of the data was moved. I have no way to test this in Swift directly, so I'm just throwing this out there, so you guys can figure out whether there actually is a problem or not. Cheers, Nejc [1] https://review.openstack.org/#/c/113549/ [2] http://lists.openstack.org/pipermail/openstack-dev/2014-September/044566.html [3] https://review.openstack.org/#/c/118932/4 [4] http://greg.brim.net/page/building_a_consistent_hashing_ring.html [5] http://paste.openstack.org/show/107782/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] (Non-)consistency of the Ironic hash ring implementation
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 it fails with the ceilometer code today? Disclaimer: in Ironic terms, node = conductor, key = host The test I linked fails with Ironic hash ring code (specifically the part that tests consistency). With 1000 keys being mapped to 10 nodes, when you add a node: - current ceilometer code remaps around 7% of the keys ( 1/#nodes) - Ironic code remaps 90% of the keys So just to underscore what Nejc is saying here ... The key point is the proportion of such baremetal-nodes that would end up being re-assigned when a new conductor is fired up. That was 100% clear, but thanks for making sure. The question was getting a proper understanding of why it was happening in Ironic. The ceilometer hashring implementation is good, but it uses the same terms very differently (e.g. replicas for partitions) - I'm adapting the key fix back into Ironic - I'd like to see us converge on a single implementation, and making sure the Ironic one is suitable for ceilometer seems applicable here (since ceilometer seems to need less from the API), 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 hash a node onto the ring. As for nodeskeys, what's your suggestion? I've opened a bug[3], so you can add a Closes-Bug to your patch. [1] http://www.martinbroadhurst.com/Consistent-Hash-Ring.html [2] https://pypi.python.org/pypi/hash_ring [3] https://bugs.launchpad.net/ironic/+bug/1365334 If reassigning was cheap Ironic wouldn't have bothered having a hash ring :) -Rob ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] (Non-)consistency of the Ironic hash ring implementation
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 partitions, 'replicas' actually denotes the number of times you hash a node onto the ring. As for nodeskeys, what's your suggestion? So - we should change the Ironic terms then, I suspect (but lets check with Deva who wrote the original code where he got them from). The parameters we need to create a ring are: - how many fallback positions we use for data (currently referred to as replicas) - how many times we hash the servers hosting data into the ring (currently inferred via the hash_partition_exponent / server count) - the servers and then we probe data items as we go. The original paper isn't http://www.martinbroadhurst.com/Consistent-Hash-Ring.html - http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.147.1879 is referenced by it, and that paper doesn't include the term replica count at all. In other systems like cassandra, replicas generally refers to how many servers end up holding a copy of the data: Martin Broadhurts paper uses replica there in quite a different sense - I much prefer the Ironic use, which says how many servers will be operating on the data: its externally relevant. 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 value, higher the distribution evenness (and higher memory usage)? I've no objection talking about keys, but 'node' is an API object in Ironic, so I'd rather we talk about hosts - or make it something clearly not node like 'bucket' (which the 1997 paper talks about in describing consistent hash functions). So proposal: - key - a stringifyable thing to be mapped to buckets What about using the term 'item' from the original paper as well? - bucket a worker/store that wants keys mapped to it - replicas - number of buckets a single key wants to be mapped to Can we keep this as an Ironic-internal parameter? Because it doesn't really affect the hash ring. If you want multiple buckets for your item, you just continue your journey along the ring and keep returning new buckets. Check out how the pypi lib does it: https://github.com/Doist/hash_ring/blob/master/hash_ring/ring.py#L119 - partitions - number of total divisions of the hash space (power of 2 required) I don't think there are any divisions of the hash space in the correct implementation, are there? I think that in the current Ironic implementation this tweaks the distribution quality, just like 'replicas' parameter in Ceilo implementation. Cheers, Nejc I've opened a bug[3], so you can add a Closes-Bug to your patch. Thanks! -Rob ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] (Non-)consistency of the Ironic hash ring implementation
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 unfortunately your implementation is not actually consistent, which is our requirement. Since you divide your ring into a number of equal sized partitions, instead of hashing hosts onto the ring, when you add a new host, an unbound amount of keys get re-mapped to different hosts (instead of the 1/#nodes remapping guaranteed by hash ring). I've confirmed this with the test in aforementioned patch[2]. I am just getting started with the ironic hash ring code, but this seems surprising to me. AIUI we do require some rebalancing when a conductor is removed or added (which is normal use of a CHT) but not for every host added. This is supported by the fact that we currently dont have a rebalancing routine, so I would be surprised if ironic worked at all if we required it for each host that is added. Sorry, I used terms that are used in the distributed caching use-case for hash-rings (which is why this algorithm was developed), where you have hosts and keys, and hash-ring tells you which host the key is on. To translate the original e-mail into Ironic use-case, where you have hosts being mapped to conductors: Since you divide your ring into a number of equal sized partitions instead of hashing *conductors* onto the ring, when you add a new *host*, an unbound amount of *hosts* get re-mapped to different *conductors* (instead of the 1/#*conductors* of *hosts* being re-mapped guaranteed by hash ring). I've confirmed this with the test in aforementioned patch[2]. Cheers, Nejc Can anyone in Ironic with a bit more experience confirm/deny this? If this is good enough for your use-case, great, otherwise we can get a generalized hash ring implementation into oslo for use in both projects or we can both use an external library[3]. Cheers, Nejc [1] https://review.openstack.org/#/c/113549/ [2] https://review.openstack.org/#/c/113549/21/ceilometer/tests/test_utils.py [3] https://pypi.python.org/pypi/hash_ring Thanks, Greg ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] (Non-)consistency of the Ironic hash ring implementation
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 linked fails with Ironic hash ring code (specifically the
part that tests consistency). With 1000 keys being mapped to 10 nodes,
when you add a node:
- current ceilometer code remaps around 7% of the keys ( 1/#nodes)
- Ironic code remaps 90% of the keys
The problem lies in the way you build your hash ring[1]. You initialize
a statically-sized array and divide its fields among nodes. When you do
a lookup, you check which field in the array the key hashes to and then
return the node that that field belongs to. This is the wrong approach
because when you add a new node, you will resize the array and assign
the fields differently, but the same key will still hash to the same
field and will therefore hash to a different node.
Nodes must be hashed onto the ring as well, statically chopping up the
ring and dividing it among nodes isn't enough for consistency.
Cheers,
Nejc
The Ironic hash_ring implementation uses a hash:
def _get_partition(self, data):
try:
return (struct.unpack_from('I', hashlib.md5(data).digest())[0]
self.partition_shift)
except TypeError:
raise exception.Invalid(
_(Invalid data supplied to HashRing.get_hosts.))
so I don't see the fixed size thing you're referring to. Could you
point a little more specifically? Thanks!
-Rob
On 1 September 2014 19:48, Nejc Saje ns...@redhat.com wrote:
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 ring into a number of equal sized partitions, instead
of hashing hosts onto the ring, when you add a new host,
an unbound amount of keys get re-mapped to different hosts (instead of the
1/#nodes remapping guaranteed by hash ring). I've confirmed this with the
test in aforementioned patch[2].
If this is good enough for your use-case, great, otherwise we can get a
generalized hash ring implementation into oslo for use in both projects or
we can both use an external library[3].
Cheers,
Nejc
[1] https://review.openstack.org/#/c/113549/
[2]
https://review.openstack.org/#/c/113549/21/ceilometer/tests/test_utils.py
[3] https://pypi.python.org/pypi/hash_ring
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] (Non-)consistency of the Ironic hash ring implementation
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 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 code (specifically the
part that tests consistency). With 1000 keys being mapped to 10 nodes,
when you add a node:
- current ceilometer code remaps around 7% of the keys ( 1/#nodes)
- Ironic code remaps 90% of the keys
The problem lies in the way you build your hash ring[1]. You initialize
a statically-sized array and divide its fields among nodes. When you do
a lookup, you check which field in the array the key hashes to and then
return the node that that field belongs to. This is the wrong approach
because when you add a new node, you will resize the array and assign
the fields differently, but the same key will still hash to the same
field and will therefore hash to a different node.
Nodes must be hashed onto the ring as well, statically chopping up the
ring and dividing it among nodes isn't enough for consistency.
Cheers,
Nejc
The Ironic hash_ring implementation uses a hash:
def _get_partition(self, data):
try:
return (struct.unpack_from('I',
hashlib.md5(data).digest())[0]
self.partition_shift)
except TypeError:
raise exception.Invalid(
_(Invalid data supplied to HashRing.get_hosts.))
so I don't see the fixed size thing you're referring to. Could you
point a little more specifically? Thanks!
-Rob
On 1 September 2014 19:48, Nejc Saje ns...@redhat.com wrote:
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 ring into a number of equal sized partitions,
instead
of hashing hosts onto the ring, when you add a new host,
an unbound amount of keys get re-mapped to different hosts (instead
of the
1/#nodes remapping guaranteed by hash ring). I've confirmed this with
the
test in aforementioned patch[2].
If this is good enough for your use-case, great, otherwise we can get a
generalized hash ring implementation into oslo for use in both
projects or
we can both use an external library[3].
Cheers,
Nejc
[1] https://review.openstack.org/#/c/113549/
[2]
https://review.openstack.org/#/c/113549/21/ceilometer/tests/test_utils.py
[3] https://pypi.python.org/pypi/hash_ring
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ironic] (Non-)consistency of the Ironic hash ring implementation
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 ring into a number of equal sized partitions, instead of hashing hosts onto the ring, when you add a new host, an unbound amount of keys get re-mapped to different hosts (instead of the 1/#nodes remapping guaranteed by hash ring). I've confirmed this with the test in aforementioned patch[2]. If this is good enough for your use-case, great, otherwise we can get a generalized hash ring implementation into oslo for use in both projects or we can both use an external library[3]. Cheers, Nejc [1] https://review.openstack.org/#/c/113549/ [2] https://review.openstack.org/#/c/113549/21/ceilometer/tests/test_utils.py [3] https://pypi.python.org/pypi/hash_ring ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [CEILOMETER] Trending Alarm
On 08/28/2014 08:07 PM, Henrique Truta wrote: Hello, everyone! I want to have an alarm that is triggered by some kind of trend. For example, an alarm that is triggeredwhen the CPU utilization is growing steadly (for example, has grown approximately 10% per 5 minutes, where the percentage and time window would be parameters, but then I would evaluate also more complex forms to compute trends).Is there any way to do this kind of task? I took a brief look on the code and saw that new evaluators can be created. So, I thought about two possibilities: the former includes creating a new Evaluator that considers a given window size and the latter considers on adding a change rate comparator, which will enable to set the growth rate as the threshold. What do you think about it? What about adding a new rate_of_change transformer on the cpu_util samples? http://docs.openstack.org/developer/ceilometer/configuration.html#rate-of-change-transformer That way you would have a new meter that denotes the rate-of-change of the cpu utilization and could set up alarms on that. Cheers, Nejc Best Regards ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] repackage ceilometer and ceilometerclient
But I'm not sure the real problem to move the modules. My understanding is - the ceilometer package has dependency with ceilometerclient so it is easy to move them - all callers for using the moved modules must change paths. The modules you are talking about are part of Ceilometer's core functionality, we can't move them to a completely separate code-tree that is meant only for client functionality. Besides the conceptual difference, python-ceilometerclient is not tightly coupled with Ceilometer and has its own release schedule among other things. Regards, Nejc ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] repackage ceilometer and ceilometerclient
On 08/21/2014 07:50 AM, Osanai, Hisashi wrote: Folks, I wrote the following BP regarding repackaging ceilometer and ceilometerclient. https://blueprints.launchpad.net/ceilometer/+spec/repackaging-ceilometerclient I need to install the ceilometer package when the swift_middlware middleware uses. And the ceilometer package has dependencies with the following: - requirements.txt in the ceilometer package ... python-ceilometerclient=1.0.6 python-glanceclient=0.13.1 python-keystoneclient=0.9.0 python-neutronclient=2.3.5,3 python-novaclient=2.17.0 python-swiftclient=2.0.2 ... From maintenance point of view, these dependencies are undesirable. What do you think? I don't think there's any way the modules you mention in the BP can be moved into ceilometerclient. I think the best approach to resolve this would be to rewrite swift middleware to use oslo.messaging notifications, as discussed here: http://lists.openstack.org/pipermail/openstack-dev/2014-July/041628.html Cheers, Nejc ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer][WSME] Sphinx failing sporadically because of wsme autodoc extension
Yesterday, doc builds started failing sporadically in Ceilometer gate. http://logstash.openstack.org/#eyJzZWFyY2giOiJcIkVSUk9SOiBJbnZvY2F0aW9uRXJyb3I6ICcvaG9tZS9qZW5raW5zL3dvcmtzcGFjZS9nYXRlLWNlaWxvbWV0ZXItZG9jcy8udG94L3ZlbnYvYmluL3B5dGhvbiBzZXR1cC5weSBidWlsZF9zcGhpbngnXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjE3MjgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MDg2MjQwMjcyMDF9 Can someone with more Sphinx-fu than me figure out why Sphinx is using a wsme extension where there is no wsme code? (The build fails when processing ceilometer.alarm module, example of a successful build: https://jenkins02.openstack.org/job/gate-ceilometer-docs/4412/consoleFull Cheers, Nejc ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] indicating sample provenance
On 08/20/2014 09:25 PM, Chris Dent wrote: On Wed, 20 Aug 2014, gordon chung wrote: disclaimer: i'm just riffing and the following might be nonsense. /me is a huge fan of riffing i guess also to extend your question about agents leaving/joining. i'd expect there is some volatility to the agents where an agent may or may not exist at the point of debugging... just curious what the benefit is of knowing who sent it if all the agents are just clones of each other. What I'm thinking of is situation where some chunk of samples is arriving at the data store and is in some fashion outside the expected norms when compared to others. If, from looking at the samples, you can tell that they were all published from the (used-to-be-)central-agent on host X then you can go to host X and have a browse around there to see what might be up. It's unlikely that the agent is going to be the cause of any weirdness but if it _is_ then we'd like to be able to locate it. As things currently stand there's no way, from the sample itself, to do so. Thus, the benefit of knowing who sent it is that though the agents themselves are clones, they are in regions and on hosts that are not. Beyond all those potentially good reasons there's also just the simple matter that it is good data hygiene to know where stuff came from? More riffing: we are moving away from per-sample specific data with Gnocchi. I don't think we should store this per-sample, since the user doesn't actually care about which agent the sample came from. The user cares about which *resource* it came from. I could see this going into an agent's log. On each polling cycle, we could log which *resources* we are responsible (not samples). Cheers, Nejc ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer] Approximate alarming
Hey everyone! I’d like to get your gut reaction on an idea for the future of alarming. Should I or should I not put it up for debate at the design summit? ---TL;DR Online algorithms for computing stream statistics over sliding windows would allow us to provide sample statistics within an error bound (e.g. The average cpu utilization in the last hour was 85% +/- 1%”), while significantly reducing the load and memory requirements of the computation. — Alarm evaluation currently recalculates the aggregate values each time the alarm is evaluated, which is problematic because of the load it puts on the system. There have been multiple ideas on how to solve this problem, from precalculating aggregate values (https://wiki.openstack.org/wiki/Ceilometer/Alerting#Precalculation_of_aggregate_values) to re-architecting the alarms into the sample pipeline (https://wiki.openstack.org/wiki/Ceilometer/AlarmImprovements). While Sandy's suggestions make sense from the performance viewpoint, the problem of scalability remains. Samples in the pipeline need to be kept in-memory for the whole evaluation window, which requires O(N) memory for a window of size N. We could tackle this problem by using cutting edge research in streaming algorithms, namely the papers by Datar et al. [1], and Arasu et al. [2]. They provide algorithms for computing stream statistics over sliding windows, such as *count, avg, min, max* and even *percentile*, **online** and with polylogarithmic space requirements. The tradeoff is of course precision, but the algorithms are bounded on the relative error - which could be specified by the user. If we can tell the user The average cpu utilization in the last hour was 85% +/- 1%, would that not be enough for most use cases, while severely reducing the load on the system? We could still support *error_rate=0*, which would simply use O(N) space and provide a precise answer for the cases where such an answer is needed. These algorithms were developed with telcos and computer network monitoring in mind, in which information about current network performance—latency, bandwidth, etc.—is generated online and is used to monitor and adjust network performance dynamically[1]. IIUC the main user of alarms is Heat autoscaling, which is exactly the kind of problem suitable to 'soft' calculations, with a certain tolerance for error. [1] Datar, Mayur, et al. Maintaining stream statistics over sliding windows. *SIAM Journal on Computing* 31.6 (2002): 1794-1813. PDF @ http://ilpubs.stanford.edu:8090/504/1/2001-34.pdf [2] Arasu, Arvind, and Gurmeet Singh Manku. Approximate counts and quantiles over sliding windows. *Proceedings of the twenty-third ACM SIGMOD-SIGACT-SIGART symposium on Principles of database systems.* ACM, 2004. PDF @ http://ilpubs.stanford.edu:8090/624/1/2003-72.pdf signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer]
Hi,
quickly said, you can use the client API with something like:
import keystoneclient.v2_0.client as ksclient
creds = {‘username’:’demo’, ‘password’:’password’, ‘auth_url’:’keystone
auth url’, ‘tenant_name’:’demo’}
keystone = ksclient.Client(**creds)
import ceilometerclient.v2.client as cclient
ceilometer = cclient.Client(token=lambda: keystone.auth_token,
endpoint=config.get('OpenStack',
'ceilometer_endpoint’))
Cheers,
Nejc
On Apr 17, 2014, at 6:52 PM, Hachem Chraiti hachem...@gmail.com wrote:
Hi ,
how to authenticate against openstack's Ceilometer Client using python
program?
plase i need response please
Sincerly ,
Chraiti Hachem
software enginee
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer][qa] Tenant isolation - IntegrityError exception
Hey, still trying to get https://review.openstack.org/#/c/39237/ through the gate :) As per David Kranz's request, I am now handling client isolation, but about 50% of the time the tests fail because of an integrity error, see http://logs.openstack.org/37/39237/13/check/check-tempest-devstack-vm-full/53c0fc1/console.html.gz . The tenant does get created in keystone and the ids do match up, so I have no clue what is causing this. Any ideas? Cheers, Nejc ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer] Another introduction
Hey everyone, I'm a developer at XLAB d.o.o. in Ljubljana. My colleagues are part of the EU research project Contrail, dealing with cloud federation, and I got hired to work on Contrail-Openstack integration. Firstly I'm trying to integrate alarming and since alarming in Ceilometer is still a work in progress, I'm free to work on Ceilometer :) I've already familiarized myself with the code a bit, any suggestions what I could help with? Perhaps something with the alarm or alarm audit API? Cheers! Nejc ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
