Is CLI provision suitable for GitOps?

Currently, Lenses CLI command lenses-cli provision is a method used to provision only initial configuration when Lenses is deployed from scratch. Consecutive runs of the provision command are not supported currently, and may have unintended consequences.

Based on this, Lenses CLI provision does not allow for a true “GitOps” workflow. Specifically the following deployment methods, by default skip provisioning from the CLI, using --setup-mode flag as in the next section

• Helm
• Linux with SystemD Unit for Automatic Provisioning

Waiting for the Wizard to complete 

In order to help with configuration race conditions between the Lenses UI wizard and Lenses CLI provision, we can opt for CLI provision command to wait until wizard setup, has been completed. When --setup-mode is used as a flag for CLI provision command: lenses-cli provision the behavior depends on the phase of Lenses deployment:

• If Lenses is deployed from scratch, and Lenses CLI runs provision with no existing configuration, --setup-mode puts provisioning into a wait mode until Lenses CLI Wizard configuration is complete.
• If Lenses CLI provision is re-run, --setup-mode skips CLI provision altogether.

To help showcase this behavior let’s consider these scenarios:

Scenario: Initial provision using CLI, updates using UI 

1. Use only the provision command for initial provision run. Never use the UI wizard. lenses-cli provision will create all configuration based on values in provision.yaml. Similarly use - Helm with field lenses.provision.enabled set to true. Helm provision uses the CLI command in an automated way, during first install.
2. To update configuration values, such as Kafka connection urls, assume we use the Lenses UI. Configuration is applied correctly.
3. Even if provision.yaml has updates at a later stage, re-runs of lenses-cli provision with --setup-mode flag, will be skipped, rendering all changes in provision.yaml ineffective. Correct course of action is to use the Lenses UI for all updates, from now on.

Scenario: Initial provision using the UI Wizard, updates using CLI 

1. Use Lenses UI Wizard for initial provision run. lenses-cli provision with --setup-mode flag, will wait for the Wizard mode to be completed. When wizard has finished, lenses-cli provision with --setup-mode flag, will be skipped, ignoring all initial values in provision.yaml
2. To update configuration values, such as Kafka connection urls, assume we update provision.yaml values. Configuration updates will never be applied.
3. Even if provision.yaml has updates on a later stage, re-runs of lenses-cli provision with --setup-mode flag, will be skipped, rendering all changes in provision.yaml ineffective. Correct course of action is to use the Lenses UI for all updates, from now on.

Scenario: Initial provision using the CLI, updates using CLI 

1. Use only provision command for initial provision run. Never use UI wizard. lenses-cli provision will create all configuration based on values in provision.yaml. Similarly use - Helm with field lenses.provision.enabled set to true. Helm provision uses the CLI command in an automated way, during first install.
2. To update configuration values, such as Kafka connection urls, assume we update provision.yaml values. Configuration updates will never be applied.
3. Even if provision.yaml has updates on a later stage, re-runs of lenses-cli provision with --setup-mode flag, will be skipped, rendering all changes in provision.yaml ineffective. The correct course of action is to use the Lenses UI for all updates from now on.