Getting Flux Support
The success and happiness of our users is essential to the Flux community. We are working very hard to make all of our tools obvious and self-explanatory, to make them composable with other tools and make our documentation easy to follow.
You might still run into issues. This page is meant to be a guide to help you figure out how and where to look for help.
Commercial Support
Luckily some of the companies who employ Flux developers offer paid support, so if you need an architecture review, training or help implementing certain features, you might want to reach out to the following companies:
Involvement / Service | ControlPlane | DoneOps | Xenit |
---|---|---|---|
Involved in Flux Community | ✅ | ✅ | ✅ |
Employs Flux Core Maintainers | ✅ | ✅ | |
Offers GitOps infrastructure review and support | ✅ | ✅ | ✅ |
Offers Custom Engineering | ✅ | ✅ | |
Offers Enterprise product based on Flux | ✅ |
Flux is a CNCF project, so this “paid support” section is not tied to any single company in particular. If you want to add your company to the list, please make sure you are listed on our adopters page and file a PR against this file and tag the Core Maintainers.
If your company has a track record of Flux engineering and/or support we will get you added.
Documentation for individual Flux projects
Implementing GitOps or any *Ops is a process which involves many layers and technologies. We therefore place a lot of importance on encoding shared knowledge and best practices in our documentation.
To be mindful of everybody’s time, please make sure you checked and followed the documentation before filing issues. Here are some good entry points to get started with our documentation including Getting Started Guides:
Getting help from the Flux Community
We as a community are both very thankful and proud to have attracted many incredibly kind and clever individuals who are all interested in the same thing and who are helping each other out.
As we have been overwhelmed with general questions, troubleshooting requests, feature requests, etc. in the past months, we would like to ask you to:
- Read the documentation carefully, check the individual troubleshooting sections for advice on how to interpret logs, use relevant tools, etc.
- For Flux questions, see if there are answers on the GH Discussions page
- Please don’t direct-message project maintainers or relevant others with specific support questions. The few Flux maintainers cannot answer all questions. If you post on GH Discussions page for Flux questions or message in the appropriate Slack channel, you’ll have a better chance at getting an answer from a community member willing to help.
- Make sure you don’t share private information.
- Help out if you can, e.g. if somebody just answered your question and it was missing in the FAQ or other docs, please consider adding it, it might help somebody in the future.
🕰 Another note: Understanding somebody’s infrastructure and settings takes time. Please provide relevant information up-front. If a Flux contributor spends an hour in a question-and-answer ping-pong with you, that’s one hour they are going to spend less on other parts of Flux.
If all of this sounds like we’re putting you off, that’s not how this is meant. We want to be there for each other in this community, but we want to be mindful of each other’s time.
Let’s be excellent to each other.
Consider this
Support for Flux users and community is mostly provided by volunteers, who are all on equal footing as peers in the Flux community. This implies that (free) support is provided on a best-effort basis, with no SLA or quality-of-service guarantee.
Best-effort delivery is explained on Wikipedia in terms of a “best-effort network, [on which] all users obtain best-effort service. Under best-effort, network performance characteristics such as network delay and packet loss depend on the current network traffic load.”
Similar to a best-effort network, the capacity for our community as a whole to provide quality support for community members, and a welcoming environment for all contributors, depends heavily on the grace and good behavior of individual community members.
You can help ensure a higher quality of best-effort support by formulating inquiries thoughtfully and making a considerate effort to place them in the most appropriate venue.
Here are some guidelines about which venue makes the most sense:
Form of inquiry | Venue |
---|---|
Something is not working as intended / I found a bug | Issue |
A feature is too limited for my <use-case> | Discussion: General |
I want Flux to be able to do <x> | Discussion: Proposal |
Something is not working, (but I am not sure if I am doing it right) | Discussion: Q&A |
Quick question | #flux on CNCF Slack |
Bearing in mind that Issues and Discussions are more permanent and searchable than Slack conversations, we can avoid unduly expending finite community resources by searching before asking. If you are not exactly sure how to ask your question or otherwise daunted by the idea of permanence, visitors are always welcome in #flux on the CNCF Slack.
If your needs are more urgent, more broadly demanding, or more persistent than the best-effort community support resources can provide, you may also consider a paid support option.
Community Help Resources
For questions around Flux, please visit our Flux Discussions section on GitHub.
I found a bug
If you made sure you encountered an actual issue, we definitely want to hear about it.
Here’s how to proceed:
Check GitHub to locate the correct project.
Many Flux projects and project facets are maintained by different code owners under separate repositories, and filing your issue under the correct repository can better ensure that relevant maintainers are notified.
Flux core projects (in active development)
- flux2 - the main Flux project repository
- source-controller - handles artifacts acquisition from external sources such as Git, Helm repositories and S3 buckets.
- kustomize-controller - runs continuous delivery pipelines defined with Kubernetes manifests and assembled with Kustomize.
- helm-controller - declaratively manages Helm chart releases (the successor to Helm Operator from Flux v1).
- notification-controller - event forwarder and notification dispatcher.
- image-reflector-controller - scans container image repositories and reflects the metadata in Kubernetes resources. Pairs with the image update automation controller to drive automated config updates.
- image-automation-controller - automates updates to Git when new container images are available.
- flagger - the progressive delivery tool, reduces the risk of introducing a new software version in production by gradually shifting traffic to the new version while measuring metrics and running conformance tests.
Project documentation
- website - the project’s landing page at https://fluxcd.io and docs
- community - our community repository
Now check the issue template and include any requested information
For example, the
flux2 repo issue template requests the output of flux check
and flux --version
. If you are using an older version of the project, review the release notes from later versions to be sure your issue has not already been resolved. Also check for other issue reports, as if your issue was already reported, this can help avoid duplicate reports.
Any relevant information depending on your specific issue should also be included, like your Kubernetes cluster version and/or cloud provider; or for example if you are reporting an issue related to image automation, tell what type of image hosting is used, or what container registry provider hosts your cluster’s images.