Enhance Condition Messages for Better Clarity and Debugging

[sankett45]

1. Problem Statement

   • The status.conditions field does not fully adhere to Kubernetes conventions.
   • Condition messages are not human-readable and do not clearly convey the observed state.
   • Condition names and structure need improvements to align with Kubernetes best practices.

2. Step 1: Standardizing Condition Types

   • Renamed condition types to follow PascalCase naming conventions.
   • Ensured condition names are concise and reflect the observed state rather than state transitions.

3. Step 2: Improving Condition Messages

   • Modified condition messages to be clear, human-readable sentences.
   • Ensured messages provide meaningful context about the current resource state.

4. Step 3: Refining Condition Reasons

   • Standardized condition reasons to be short, structured, and easy to understand.
   • Used concise, relevant terms such as FaultyGraph, InvalidCEL, and CRDNotSynced.

5. Outcome

   • status.conditions now follow Kubernetes conventions.
   • Messages and reasons provide better debugging insights.
   • Condition structure is more intuitive and standardized.

[sankett45]

@a-hilaly do check out this solution for issue #415 suggest any changes if any

[n3wscott]

I wonder if we need to let err.Error into the condition message?

[n3wscott]

Good catch! Condition Reason needs to be a Key not a free form text field.

[n3wscott]

I am shocked setting reason to "" worked before, this violates the built in type validation of conditions if you use the upstream open api.