Configuration

Starting with Lenses 5.0, configuration is separated to dynamic and static.

Dynamic configuration key-points 

• It is available at runtime. It is driven via the Lenses API and is stored inside the application’s database.
• It is used for connections and userland configuration (e.g., alerts, users, groups).
• All core services (Kafka, Schema Registry, Zookeeper, Connect, Kerberos), and the license management moved to the dynamic configuration with Lenses 5.0.
• The Lenses UI can be used (among other clients) to manage dynamic configuration.
• All changes to the dynamic configuration are applied immediately, without the need to restart Lenses.
• With Lenses 5.3 a file-based alternative is introduced for connections and license management, to help platform teams use their existing toolsets for configuration as code.

Kafka and the rest of the key services, are now part of the Connections API and can be managed (add new, update or remove existing ones) without the need to edit static files or restart Lenses. Common cases include to update the Kafka truststore, add a new Connect cluster to Lenses, or setup Lenses for the first time.

Whilst the API can be used directly, it is most often accessed via the Lenses UI (browser), first-run wizard, and the lenses-cli. For platform teams that need to have configuration as code, a YAML file for connections and the license can be used. Changes to this file are reflected immediately in the application.

Static configuration key-points 

• It is driven via the files lenses.conf, security.conf, and logback.xml. It is not stored within the application’s database.
• It is used for application configuration (e.g., port, TLS, authentication —SAML, LDAP, etc—) and tweaking (e.g., polling intervals, SQL low level settings).
• Lenses is monitoring these files constantly, but not all changes can be applied without a restart.