Skip to content

[FEATURE] Trigger new IstioRevision on spec.values changes in RevisionBased strategy #1697

@berryfl

Description

@berryfl

Is this the right place to submit this?

  • This is not a question about how to use the sail-operator

Feature Description

Problem

Currently, when spec.updateStrategy.type is set to RevisionBased, a new IstioRevision is created only when spec.version changes.

Each IstioRevision represents a full Istio control plane (e.g., istiod, ConfigMaps, etc.), which makes it very useful for gradual rollouts and safe upgrades.

However, many important configurations (such as access log format, telemetry settings, etc.) are defined in spec.values. Changes to these configurations do not trigger the creation of a new IstioRevision, making it difficult to safely roll out such changes using the existing revision-based mechanism.


Proposal

Introduce an optional boolean field:

spec.updateStrategy.trackValues: true

When enabled, the controller should create a new IstioRevision not only when spec.version changes, but also when spec.values changes.


Suggested Behavior

  • When trackValues is disabled (default):

    • Existing behavior is preserved (only spec.version changes trigger new revisions)
  • When trackValues is enabled:

    • Changes in spec.values should also trigger a new IstioRevision

Implementation Idea

To distinguish revisions created from spec.values changes, the naming convention of IstioRevision could be extended from:

<istio-name>-<istio-version>

to

<istio-name>-<istio-version>-<values-hash>

Where:

  • <values-hash> is computed based on spec.values
  • This ensures deterministic and unique revision names for different configurations

Benefits

  • Enables safe and gradual rollout of configuration-only changes
  • Aligns configuration changes with the existing revision-based upgrade model
  • Avoids in-place mutations of control plane components
  • Improves observability and rollback capabilities

Additional Notes

  • The hash computation should be stable and deterministic
  • Backward compatibility is preserved since the feature is opt-in

Additional Information

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions