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
Add Status subresource to ClusterGroup CRD #1778
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1778 +/- ##
=======================================
Coverage ? 62.00%
=======================================
Files ? 192
Lines ? 16387
Branches ? 0
=======================================
Hits ? 10161
Misses ? 5174
Partials ? 1052
Flags with carried forward coverage won't be shown. Click here to find out more. |
73dc816
to
81fe802
Compare
pkg/apis/core/v1alpha2/types.go
Outdated
// GroupPending means the Group has been accepted by the system, but it has not been processed by Antrea. | ||
GroupPending GroupPhase = "Pending" | ||
// GroupRealized means the Group has realized all of its GroupMembers. | ||
GroupRealized GroupPhase = "Realized" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel "Realized" does not best fit Groups, as it just means the Group members are computed? But we want to use the same terms for all CRDs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i considered "Processed" and "Computed". Was not sure about either so stick with what is already used in NetworkPolicyStatus
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or do you think this (computed) is like a condition? @tnqn
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just took a look at K8s API convention to understand the difference between phase and condition, looks like they are for same purpose and phase is a deprecated usage:
Some resources in the v1 API contain fields called phase, and associated message, reason, and other status fields. The pattern of using phase is deprecated. Newer API types should use conditions instead. Phase was essentially a state-machine enumeration field, that contradicted system-design principles and hampered evolution, since adding new enum values breaks backward compatibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for the link.. makes sense to transition to Conditions.. here i propose the following:
status:
conditions:
- type: GroupMembersReady
status: "True"/"False"
lastTransitionTime: "2021-1-25T16:29:31Z"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about GroupMembersComputed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about GroupMembersComputed?
i don't have a strong opinion. I was now thinking of using the plain commonly used term Ready
or Succeeded
for type
value, will post patch with GroupMembersComputed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. No strong preference either. Would let you decide.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
4cd3da1
to
c29adef
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
|
||
// groupMembersComputedConditionEqual checks whether the condition status for GroupMembersComputed condition | ||
// is same. Returns true if equal, otherwise returns false. It disregards the lastTransitionTime field. | ||
func groupMembersComputedConditionEqual(conds []corev1a2.GroupCondition, condition corev1a2.GroupCondition) bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe later this function can be more generic to compare all desired conditions and actual condition, assuming the actual conditions should be in the same order of the desired conditions as they are updated to API in this order.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks.. will do in a follow up
/test-all |
simple rebase to get some jobs passing /test-all |
Add
status
sub resource to ClusterGroup CRD. Thestatus
will store the conditions associated with a CG.Currently, supported values for
status.conditions
are conditions of typeGroupMembersComputed
. The conditionstatus
of theGroupMembersComputed
will store whether the CG has computed its members. Valid values for the conditionstatus
ofGroupMembersComputed
type are "True" and "False". The conditionstatus
will be updated by the controller to "True" once group members have been calculated and updated to the corresponding internal Group.The Status of the ClusterGroup can be retrieved by performing the following GET: