Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: print diff resource as yaml #2542

Merged

Conversation

10000-ki
Copy link
Contributor

@10000-ki 10000-ki commented Sep 29, 2024

resolved: #2492

AS-IS

Output diff data in text format

{data={key1=val1}, metadata={ownerReferences=[{name=kube-root-ca.crt, uid=1ef74cb4-dbbd-45ef-9caf-aa76186594ea, apiVersion=v1, kind=ConfigMap}]}}

{metadata={ownerReferences=[{apiVersion=v1, kind=ConfigMap, name=kube-root-ca.crt, uid=1ef74cb4-dbbd-45ef-9caf-aa76186594ea}]}, data={key1=different value}}
  • problem : It's difficult to compare

TO-BE

Output diff data in yml format

data:
  key1: "val1"
metadata:
  ownerReferences:
  - name: "kube-root-ca.crt"
    uid: "1ef74cb4-dbbd-45ef-9caf-aa76186594ea"
    apiVersion: "v1"
    kind: "ConfigMap"
 
 ---
metadata:
  ownerReferences:
  - apiVersion: "v1"
    kind: "ConfigMap"
    name: "kube-root-ca.crt"
    uid: "1ef74cb4-dbbd-45ef-9caf-aa76186594ea"
data:
  key1: "different value"

If the user sorts fields through Jackson settings .enable(SerializationFeature.ORDER_MAP_ENTRIES_BY_KEYS)
it will look much better because the keys will be displayed in sorted order.


log.debug("Pruned actual: \n {} \n desired: \n {} ", prunedActual, desiredMap);
var actualYml = objectMapper.asYaml(prunedActual);
var desiredYml = objectMapper.asYaml(desiredMap);
log.debug("Pruned actual: \n {} \n desired: \n {} ", actualYml, desiredYml);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is possible to use a library or write code to compare YAML files. However, as the size of the YAML file increases, the cost of processing grows. Therefore, I have not added this functionality here and simply focused on outputting the data.

If deemed necessary, I can consider adding it in the future.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure that the sorting would make that much of a difference compared to serializing to YAML in the first place…

Signed-off-by: 10000-ki <[email protected]>
@10000-ki
Copy link
Contributor Author

10000-ki commented Sep 29, 2024

As mentioned above, users can configure Jackson to sort field keys when logging YAML files by enabling the SerializationFeature.ORDER_MAP_ENTRIES_BY_KEYS setting
This ensures that the YAML fields are ordered alphabetically, making the log output more readable and consistent

However, I'm not sure if this should be supported directly within josdk. Since sorting itself incurs a performance cost, it might be better to allow users to opt-in selectively if they need it, rather than enabling it by default.

@@ -104,7 +104,9 @@ public boolean matches(R actual, R desired, Context<?> context) {
removeIrrelevantValues(desiredMap);

if (LoggingUtils.isNotSensitiveResource(desired)) {
log.debug("Pruned actual: \n {} \n desired: \n {} ", prunedActual, desiredMap);
var actualYaml = objectMapper.asYaml(prunedActual);
Copy link
Collaborator

@metacosm metacosm Sep 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would protect these calls with a check to whether debug is enabled so as to not incur the YAML serialization cost in that situation.

Copy link
Contributor Author

@10000-ki 10000-ki Sep 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would protect these calls with a check to whether debug is enabled so as to not incur the YAML serialization cost in that situation.

yes it would be better thank you, i will fix it

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@metacosm
72911d6

fixed it in this commit

thank you!!

Copy link
Collaborator

@metacosm metacosm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

var desiredYaml = serialization.asYaml(desiredMap);
log.debug("Pruned actual yaml: \n {} \n desired yaml: \n {} ", actualYaml, desiredYaml);
} else {
log.debug("Pruned actual map: \n {} \n desired map: \n {} ", prunedActualMap, desiredMap);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if I follow this. "If debug is not enabled we log something on debug" ?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yes, missed that, though there should actually be no output since debug is checked internally (iirc) but it does make sense to remove the else branch altogether, indeed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://github.com/operator-framework/java-operator-sdk/pull/2542/files#diff-7568f2dc58ce3a6a5d7ce2d5227aeb49402136b091fb19a4d8cadb28351ce709L107

we remain the debug logging regardless of whether the debug mode was enabled.
Would it be better to remove the else block?

Although the cost of the else block itself doesn't seem significant, I'd like to hear your thoughts.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I mean is that the else block never logs any message, since only called if no debug is enabled but logs on debug level.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@csviri

Ah understand

96920ab

I thought it would be better to just remove this part, so I modified it as shown above. What do you think?

Copy link
Collaborator

@csviri csviri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@csviri csviri merged commit 7ba6f8a into operator-framework:next Sep 30, 2024
20 checks passed
@csviri
Copy link
Collaborator

csviri commented Sep 30, 2024

Thank you @10000-ki !

@bachmanity1
Copy link
Contributor

bachmanity1 commented Oct 2, 2024

Hi @10000-ki. Thanks for the PR!

I think printing the whole actual and desired resource is a bit inconvenient since we still need to copy and paste it into other tools to get the real diff. How about improving the logging logic to directly print the actual diff, like shown below?

2024-10-02 14:30:29,489 1 i.j.o.p.d.k.SSABasedGenericKubernetesResourceMatcher [DEBUG] Diff between actual and desired state for resource: Deployment with name: test in namespace: default is: 
--- 
+++ 
@@ -15,1 +15,1 @@
-      - image: "nginx:1.17.0"
+      - image: "nginx:1.17.1"

I can work on this if you think the change would be helpful.

@metacosm
Copy link
Collaborator

metacosm commented Oct 2, 2024

Hi @bachmanity1,

I was kind of thinking the same thing but seeing the resource in YAML format is already helpful. We'd happily consider a PR to output the actual diffs! Keep in mind, though, that we want to keep this output as efficient as possible so it should probably be only activated via a flag.

@10000-ki
Copy link
Contributor Author

10000-ki commented Oct 2, 2024

@bachmanity1

I think printing the whole actual and desired resource is a bit inconvenient since we still need to copy and paste it into other tools to get the real diff. How about improving the logging logic to directly print the actual diff, like shown below?

oh sure great!!

metacosm pushed a commit that referenced this pull request Oct 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants