Uploaded image for project: 'Bitbucket Data Center'
  1. Bitbucket Data Center
  2. BSERV-9666

SCM cache configuration is inconsistent, when configured via bitbucket.properties and the REST API

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Low Low
    • 5.0.0
    • None
    • Enterprise, SCM Cache

      Summary

      SCM Caching (ref advertisements and upload-pack / cloning) can be configured in two different ways:

      This results in inconsistent behaviour. Settings via the REST API are persistent, and write the configuration to the plugin_setting table. The persistent configuration appears to take precedence over any config set in bitbucket.properties - in other words, once the API is used to configure SCM caching, bitbucket.properties configuration ceases to have any effect one way or the other

      Steps to Reproduce

      1. Set upload-pack caching to false in bitbucket.properties
      2. Confirm clones are no longer cached
      3. Set upload-pack caching to true via the REST API

      Expected Results

      ???

      Actual Results

      bitbucket.properties configuration no longer has any effect

      Additional considerations

      In a Data Center cluster, when these configuration options are set via the REST API the value is propagated via Hazelcast to all nodes. However, when set via bitbucket.properties, if a node is restarted and picks up the configuration it is not propagated to other nodes. This results in inconsistent configuration within the cluster, where some nodes are behaving one way and other nodes a different way. I'm not sure if this is actually an unrelated hazelcast + bitbucket.properties configuration issue, or if it only applies to the cache settings described here.

            [BSERV-9666] SCM cache configuration is inconsistent, when configured via bitbucket.properties and the REST API

            Messaging and warning around this behaviour will be improved in the upcoming 5.0 release.
            Note that the behaviour itself will not change, however it will be explicitly called out in the documentation for the properties.

            Mismatches in the settings (ie. a property being set in the bitbucket.properties file and via REST) will be logged at startup or when a mismatch is created at runtime (by setting the configuration via REST).

            This should help make it clearer when a property is overridden via REST and make this problem easier to spot should it occur.

            Felix (Inactive) added a comment - Messaging and warning around this behaviour will be improved in the upcoming 5.0 release. Note that the behaviour itself will not change, however it will be explicitly called out in the documentation for the properties. Mismatches in the settings (ie. a property being set in the bitbucket.properties file and via REST) will be logged at startup or when a mismatch is created at runtime (by setting the configuration via REST). This should help make it clearer when a property is overridden via REST and make this problem easier to spot should it occur.

              fhaehnel Felix (Inactive)
              dchevell Dave Chevell
              Affected customers:
              0 This affects my team
              Watchers:
              8 Start watching this issue

                Created:
                Updated:
                Resolved: