Re: [openstack-dev] [Ceilometer] [Heat] Ceilometer aware people, please advise us on processing notifications..
This may be out of scope, but as a developer of an external tool that works with OpenStack we would love an external interface to get this kind of information more efficiently. Today we poll the state of all resources periodically which is a pretty heavy operation. Ideally any work done for internal notification would be able to be leveraged for such an external API in the future. On Thu, Jun 26, 2014 at 5:34 PM, Randall Burt randall.b...@rackspace.com wrote: On Jun 26, 2014, at 5:25 PM, Zane Bitter zbit...@redhat.com wrote: On 23/06/14 19:25, Clint Byrum wrote: Hello! I would like to turn your attention to this specification draft that I've written: https://review.openstack.org/#/c/100012/1/specs/convergence-continuous-observer.rst Angus has suggested that perhaps Ceilometer is a better place to handle this. Can you please comment on the review, or can we have a brief mailing list discussion about how best to filter notifications? Basically in Heat when a user boots an instance, we would like to act as soon as it is active, and not have to poll the nova API to know when that is. Angus has suggested that perhaps we can just tell ceilometer to hit Heat with a web hook when that happens. I'm all in favour of having Ceilometer filter the firehose for us if we can :) Webhooks would seem to add a lot of overhead though (set up + tear down a connection for every notification), that could perhaps be avoided by using a message bus? Given that both setting up and receiving these notifications would be admin-only operations, is there any benefit to handling them through a webhook API rather than through oslo.messaging? cheers, Zane. In larger OpenStack deployments, the different services probably don't share the same message bus. While I certainly agree oslo.messaging and/or oslo.notifications should be an option (and probably the default one at that), I think there should still be an option to use ceilometer or some other notification mechanism. As long as its pluggable, I don't think anyone would be too fussed. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Andrew Mann DivvyCloud Inc. www.divvycloud.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] [Heat] Ceilometer aware people, please advise us on processing notifications..
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24/06/14 09:28, Clint Byrum wrote: Hello! I would like to turn your attention to this specification draft that I've written: https://review.openstack.org/#/c/100012/1/specs/convergence-continuous-observer.rst Angus has suggested that perhaps Ceilometer is a better place to handle this. Can you please comment on the review, or can we have a brief mailing list discussion about how best to filter notifications? Basically in Heat when a user boots an instance, we would like to act as soon as it is active, and not have to poll the nova API to know when that is. Angus has suggested that perhaps we can just tell ceilometer to hit Heat with a web hook when that happens. We could have a per-resource webhook (either the signal or something like it) that is just a logical notification/kick to go and re-check the resource state. The other part of this is when we turn on continuous convergence, we could get an alarm whenever that resource changes state (or what ever we are interested in - as long as it is in the notification payload). Given the number of resources we want to manage the alarm sub-system will need to be scalable. I'd rather Ceilometer solve that than Heat. When we talked about that issue in Atlanta, I think we came to the conclusion that one system wouldn't solve it, and that we need to be able to provide different pluggable solutions. The first solution is just to move the current polling system and create a generic API around it. That's something that we'll want to keep, even if it's only to make standalone mode works. The next solution for me is to subscribe directly to the notification system. We know the shortcomings, but it's the obvious improvement we can do in the Juno cycle. Later on, if/when Ceilometer provides what we need, we can implement a new backend using it. -- Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] [Heat] Ceilometer aware people, please advise us on processing notifications..
On 23/06/14 19:25, Clint Byrum wrote: Hello! I would like to turn your attention to this specification draft that I've written: https://review.openstack.org/#/c/100012/1/specs/convergence-continuous-observer.rst Angus has suggested that perhaps Ceilometer is a better place to handle this. Can you please comment on the review, or can we have a brief mailing list discussion about how best to filter notifications? Basically in Heat when a user boots an instance, we would like to act as soon as it is active, and not have to poll the nova API to know when that is. Angus has suggested that perhaps we can just tell ceilometer to hit Heat with a web hook when that happens. I'm all in favour of having Ceilometer filter the firehose for us if we can :) Webhooks would seem to add a lot of overhead though (set up + tear down a connection for every notification), that could perhaps be avoided by using a message bus? Given that both setting up and receiving these notifications would be admin-only operations, is there any benefit to handling them through a webhook API rather than through oslo.messaging? cheers, Zane. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] [Heat] Ceilometer aware people, please advise us on processing notifications..
On Jun 26, 2014, at 5:25 PM, Zane Bitter zbit...@redhat.com wrote: On 23/06/14 19:25, Clint Byrum wrote: Hello! I would like to turn your attention to this specification draft that I've written: https://review.openstack.org/#/c/100012/1/specs/convergence-continuous-observer.rst Angus has suggested that perhaps Ceilometer is a better place to handle this. Can you please comment on the review, or can we have a brief mailing list discussion about how best to filter notifications? Basically in Heat when a user boots an instance, we would like to act as soon as it is active, and not have to poll the nova API to know when that is. Angus has suggested that perhaps we can just tell ceilometer to hit Heat with a web hook when that happens. I'm all in favour of having Ceilometer filter the firehose for us if we can :) Webhooks would seem to add a lot of overhead though (set up + tear down a connection for every notification), that could perhaps be avoided by using a message bus? Given that both setting up and receiving these notifications would be admin-only operations, is there any benefit to handling them through a webhook API rather than through oslo.messaging? cheers, Zane. In larger OpenStack deployments, the different services probably don't share the same message bus. While I certainly agree oslo.messaging and/or oslo.notifications should be an option (and probably the default one at that), I think there should still be an option to use ceilometer or some other notification mechanism. As long as its pluggable, I don't think anyone would be too fussed. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] [Heat] Ceilometer aware people, please advise us on processing notifications..
On Tue, Jun 24 2014, Clint Byrum wrote: Basically in Heat when a user boots an instance, we would like to act as soon as it is active, and not have to poll the nova API to know when that is. Angus has suggested that perhaps we can just tell ceilometer to hit Heat with a web hook when that happens. We have a blueprint for having alarm based on notifications: https://blueprints.launchpad.net/ceilometer/+spec/alarm-on-notification And that would likely do what you need. -- Julien Danjou /* Free Software hacker http://julien.danjou.info */ signature.asc Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer] [Heat] Ceilometer aware people, please advise us on processing notifications..
Hello! I would like to turn your attention to this specification draft that I've written: https://review.openstack.org/#/c/100012/1/specs/convergence-continuous-observer.rst Angus has suggested that perhaps Ceilometer is a better place to handle this. Can you please comment on the review, or can we have a brief mailing list discussion about how best to filter notifications? Basically in Heat when a user boots an instance, we would like to act as soon as it is active, and not have to poll the nova API to know when that is. Angus has suggested that perhaps we can just tell ceilometer to hit Heat with a web hook when that happens. Thanks! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] [Heat] Ceilometer aware people, please advise us on processing notifications..
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24/06/14 09:28, Clint Byrum wrote: Hello! I would like to turn your attention to this specification draft that I've written: https://review.openstack.org/#/c/100012/1/specs/convergence-continuous-observer.rst Angus has suggested that perhaps Ceilometer is a better place to handle this. Can you please comment on the review, or can we have a brief mailing list discussion about how best to filter notifications? Basically in Heat when a user boots an instance, we would like to act as soon as it is active, and not have to poll the nova API to know when that is. Angus has suggested that perhaps we can just tell ceilometer to hit Heat with a web hook when that happens. We could have a per-resource webhook (either the signal or something like it) that is just a logical notification/kick to go and re-check the resource state. The other part of this is when we turn on continuous convergence, we could get an alarm whenever that resource changes state (or what ever we are interested in - as long as it is in the notification payload). Given the number of resources we want to manage the alarm sub-system will need to be scalable. I'd rather Ceilometer solve that than Heat. Aside: One thing is do we need to continuously monitor the properties? Because the notifications won't tell us that. - -Angus Thanks! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTqPxRAAoJEFrDYBLxZjWo/JQH/2zKJAycPTkRcR0/kUabxTkd 6NFdM+5TMCiLhcehqQweTcB4yG9i5+oX1G36SApsN9bKWAM+JQ9IW6ZcxCalwn7o oRza0Ubh4stDE2MIBeDDkXjSz3Fggc5hf9oICILLi9utdrBhPnxjEwNXVyuDnxtm oXYBsaI9U/UxuboHMj7sOyOPbB0kXMk9lf4LsVMNJLlplIjABYeRODS2xdepS9SC ANga13pEomQpe5LlPeHkgG/Ww2ZPtA7I35A4nkaWzq7nOiL9JZgREXyaOcwi2pzK KFMw+c5woDjikDIk00jLLLHpzmaRMMP8nr0+M35GqtMqDBxDX1mRnd68f6LPP/8= =6eWN -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
