<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Oct 7, 2013 at 1:44 PM, Thomas Maddox <span dir="ltr"><<a href="mailto:thomas.maddox@rackspace.com" target="_blank">thomas.maddox@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 10/3/13 4:09 PM, "Thomas Maddox" <<a href="mailto:thomas.maddox@RACKSPACE.COM">thomas.maddox@RACKSPACE.COM</a>> wrote:<br>

<br>
>On 10/3/13 8:53 AM, "Julien Danjou" <<a href="mailto:julien@danjou.info">julien@danjou.info</a>> wrote:<br>
><br>
>>On Thu, Oct 03 2013, Thomas Maddox wrote:<br>
>><br>
>>> Interesting point, Doug and Julien. I'm thinking out loud, but if we<br>
>>>wanted<br>
>>> to use pipeline.yaml, we could have an 'enabled' attribute for each<br>
>>> pipeline?<br>
>><br>
>>That would be an option, for sure. But just removing all of them should<br>
>>also work.<br>
>><br>
>>> I'm curious, does the pipeline dictate whether its resulting<br>
>>> sample is stored, or if no pipeline is configured, will it just store<br>
>>>the<br>
>>> sample according to the plugins in */notifications.py? I will test this<br>
>>>out.<br>
>><br>
>>If there's no pipeline, there's no sample, so nothing's stored.<br>
>><br>
>>> For additional context, the intent of the feature is to allow a<br>
>>>deployer<br>
>>> more flexibility. Like, say we wanted to only enable storing<br>
>>>white-listed<br>
>>> event traits and using trigger pipelines (to come) for notification<br>
>>>based<br>
>>> alerting/monitoring?<br>
>><br>
>>This is already supported by the pipeline as you can list the meters you<br>
>>want or not.<br>
><br>
>I poked around a bunch today; yep, you're right - we can just drop samples<br>
>on the floor by negating all meters in pipeline.yaml. I didn't have much<br>
>luck just removing all pipeline definitions or using a blank one (it<br>
>puked, and anything other than negating all samples felt too hacky to be<br>
>viable with trusted behavior).<br>
><br>
>I had my semantics and understanding of the workflow from the collector to<br>
>the pipeline to the dispatcher all muddled and was set straight today. =]<br>
>I will think on this some more.<br>
><br>
>I was also made aware of some additional Stevedore functionality, like<br>
>NamedExtensionManager, that should allow us to completely enable/disable<br>
>any handlers we don't want to load and the pipelines with just config<br>
>changes, and easily (thanks, Dragon!).<br>
><br>
>I really appreciate the time you all take to help us less experienced<br>
>developers learn on a daily basis! =]<br>
<br>
</div></div>I tried two approaches from this:<br>
<br>
1. Using NamedExtensionManager and passing in an empty list of names, I<br>
get the same RuntimeError[1]<br>
2. Using EnabledExtensionManager (my preference since the use case for<br>
disabling is lesser than enabling) and passing in a black list check, with<br>
which I received the same Runtime error when an empty list of extensions<br>
was the result.<br>
<br>
I was thinking that, with the white-list/black-list capability of [Named,<br>
Enabled]ExtensionManager, it would behave more like an iterator. If the<br>
manager didn't load any Extensions, then it would just no op on operations<br>
on said extensions it owns and the application would carry on as always.<br>
<br>
Is this something that we could change in Stevedore? I wanted to get your<br>
thoughts before opening an issue there, in case this was intended behavior<br>
for some benefit I'm not aware of.<br></blockquote><div><br></div><div>The exception is intended to prevent the app from failing silently if it cannot load any plugins for some reason, but </div><div>stevedore should throw a different exception for the "could not load any plugins" and "I was told not to use any plugins and then told to do some work" cases.</div>
<div><br></div><div>In this particular case, though, the thing calling the extension manager knows what the pipeline configuration is, and could just skip the call if there are no publishers in the pipeline.</div><div><br>
</div><div>Doug</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-Thomas<br>
<br>
[1]:'RuntimeError: No ceilometer.collector extensions found'<br>
<div class="im HOEnZb"><br>
<br>
><br>
>Cheers!<br>
><br>
>-Thomas<br>
><br>
>><br>
>>--<br>
>>Julien Danjou<br>
>>-- Free Software hacker - independent consultant<br>
>>-- <a href="http://julien.danjou.info" target="_blank">http://julien.danjou.info</a><br>
>><br>
><br>
><br>
><br>
</div><div class="HOEnZb"><div class="h5">>_______________________________________________<br>
>OpenStack-dev mailing list<br>
><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>