On 10/3/13 8:15 AM, "Doug Hellmann" <doug.hellm...@dreamhost.com<mailto:doug.hellm...@dreamhost.com>> wrote:
On Thu, Oct 3, 2013 at 5:54 AM, Julien Danjou <jul...@danjou.info<mailto:jul...@danjou.info>> wrote: On Wed, Oct 02 2013, Thomas Maddox wrote: > I'm working to make the sample pipeline optional and I'm stuck at a > decision point about whether I ought to use a collector config option > (like 'enable_sample_pipelines'), or let it be driven by setup.cfg (i.e. > the existence of sample plugin references). My favorite right now is the > former, but I wanted to entertain the latter and learn in the process. What about having an empty pipeline.yml? Modifying the pipeline's configuration file is the right way to go. If an empty file isn't valid, then a single pipeline that subscribes to no events may work. 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? 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. 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? The other proposed solution isn't going to work. setup.cfg is not meant to be a deployer-facing configuration file. It's a packaging file that tells the system what files are part of the app or library. Agreed. Thanks for the explanation! =] Doug
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
