Open Stack

On 10/3/13 4:09 PM, "Thomas Maddox" <thomas.maddox at RACKSPACE.COM> wrote:

>On 10/3/13 8:53 AM, "Julien Danjou" <julien at danjou.info> wrote:
>
>>On Thu, Oct 03 2013, Thomas Maddox wrote:
>>
>>> Interesting point, Doug and Julien. I'm thinking out loud, but if we
>>>wanted
>>> to use pipeline.yaml, we could have an 'enabled' attribute for each
>>> pipeline?
>>
>>That would be an option, for sure. But just removing all of them should
>>also work.
>>
>>> I'm curious, does the pipeline dictate whether its resulting
>>> sample is stored, or if no pipeline is configured, will it just store
>>>the
>>> sample according to the plugins in */notifications.py? I will test this
>>>out.
>>
>>If there's no pipeline, there's no sample, so nothing's stored.
>>
>>> For additional context, the intent of the feature is to allow a
>>>deployer
>>> more flexibility. Like, say we wanted to only enable storing
>>>white-listed
>>> event traits and using trigger pipelines (to come) for notification
>>>based
>>> alerting/monitoring?
>>
>>This is already supported by the pipeline as you can list the meters you
>>want or not.
>
>I poked around a bunch today; yep, you're right - we can just drop samples
>on the floor by negating all meters in pipeline.yaml. I didn't have much
>luck just removing all pipeline definitions or using a blank one (it
>puked, and anything other than negating all samples felt too hacky to be
>viable with trusted behavior).
>
>I had my semantics and understanding of the workflow from the collector to
>the pipeline to the dispatcher all muddled and was set straight today. =]
>I will think on this some more.
>
>I was also made aware of some additional Stevedore functionality, like
>NamedExtensionManager, that should allow us to completely enable/disable
>any handlers we don't want to load and the pipelines with just config
>changes, and easily (thanks, Dragon!).
>
>I really appreciate the time you all take to help us less experienced
>developers learn on a daily basis! =]

I tried two approaches from this:

1. Using NamedExtensionManager and passing in an empty list of names, I
get the same RuntimeError[1]
2. Using EnabledExtensionManager (my preference since the use case for
disabling is lesser than enabling) and passing in a black list check, with
which I received the same Runtime error when an empty list of extensions
was the result.

I was thinking that, with the white-list/black-list capability of [Named,
Enabled]ExtensionManager, it would behave more like an iterator. If the
manager didn't load any Extensions, then it would just no op on operations
on said extensions it owns and the application would carry on as always.

Is this something that we could change in Stevedore? I wanted to get your
thoughts before opening an issue there, in case this was intended behavior
for some benefit I'm not aware of.

-Thomas

[1]:'RuntimeError: No ceilometer.collector extensions found'


>
>Cheers!
>
>-Thomas
>
>>
>>-- 
>>Julien Danjou
>>-- Free Software hacker - independent consultant
>>-- http://julien.danjou.info
>>
>
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>