Lower resource usage

[runningman84]

Describe the feature I found out that in an edge computing use case with low powered devices flux and helm operator easily usu more power than the main running applications in a cluster.

What would the new user story look like? Flux and helm operator should only run if a new git commit appears or some schedule is met like run at least once an hour or day.

Expected behavior Using flux should be more efficient.

[2opremio]

@runningman84 can you decribe your usecase further? What kind of low power devices are you referring to?

Can you share some data or even profile Flux?

[2opremio]

There may be ways to tweak Flux in order to less resource-hungry for your usecase.

[runningman84]

Yes I have some low powered msi cubi n devices. They have CPUs like Intel n4000 and n5000 which are not very fast. I use it to run some internal stuff like home automation and so on. There are not many changes happening so the current flux model is quite brute force.

I think you should be able to specify something like sync at least once a day or if a new git commit appears.... The key point is I do not want to wait one day if I make a git commit...

[2opremio]

You can use webhooks and set a looong sync period, see https://github.com/fluxcd/flux-recv

[runningman84]

the webhook seems to be a good solution but right now the helm chart does not support it. It would be cool if the flux-recv part would just be an option for the helm chart...

[runningman84]

As you can see fluxd and helm-operator consume a lot more cpu time than and elasticsearch, prometheus. Elasticsearch stores about 1 million messages a day and prometheus also stores a lot of data using a lot less time...

[kingdonb]

The Helm chart most certainly does support it, though it may not be sufficiently documented, it is possible through this example... Flux v1's helm chart can enable flux-recv in this way, through adding extraContainers (as an example values you can use to set up the git flux-recv webhook via Helm): https://github.com/okteto/charts/blob/master/flux/values.yaml

This is from the Okteto "flux-getting-started" guide, https://github.com/okteto/flux-getting-started which has a delicious walkthrough of setting up Flux v1 on Okteto Cloud.

There are additional webhook examples for Flux v2 that can allow you to lower polling intervals and improve performance that way (though Flux v2 has made great onroads in performance, eg by not relying on pulling image layers to drive automation!)

Documentation for Flux v2 for both webhook receiving (for triggering a reconciliation on-demand): https://toolkit.fluxcd.io/components/notification/receiver/#generic-receiver

... and providing: https://toolkit.fluxcd.io/components/notification/provider/#generic-webhook

So you can trigger remote far-away operations, eg. actions that need to happen in a pipeline, with a webhook provider too.

Flux v1 is in maintenance mode now, and is not adding any new features unless they are critical.

As Flux contrib efforts have been focused on Flux v2, the Flux project has moved to a new repo, fluxcd/flux2

In the interest of reducing the number of open issues not directly related to supporting Flux v1 in maintenance mode, and respecting you may have moved on already, I will go ahead and close out this issue for now.

If you have a use case for Flux that isn't covered well in the new Flux v2 (which is a total rewrite), we want to hear about it.

If you've been following our development efforts then of course we hope you are able to upgrade, here's more info on how to find support with that: https://fluxcd.io/support/

Thank you for reporting this issue, your feedback has helped the dev team to decide priorities for the next version of Flux! Closing out for now.