Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🪲 Minion role does not define sink topic configuration #49

Open
indigo423 opened this issue May 7, 2024 · 5 comments
Open

🪲 Minion role does not define sink topic configuration #49

indigo423 opened this issue May 7, 2024 · 5 comments
Labels
bug Something isn't working

Comments

@indigo423
Copy link
Member

The Ansible role for the Minion does not define anything for the sink configuration, only for IPC.

@indigo423 indigo423 added the bug Something isn't working label May 7, 2024
@indigo423
Copy link
Member Author

indigo423 commented May 7, 2024

@bmgante The opennms_minion_kafka dictionary should allow you to configure any arbitrary key/value property in the IPC configuration on the Minion. You should be able to configure it like this:

opennms_minion_kafka:
  "bootstrap.servers": localhost:9092
  "org.opennms.activemq.broker.disable": True
  "org.opennms.core.ipc.strategy": kafka
  "org.opennms.core.ipc.sink.kafka.group.id": Labmonkeys-HQ-Core-Sink
  "org.opennms.core.ipc.sink.initialSleepTime": 60000
  "org.opennms.core.ipc.twin.kafka.group.id": Labmonkeys-HQ-Core-Twin
  "org.opennms.core.ipc.rpc.kafka.group.id": Labmonkeys-HQ-Core-RPC
  "org.opennms.core.ipc.rpc.kafka.single-topic": True
  "org.opennms.core.ipc.rpc.kafka.ttl": 30000

@bmgante
Copy link

bmgante commented May 7, 2024

@indigo423 ok got it. The dict defines the common configuration values and we can put there anything specific to modules:

You can configure module-specific values for modules sink, rpc, and twin by replacing org.opennms.core.ipc.kafka in the config:edit command with org.opennms.core.ipc.sink.kafka, org.opennms.core.ipc.rpc.kafka, and org.opennms.core.ipc.twin.kafka, respectively. Module-specific configuration values take precedence over common configuration values.

https://docs.opennms.com/horizon/33/deployment/minion/install.html

The question in my use case is, what parameters I must configure for snmp traps to be sent from minion to horizon? Do I need all of them (sink, rpc and twin)?

Thanks

@indigo423
Copy link
Member Author

indigo423 commented May 8, 2024

Ok, I understand what you mean by now. What if you want to configure each module (sink, twin, rpc) in a different configuration? It's related to the documentation hint here:

You can configure module-specific values for modules sink, rpc, and twin by replacing org.opennms.core.ipc.kafka in the config:edit command with org.opennms.core.ipc.sink.kafka, org.opennms.core.ipc.rpc.kafka, and org.opennms.core.ipc.twin.kafka, respectively. Module-specific configuration values take precedence over common configuration values.

We should enhance the ansible role to create individual module configurations by default. It gives users the most flexibility to configure the Kafka communication behavior. I need to double-check if it's required to have individual files for each module.

@indigo423
Copy link
Member Author

The question in my use case is, what parameters I must configure for snmp traps to be sent from minion to horizon? Do I need all of them (sink, rpc and twin)?

If you configure the "bootstrap.servers": localhost:9092 property sink, rpc and twin this value. In very advanced setups, you can use for the sink, rpc and twin topics different Kafka cluster.

@bmgante
Copy link

bmgante commented May 8, 2024

The question in my use case is, what parameters I must configure for snmp traps to be sent from minion to horizon? Do I need all of them (sink, rpc and twin)?

If you configure the "bootstrap.servers": localhost:9092 property sink, rpc and twin this value. In very advanced setups, you can use for the sink, rpc and twin topics different Kafka cluster.

I want to use the same kafka for all of these modules so yes, the common config which applies to all of them should be enough. Thanks @indigo423

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants