Re: [openstack-dev] [rally] [Ceilometer] profiler sample resource id
Hi, Could you provide the link to this code? On Wed, Aug 12, 2015 at 9:22 PM, Pradeep Kilambi pkila...@redhat.com wrote: We're in the process of converting existing meters to use a more declarative approach where we add the meter definition as part of a yaml. As part of this transition there are few notification handlers where the id is not consistent. For example, in profiler notification Handler the resource_id is set to profiler-%s % message[payload][base_id] . Is there a reason we have the prefix? Can we ignore this and directly set to message[payload][base_id] ? Seems like there is no real need for the prefix here unless i'm missing something. Can we go ahead and drop this? If we don't hear anything i'll assume there is no objection to dropping this prefix. Thanks, -- -- Pradeep Kilambi; irc: prad OpenStack Engineering __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [rally] [Ceilometer] profiler sample resource id
On Thu, Aug 13, 2015 at 8:50 AM, Roman Vasilets rvasil...@mirantis.com wrote: Hi, Could you provide the link to this code? Here it is: https://github.com/openstack/ceilometer/blob/master/ceilometer/profiler/notifications.py#L76 On Wed, Aug 12, 2015 at 9:22 PM, Pradeep Kilambi pkila...@redhat.com wrote: We're in the process of converting existing meters to use a more declarative approach where we add the meter definition as part of a yaml. As part of this transition there are few notification handlers where the id is not consistent. For example, in profiler notification Handler the resource_id is set to profiler-%s % message[payload][base_id] . Is there a reason we have the prefix? Can we ignore this and directly set to message[payload][base_id] ? Seems like there is no real need for the prefix here unless i'm missing something. Can we go ahead and drop this? If we don't hear anything i'll assume there is no objection to dropping this prefix. Thanks, -- -- Pradeep Kilambi; irc: prad OpenStack Engineering __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -- Pradeep Kilambi; irc: prad OpenStack Engineering __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [rally] [Ceilometer] profiler sample resource id
Pradeep, Actually this topic is more about osprofiler ceilometer. Overall it doesn't require this prefix. However it is used in osproifler lib. https://github.com/stackforge/osprofiler/blob/master/osprofiler/parsers/ceilometer.py#L129 Best regards, Boris Pavlovic On Thu, Aug 13, 2015 at 7:16 AM, Pradeep Kilambi pkila...@redhat.com wrote: On Thu, Aug 13, 2015 at 8:50 AM, Roman Vasilets rvasil...@mirantis.com wrote: Hi, Could you provide the link to this code? Here it is: https://github.com/openstack/ceilometer/blob/master/ceilometer/profiler/notifications.py#L76 On Wed, Aug 12, 2015 at 9:22 PM, Pradeep Kilambi pkila...@redhat.com wrote: We're in the process of converting existing meters to use a more declarative approach where we add the meter definition as part of a yaml. As part of this transition there are few notification handlers where the id is not consistent. For example, in profiler notification Handler the resource_id is set to profiler-%s % message[payload][base_id] . Is there a reason we have the prefix? Can we ignore this and directly set to message[payload][base_id] ? Seems like there is no real need for the prefix here unless i'm missing something. Can we go ahead and drop this? If we don't hear anything i'll assume there is no objection to dropping this prefix. Thanks, -- -- Pradeep Kilambi; irc: prad OpenStack Engineering __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -- Pradeep Kilambi; irc: prad OpenStack Engineering __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [rally] [Ceilometer] profiler sample resource id
We're in the process of converting existing meters to use a more declarative approach where we add the meter definition as part of a yaml. As part of this transition there are few notification handlers where the id is not consistent. For example, in profiler notification Handler the resource_id is set to profiler-%s % message[payload][base_id] . Is there a reason we have the prefix? Can we ignore this and directly set to message[payload][base_id] ? Seems like there is no real need for the prefix here unless i'm missing something. Can we go ahead and drop this? If we don't hear anything i'll assume there is no objection to dropping this prefix. Thanks, -- -- Pradeep Kilambi; irc: prad OpenStack Engineering __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
