-
Notifications
You must be signed in to change notification settings - Fork 47
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
Flows do not persist pod restart #70
Comments
I got this response from one of the alternate communication channels. But I cannot make sense of it. Could this be an issue?
|
I recently opened a PR that provides an option to NifiClusterSpec where, when specified, does not remove the flow.xml.gz file on pod startup. In the current implementation, even though the flows.xml.gz file is persisted, it is removed every time the pod starts. https://github.com/Orange-OpenSource/nifikop/blob/master/pkg/resources/nifi/pod.go#L418 |
You should deploy a https://orange-opensource.github.io/nifikop/docs/5_references/5_nifi_dataflow I could be wrong, but I suppose you could also make sure the |
For production clusters where you've configured nifikop to deploy flows to, this isn't really a problem. However, I do think this would be a useful feature for the following reason: If you use a single cluster deployment as a place to create flows and version control them, then you wouldn't be configuring flows to be deployed to it. Since nifikop wipes the I personally feel that the PR previously mentioned, raised by @genehynson, would be a useful feature and should be re-opened in this repo. |
After upgrading to NiFi 1.16 we are no longer running into this issue. I believe this is because NiFi migrated to a new file, flow.json.gz which is not deleted by the NiFi pod startup script provided by nifikop. Also with NiFi 1.16 we've been able to do clean, rolling upgrades by creating a PodDisruptionBudget and only allowing 1 NiFi node to be updated by k8s at a time. NiFi 1.16 introduced a new "flow negotiation" system that allows for each node in the NiFi cluster to have slightly different versions of the flow.json.gz file (like different processor versions, for example). So even if nifikop does start deleting the flow.json.gz file I think we'll be fine because when a NiFi pod rolls it will get the contents for the flow.json.gz from the primary NiFi node that has not rolled yet (or has already rolled). So that being said, the usecase for the PR mentioned is only if you're running 1 NiFi node or are running an older version of NiFi. |
Good to know! Thanks for the follow up. I do think that NiFi is writing both the Maybe we can resolve this issue then? |
Correct, but it only uses one of them. Whichever you have defined in That being said, I'm also fine with resolving this issue. |
The flow.xml.gz is not removed anymore at pod restart ! |
From nifikop created by andrew-musoke: Orange-OpenSource/nifikop#201
Type of question
Are you asking about community best practices, how to implement a specific feature, or about general context and help around nifikop ?
General help with Nifikop.
Question
What did you do?
I deployed Nifi with 2 pods via NifiKops. After creating a flow on the UI, I exported the process groups to a nifi-registry as well. The cluster run for days. This is the CR I used. I then deleted the cluster pods to test resilience.
What did you expect to see?
I expected the cluster to run properly and survive restarts since PVs are created. I expected to see the pipelines continue running after the pods started up.
What did you see instead? Under which circumstances?
When the pods came back up and were healthy, the UI had no flows or process groups. The registry configuration had also disappeared. I have to manually re-register the nifi-registry, re-import the process groups, add the secrets and restart the pipelines.
Environment
nifikop version:
v0.7.5-release
Kubernetes version information:
apache/nifi:1.12.1
The text was updated successfully, but these errors were encountered: