Closed dreary-ennui closed 4 months ago
@LaurenceJJones just wondering if Crowdsec has reviewed this issue yet. Thanks!
@LaurenceJJones just wondering if Crowdsec has reviewed this issue yet. Thanks!
Sorry with holidays and launch of 1.6 we havent been able to review it yet.
Stated looking into it, we should provide additional params to the zone worker
from this struct https://github.com/cloudflare/cloudflare-go/blob/ffa96c9e3b43bfe62c918a56536c2b6ab2c55003/workers.go#L24-L65
I dont know cloudflare much but all the docs are pointing it to be as simple as, allowing you to set true/false 🤷🏻
allowing you to set true/false 🤷🏻
I'd be perfectly happy with an option in the bouncer config .yml that I can just set to Logpush: true
@LaurenceJJones Hey Laurence - sorry to bug you :) Just wondering if this is on the radar.
I set up CloudFlare Logpush on the worker and was ingesting the worker logs to my local Elastic instance for statistics and log analysis. Was working great.
Restarted the system the worker was on, the worker re-deployed, CloudFlare Logpush is now disabled.
Looks like the worker re-deploys its infrastructure every time the service starts. Because of this, worker settings do not persist across service restarts.
Proposing one of the following solutions:
1) Workers only re-deploy when necessary (would have to figure out how to tell that?) and can use existing deployments, so customizations to the workers (and workers themselves?) persist across service restarts 2) Service reads existing worker settings prior to cleanup and sets them back after re-deployment 3) Service provides worker options management in config yml
I'm sure there are other ways to tackle this, these were just the first things that came to mind.
This impacted me for Logpush settings, but this probably impacts other worker settings: CPU limit, usage model, placement, etc.