@Harshith Venkatesh When performing Site-to-Site (S2S) between two Secured NiFi installs, server authentication and authorization will need to be successful. In your case it sounds like authentication was likely successful (You can confirm this by looking in the nifi-user.log of the target NiFi). What appears to be missing is source server(s) authorization. To resolve the "forbidden" you are seeing on your RPG, you will need to go to the target NiFi and add a new user for the source NiFi server(s) running the RPG. Click on "Users" to add new The user you are adding will need to be the full DN from the source NiFI's server certificate. (Case sensitive and white spaces count as valid characters). You can pull he DN out of the nifi-user.log or by doing a verbose listing source NiFi's keystore. After you have added the server as a user, you will need to authorize that server by clicking on "Policies" and granting the server "retrieve site-to-site details" access policy. After doing the above the "forbidden" response on the RPG should go away on next sync. What you still will not see is a list of available input and output ports on the target NiFi to which your source NiFi can connect with over S2S. Remote input and output ports can only be added to the root canvas level. After they have been added you will need to allow your source NiFi server user to access them as well before they will show up in the RPG. This is done via the "Operate panel": Selecting an input or output port on the canvas will show that component as the selected component in the operate panel. Select the key icon and grant your NiFi source Server the following policy: For input ports --> "receive data via site-to-site" access policy For output ports --> "send data via site-to-site" access policy On next sync RPG should now show these ports as available to your source Nifi for connecting to over S2S. Thanks, Matt ... View more

@Sunile Manjee UUIDs are created when a template is add to the canvas. This allows users to instantiate the same template multiple times within a single NiFi. It also insures not conflict of UUID with other existing components already instantiated. There is no way for users to set the UUIDs of any component manually. The only way to maintain UUIDs between NiFi instances is to move the entire flow.xml.gz file from one NIFi to the next rather then using templates. Thanks, Matt ... View more

@Sunile Manjee Even if you were to use NiFi's file based authorizer instead of Ranger the same limitation exists with maintaining authorizations when moving templates from one NiFi environment to another. Templates were never intended or designed to be the answer to the SDLC. Although they represent the closest thing to it for now. Templates are nothing more the a snippet of a NiFi components that can be reused within the same NiFi or downloaded and shared with user of other NiFi instances. They cannot be hardcoded to use specific component uuids nor would be want to because that what hinder there reusability within the same NiFi instance. We also can't include any authorizations with a template since there is no way of knowing that other NiFi instances in which the template is loaded will contain the same set of users. Nor can we set authorizations based on PG names. What if another PG is created with that same name in another process group? What is a user happens to use a PG name that has policies associated to it? The results could present a security issue. There is on going work towards a better SDLC model with NIFi. That being said, the default behavior when adding a template to a graph is that all components inherit the policies from the parent process group. So if at the root level you create several process groups with a specific set of authorizations for each, instantiating your templates in a given process group will establish a controlled set of authorizations. Not the ideal solution, but helps some until future work is done to make SDLC better. Thanks, Matt ... View more

@Anishkumar Valsalam All Nodes will register with ZK to become the cluster coordinator when NiFi cluster is first started. Once all nodes have checked in to ZK or 5 minutes has passed a random node from those who connected will be picked as the cluster coordinator. ZK will also register one node as your primary node. Once a cluster coordinator has been elected, all nodes will start sending heartbeats directly to that node. The cluster coordinator assumes the role of disconnecting nodes from the cluster who do not send heartbeats and reconnecting nodes who heartbeat later after previously being disconnected. Nodes in a cluster also heartbeat with ZK. If either the primary node or cluster coordinator fails to heartbeat, another connected node(s) at random is elected to assume those roles. There is no ability for users to manually assign either of these roles to a specific node in a cluster. Thanks, Matt ... View more