@MWM  For good security reasons, NiFi does not support passwordless keystore and truststore files. The password fields can not be blank. Also keep in mind that the default "nifi.web.https.host=127.0.0.1" is localhost on the machine were you installed NiFi. So you will not be able to access this IP from any other machine. You'll need to use a browser installed on the same machine. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more

@hegdemahendra  The ConsumeAzureEventHub processor utilizes the AzureSDK library. The AzureSDK manages an internal thread pool for consuming events outside of the control of the NiFi processor.  When the processor is started the single concurrent task thread is used to give a handle to the AzureSDK Session Factory.  At that point all thread control pertaining to the consumption of events is outside the bounds of the NiFi framework.  There are unfortunate side effects caused by using the AzureSDK in this processor.  Since thread handling is moved out of the NiFi framework control, backpressure on the outbound connection(s) of this processor are not going to be honored.  NiFi Framework handles backpressure as a soft limit and once the threshold on the connection is met or exceeded, the framework stops scheduling the source component. Since the ConsumeAzureEventHub processor on startup only gets "scheduled" once (hands off thread to AzureSDK to handle thread pool and consumption, the processor never needs to be scheduled again (always on). Only stopping the processor will stop the underlying AzureSDK from consuming more events.  Risk here is that if a downstream issue happens, the connection(s) outbound from the ConsumeAzureEventHub processor will continue to grow until you run out of disk space on the FlowFile or content repository disks. The following Jira covers this limitation: https://issues.apache.org/jira/browse/NIFI-10353 If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more

@hegdemahendra  There currently are no NiFi processors for ingesting from Delta Lake.  There is an existing Apache Jira for creating such list/fetch processors for Delta Lake, but it is still open and does not look to be actively being worked on: https://issues.apache.org/jira/browse/NIFI-7093 I am not aware of any open source 3rd party options here as well. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more

@SandyClouds  What i am saying is that rest-api call response you got via command line is probably not the exact same request made by NiFi.   What that response json tells you is that the user that made the request only has READ to all three buckets. You did not share the complete rest-api call you made, so I am guessing you did not pass any user authentication token or clientAuth certificate in yoru rest-api request and this that request was treated as bing made by an anonymous user.  Since your bucket(s) have the "make publicly visible" checked, anonymous user will have only READ access to the buckets. In NiFi you are trying to start version control on a Process group.  That means that the NiFi node certificate needs to be authorized on all buckets and authorized to proxy the NiFi authenticated user (who also needs to have read, write on the specific bucket to start version control.  If the response received back to NiFi during the request is that nodes or user on has READ, then no buckets would be shown in that UI since the action that UI is performing would be a WRITE.   You should use the "developer tools" in your web browser to capture the actual full request  being made by NiFi when you try to start version control on a process group.  Most developer tolls even give you and option to "copy as curl" which you can then just paste in a cmd window and execute manually yourself outside of NiFi to see the same response NiFi is getting. My guess here is that you are having a TLS handshake issue resulting in yoru requests to NiFi-Registry being anonymous requests.   The NiFi logs are not going to show you details on what authorization was on the NiFi-Registry side (you'll need to check the nifi-registry-app.log for that).  All the NiFi log you shared shows is that your "new_admin" was authorized to execute the NiFi rest-api endpoint.  This triggering the connection attempt with NiFi-Registry which also appeared successful (likely as anonymous). If you look at the verbose output for the NiFi keystore, NiFi truststore, NiFi-Registry keystore, and NiFi-Registry truststore, you'll be able to determine if a mutual TLS exchange would even be possible between the two services using the keystore and truststores you have in place.  These versbose outputs which you can get using the keytool command will also show you the EKUs and SANs present on your certificates. <path to JDK>/keytool -v -list -keystore <keystore or truststore file> When prompted for password, you can just hit enter without providing password. The screenshots you shared showing the authorizations configured in NiFi-Registry are sufficient.  I was simply pointing out that you gave too much authorization to your NiFi node in the global policy section.   This is why i am leaning more to a TLS handshake issue resulting in an anonymous user authentication rather then an authorization issue.  You'll also want to inspect your nifi-registry-app.log for the authorization request coming from NiFi to see if is authorizing "anonymous" or some other string.  Perhaps you have some identity mapping pattern configured on NiFi-Registry side that is trimming out the CN  from your certificate DNs?  In that case you could also see this behavior because your NiFi-Registry would be looking up authorization on different identity string (instead of "CN=new_admin, OU=Nifi, i maybe looking for just "new_admin").  NiFi and NiFi-Registry authorizations are exact string matches (case sensitive); otherwise, treated as different users. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more