Current behaviour

When creating a Product with a CR that contains a duplicate mapping rule the duplicate rule is created in 3scale and stored in the Proxy Config object. When applying any updates to the same CR where a duplicate resides then after that is saved on 3scale the next reconciliation loop will apply a change to the Proxy Config object and the warning symbol will appear in the UI suggesting there are changes which need to be promoted. This is incorrect as can be seen by investigating the attached proxy config files: v1 & v2 and noticing that no data has changed only the updated_at field has changed. This causes the user to think that their current proxy configuration is outdated and a promotion is required which it is not. Also it leads to concerns that some changes may have been reverted or the operator is automatically applying undesired changes.

Additionally, when a Product CR containing duplicate mapping rules since v1 is updated then the duplicate mapping rules are never removed by the reconciliation. When a duplicate mapping rule is added via an update to an existing Product CR then the operator will not create the duplicate, it will always create the mapping rule in the last position defined in the yaml in case it is a duplicate. This helps to distinguish the behaviour of the operator between the CREATE and UPDATE actions and when the duplicate mapping rule was present.

Expected behaviour

When applying an update to a CR that contains 1 or more duplicate mapping rules those are saved in 3scale as defined in the CR yaml. No reconciliation takes place after this where a new version of the proxy config object is generated even though no data was modified.

IMPORTANT:

The updated proxy config file looks like it has data modified but it is not the case. Simply the order of the mapping rules changes as per the JSON spec so when doing a diff of the files it initially looks like the IDs are being updated but they are only changing order.

According to THREESCALE-1884 duplicated mapping rules was reported but never fixed so this should be reopened to fix this as it is a bug in system. Currently the operator allows duplicates to be created as does the API and the UI, it however does not allow duplicates to be updated and so there is now an inconsistent behaviour between the CREATE and UPDATE actions in the operator as well as inconsistent behaviour between the operator and the system UI & API. I am not sure why the API is allowing the PATCH to be executed by the operator if no data has changed so this needs investigation also.

FINAL NOTE: I think THREESCALE-1884 should be fixed and we should not allow duplicate mapping rules, there are no known use cases where customers depend on this. Therefore a decision needs to be made about how to fix the operator, should it fix the incosistency withing the operator according to current system behaviour or wait for system to fix the bug then add the new behaviour to the operator? Either way we have bugs in both components as it currently stands.