[jira] [Updated] (NIFI-6849) On startup, NiFi should be more liberal about what it's willing to inherit from cluster
[ https://issues.apache.org/jira/browse/NIFI-6849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Gilman updated NIFI-6849: -- Fix Version/s: 1.12.0 Resolution: Fixed Status: Resolved (was: Patch Available) > 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 > Fix For: 1.12.0 > > Time Spent: 3h 40m > 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)
[jira] [Updated] (NIFI-6849) On startup, NiFi should be more liberal about what it's willing to inherit from cluster
[ https://issues.apache.org/jira/browse/NIFI-6849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-6849: --- Fix Version/s: (was: 1.11.0) > 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: 0.5h > 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)
[jira] [Updated] (NIFI-6849) On startup, NiFi should be more liberal about what it's willing to inherit from cluster
[ https://issues.apache.org/jira/browse/NIFI-6849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-6849: --- Fix Version/s: 1.11.0 > 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 > Fix For: 1.11.0 > > 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)
[jira] [Updated] (NIFI-6849) On startup, NiFi should be more liberal about what it's willing to inherit from cluster
[ https://issues.apache.org/jira/browse/NIFI-6849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Payne updated NIFI-6849: - Status: Patch Available (was: Open) > 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: 10m > 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)
