Open Stack

On Tue, Oct 8, 2013 at 9:44 AM, Thomas Maddox
<thomas.maddox at rackspace.com>wrote:

>   On 10/7/13 3:49 PM, "Doug Hellmann" <doug.hellmann at dreamhost.com> wrote:
>
>
>
>
> On Mon, Oct 7, 2013 at 4:23 PM, Thomas Maddox <thomas.maddox at rackspace.com
> > wrote:
>
>>   On 10/7/13 1:55 PM, "Doug Hellmann" <doug.hellmann at dreamhost.com>
>> wrote:
>>
>>
>>
>>
>> On Mon, Oct 7, 2013 at 1:44 PM, Thomas Maddox <
>> thomas.maddox at rackspace.com> wrote:
>>
>>>  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.
>>>
>>
>>  The exception is intended to prevent the app from failing silently if
>> it cannot load any plugins for some reason, but
>> 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.
>>
>>
>>   Thanks, Doug!
>>
>>  I poked around a bit more. This is being raised in the map function:
>> https://github.com/dreamhost/stevedore/blob/master/stevedore/extension.py#L135-L137,
>> not at load time. I see a separate try/except block for a failure to load,
>> it looks like:
>> https://github.com/dreamhost/stevedore/blob/master/stevedore/extension.py#L85-L97.
>> Is that what you're referring to?
>>
>
>  The exception is raised when the manager is used, because the manager
> might have been created as a module or application global object in a place
> where the traceback wouldn't have been logged properly.
>
>
>  I don't understand. Why wouldn't it have been logged properly when it
> fails in the _load_plugins(…) method? Due to implementor's code, Stevedore
> code, or some other reason(s) that I'm missing?
>

If the manager is instantiated before logging is configured that log call
won't do anything (or might do the wrong thing).

Stevedore is trying to prevent an app from failing to start if some or all
of the extensions don't load, but then complain noisily later when the
extensions are actually *used*. The trade-off for protecting against those
cases is what you're running into -- sometimes it is OK to not load or
invoke any plugins. But stevedore does not know when that is OK, so it is
left up to the caller to either catch the exception and ignore it or
perform some sort of check explicitly before calling the manager.


> 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.
>>
>>
>>  This seems like it'd have the desired end result, but then this logic
>> would have to live in two places for the collector service - both at
>> collector initialization as well as each time a notification is processed.
>> If Stevedore ExtensionManager behaved like an iterator map, where
>> extensions = [] and map(func, extensions) just returns None, we would
>> handle the empty case in one place (but silently, indeed). Otherwise, We'd
>> have to check for publishers in the init function and, since that causes no
>> notification managers to load,  we also have to check for the existence of
>> notification managers in the callback for each notification. I realize I'm
>> speaking specifically to Ceilometer's collector service, so generally
>> speaking, what I'm suggesting is to fall back to how Python handles this
>> naturally, since Stevedore is using a map function as syntactic sugar for
>> an iterator of available extensions; seems the simplest approach to me.
>>
>
>  If there are no publishers for any pipelines, is there any need to
> subscribe to the notifications at all?
>
>
>  Only if we wanted to just store events that come through; no pipeline,
> just straight to the dispatcher with the coded traits – soon to be
> configurable.
>

Ah, right, OK.


>
>
>
>>
>>  Another suggestion (thanks, Dragon!), is we could just subclass the
>> ExtensionManager for a different way of handling the various iterator
>> operations?
>>
>
>  You could just loop over the manager, too. It already exposes the
> extensions as an iterable.
>
>
>  Yep, good point. I will change it to this for my next patchset. I
> suppose I was really trying to use the built in functionality for applying
> a function to all extensions the manager had. =P
>

And you still could. Just catch the exception and decide whether it's
really an error.


> That mode does not report the error where the app thinks it needs to load
> some plugins but cannot, so you would have to add an explicit check for
> that somewhere to replace the one built into stevedore's map() method now.
>
>
>  Are you referring only to subclassing ExtensionManager here, or doing
> map(func, manager.extensions) as well? Since we instantiate the manager in
> the collector init function, we should see a failed load there from the
> _load_plugins(…) try block.
>

Iterating over the extension manager does not check whether there are any
extensions loaded. If the manager contains no extensions, the loop just
iterates over an empty list.

Doug


>
>  Thanks again, man!
>
>  - Thomas
>
>
>
>>
>>  So, now we have several viable options on the table, all of which I
>> believe will work for our needs. More thoughts will definitely be
>> appreciated. =]
>>
>>  - Thomas
>>
>>
>>  Doug
>>
>>
>>
>>>
>>> -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
>>> >
>>>
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131008/b1227e3e/attachment.html>