[
https://issues.apache.org/jira/browse/NIFI-6849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17009038#comment-17009038
]
Joe Witt commented on NIFI-6849:
--------------------------------
This does not have a reviewer and is a big change. But the benefit to
typical/desired usage patterns is huge. I'm pulling this into 1.11 for now and
will hunt down a reviewer.
> On startup, NiFi should be more liberal about what it's willing to inherit
> from cluster
> ---------------------------------------------------------------------------------------
>
> Key: NIFI-6849
> URL: https://issues.apache.org/jira/browse/NIFI-6849
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
> Reporter: Mark Payne
> Assignee: Mark Payne
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> On startup, if an instance is configured to be clustered, the instance must
> connect to the Cluster Coordinator and download the existing cluster flow,
> access policies, and users and groups. The instance then performs some checks
> to ensure that the local flow matches the cluster's flow. If it doesn't, then
> the node fails to startup and logs errors that the local flow is different
> than the cluster's flow.
> This was done in order to facilitate debugging. If a particular node is not
> behaving as expected, a user is able to disconnect the node from the cluster
> and make modifications to the node. If the node is then restarted, it may not
> be desirable to lose those changes.
> However, in the vast majority of cases (probably over 98% of the time), what
> the user really wants is for the node to just join back to the cluster and
> inherit the cluster's flow - especially if the node just disconnected because
> it failed to make a modification. This is also problematic with how the
> Users, Groups, and Policies are inherited.
> As a result, we should make the following modifications:
> 1) If Users, Groups, or Access Policies cannot be inherited, continue to
> fail, unless the flow is empty. If the flow is empty, it doesn't really make
> sense to retain the authorizations' configuration because they don't really
> apply to anything. As a result, if the flow is empty, just inherit whatever
> the cluster has. But first, make a backup of the existing policies, users,
> and groups, so that users can manually revert if they do end up needing to.
> 2) If the flow differs from the cluster flow, check the proposed flow to see
> if it removes any existing connections. If it does remove a connection, and
> that connection has data queued locally, continue to fail. Otherwise, create
> a backup of the flow and replace the node's flow with the cluster flow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
