Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable runtime fetcher disable/enable #351

Closed
wants to merge 1 commit into from
Closed

Enable runtime fetcher disable/enable #351

wants to merge 1 commit into from

Conversation

Djelibeybi
Copy link
Contributor

Implements #221

This adds a configuration section to config.yaml which allows users
to enable/disable each fetcher at runtime.

I used the same mechanism being used by the notifications so that future fetchers can add additional configuration items without too much work.

Signed-off-by: Avi Miller [email protected]

This adds a configuration section to config.yaml which allows users
to enable/disable each fetcher at runtime.

Signed-off-by: Avi Miller <[email protected]>
@Quentin-M Quentin-M self-requested a review March 21, 2017 19:09
@Quentin-M Quentin-M added area/usability related to improving user experience component/config lacking/review needs to be reviewed by a maintainer labels Mar 21, 2017
@Quentin-M
Copy link
Contributor

Thanks,

I really like the idea, thanks for your contribution!

@jzelinskie
Copy link
Contributor

The code looks really good. @Quentin-M should we ship this after 2.0 for as a part of it? We're already breaking the config.

@Djelibeybi
Copy link
Contributor Author

The existing config (unmodified) should allow Clair to run without modification. The config changes can be added to disable fetchers, but without the config, all fetchers should work (as before).

@jzelinskie
Copy link
Contributor

This sounds good to me. Let's have them all default to on, but can be disabled.

@jzelinskie jzelinskie added reviewed/needs rework will be closed if review not addressed and removed lacking/review needs to be reviewed by a maintainer labels Apr 11, 2017
@jzelinskie
Copy link
Contributor

jzelinskie commented Aug 14, 2017

#432 implements this behavior, but with a much safer design at the database level.
I'm going to close this PR and prioritize work towards getting #432 merged.

@jzelinskie jzelinskie closed this Aug 14, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/usability related to improving user experience reviewed/needs rework will be closed if review not addressed
Development

Successfully merging this pull request may close these issues.

3 participants