You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the decision about kicking off Re-provisioning or not is made based on the compatibility.re-provisioning-needed flag in the config. While this is undoubtedly good, during the changes in the area we dropped a step which was persisting the current version of CLI (and schema version). Now, the version pair stored in the migrations DS in the TS holds values that were used during the last Re-provisioning process. While this is maybe not extremely bad it also causes a bit of confusion when looking at the TG logs as it says something like this:
TS_MIGRATION_REQUEST: re-provisioning triples Store on (2.3.0,10); expected [cli-version: 2.3.2, schema-version: 10, reProvisioningNeeded=false]
while we in fact the TS is not on 2.3.0 (it would be actually even saying it's on schema 9 if the v10 migration wouldn't change the value).
Long story short, it might be the time that in the presence of mentioned compatibility.re-provisioning-needed flag, storing the CLI version might be:
either taken out completely
or updated every time TG gets a different version of CLI, even if no re-provisioning was done.
Option 1. sounds to me a bit better choice.
The text was updated successfully, but these errors were encountered:
Currently, the decision about kicking off Re-provisioning or not is made based on the
compatibility.re-provisioning-needed
flag in the config. While this is undoubtedly good, during the changes in the area we dropped a step which was persisting the current version of CLI (and schema version). Now, the version pair stored in themigrations
DS in the TS holds values that were used during the last Re-provisioning process. While this is maybe not extremely bad it also causes a bit of confusion when looking at the TG logs as it says something like this:while we in fact the TS is not on
2.3.0
(it would be actually even saying it's on schema9
if the v10 migration wouldn't change the value).Long story short, it might be the time that in the presence of mentioned
compatibility.re-provisioning-needed
flag, storing the CLI version might be:or updated every time TG gets a different version of CLI, even if no re-provisioning was done.Option 1. sounds to me a bit better choice.
The text was updated successfully, but these errors were encountered: