[
https://issues.apache.org/jira/browse/NIFI-2078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15347902#comment-15347902
]
ASF GitHub Bot commented on NIFI-2078:
--------------------------------------
Github user ijokarumawak commented on the issue:
https://github.com/apache/nifi/pull/563
Test with Kerberized Kafka and Zk is done. I followed [confluent Apache
Kafka Security
101](http://www.confluent.io/blog/apache-kafka-security-authorization-authentication-encryption)
to setup test environment. As written in the blog post, I used the [Vagrant
instance](https://github.com/confluentinc/securing-kafka-blog), then deployed
NiFi Snapshot build on it.
In order to make ConsumeKafka working, followings had to be configured:
- $NIFI/conf/bootstrap.conf
-
java.arg.15=-Djava.security.auth.login.config=/etc/kafka/kafka_client_jaas.conf
- ConsumeKafka processor properties
- Kafka Brokers: kafka.example.com:9095
- Topic Name: securing-kafka
- Client ID: (any value would be fine)
- Security Protocol: SASL_SSL
- Kerberos Service Name: kafka
- Group ID: securing-kafka-group * needs ACL setting
- Offset Reset: earliest (doesn't matter)
- Message Demarcrator: (No value set)
- ssl.key.password: test1234
- ssl.keystore.location: /etc/security/tls/kafka.client.keystore.jks
- ssl.keystore.password: test1234
- ssl.truststore.location: /etc/security/tls/kafka.client.keystore.jks
- ssl.truststore.password: test1234
Thanks @olegz for helping me to setup the environment. I also should thank
[confluent](http://www.confluent.io/) for publishing the detailed blog post and
share Vagrant file!
> State management for processors whose states are managed externally
> -------------------------------------------------------------------
>
> Key: NIFI-2078
> URL: https://issues.apache.org/jira/browse/NIFI-2078
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
> Reporter: Koji Kawamura
> Assignee: Koji Kawamura
> Fix For: 1.0.0
>
>
> Inherently by the nature of a given processor it may involve state managed by
> itself (using nifi state management), or can be managed by some external
> service it interacts with (kafka's offset), and theoretically some might have
> both going on. With the new state management, we're giving users a way to
> reset state managed by nifi for a given processor. But it doesnt apply to
> those processors who have external state.
> we should consider offering a way to reset state that allows a processor to
> call out to whatever external store it impacts
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
