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

Add Status subresource to ClusterGroup CRD #1778

Merged
merged 3 commits into from Jan 29, 2021
Merged

Conversation

abhiraut
Copy link
Contributor

@abhiraut abhiraut commented Jan 23, 2021

Add status sub resource to ClusterGroup CRD. The status will store the conditions associated with a CG.
Currently, supported values for status.conditions are conditions of type GroupMembersComputed. The condition status of the GroupMembersComputed will store whether the CG has computed its members. Valid values for the condition status of GroupMembersComputed type are "True" and "False". The condition status 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:

eg: Get status for ClusterGroup "mycg"
GET $K8sAPI/apis/core.antrea.tanzu.vmware.com/v1alpha2/clustergroups/mycg

{
   "apiVersion":"core.antrea.tanzu.vmware.com/v1alpha2",
   "kind":"ClusterGroup",
   "metadata":{
      "annotations":{
         "kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"core.antrea.tanzu.vmware.com/v1alpha2\",\"kind\":\"ClusterGroup\",\"metadata\":{\"annotations\":{},\"name\":\"mycg\"},\"spec\":{\"podSelector\":{\"matchLabels\":{\"k8s-app\":\"kube-dns\"}}}}\n"
      },
      "creationTimestamp":"2021-01-29T19:59:42Z",
      "generation":1,
      "managedFields":[
         {
            "apiVersion":"core.antrea.tanzu.vmware.com/v1alpha2",
            "fieldsType":"FieldsV1",
            "fieldsV1":{
               "f:status":{
                  ".":{
                     
                  },
                  "f:conditions":{
                     
                  }
               }
            },
            "manager":"antrea-controller",
            "operation":"Update",
            "time":"2021-01-29T19:59:42Z"
         },
         {
            "apiVersion":"core.antrea.tanzu.vmware.com/v1alpha2",
            "fieldsType":"FieldsV1",
            "fieldsV1":{
               "f:metadata":{
                  "f:annotations":{
                     ".":{
                        
                     },
                     "f:kubectl.kubernetes.io/last-applied-configuration":{
                        
                     }
                  }
               },
               "f:spec":{
                  ".":{
                     
                  },
                  "f:podSelector":{
                     
                  }
               }
            },
            "manager":"kubectl-client-side-apply",
            "operation":"Update",
            "time":"2021-01-29T19:59:42Z"
         }
      ],
      "name":"mycg",
      "resourceVersion":"611970",
      "uid":"7d2d3d15-bd7d-4f24-a07e-c756bab47579"
   },
   "spec":{
      "podSelector":{
         "matchLabels":{
            "k8s-app":"kube-dns"
         }
      }
   },
   "status":{
      "conditions":[
         {
            "lastTransitionTime":"2021-01-29T19:59:39Z",
            "status":"True",
            "type":"GroupMembersComputed"
         }
      ]
   }
}

@codecov-io
Copy link

codecov-io commented Jan 23, 2021

Codecov Report

❗ No coverage uploaded for pull request base (main@b9bd4bb). Click here to learn what that means.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##             main    #1778   +/-   ##
=======================================
  Coverage        ?   62.00%           
=======================================
  Files           ?      192           
  Lines           ?    16387           
  Branches        ?        0           
=======================================
  Hits            ?    10161           
  Misses          ?     5174           
  Partials        ?     1052           
Flag Coverage Δ
e2e-tests 26.56% <0.00%> (?)
kind-e2e-tests 49.64% <0.00%> (?)
unit-tests 42.83% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

pkg/controller/networkpolicy/clustergroup.go Outdated Show resolved Hide resolved
pkg/controller/networkpolicy/clustergroup.go Outdated Show resolved Hide resolved
pkg/controller/networkpolicy/clustergroup.go Outdated Show resolved Hide resolved
pkg/controller/networkpolicy/networkpolicy_controller.go Outdated Show resolved Hide resolved
@abhiraut abhiraut force-pushed the cg-status branch 2 times, most recently from 73dc816 to 81fe802 Compare January 25, 2021 21:34
Base automatically changed from master to main January 26, 2021 00:00
// 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"
Copy link
Contributor

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?

Copy link
Contributor Author

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

Copy link
Contributor

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

Copy link
Member

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.

https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties

Copy link
Contributor Author

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"

Copy link
Contributor

Choose a reason for hiding this comment

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

How about GroupMembersComputed?

Copy link
Contributor Author

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

Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

jianjuns
jianjuns previously approved these changes Jan 28, 2021
Copy link
Contributor

@jianjuns jianjuns left a 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 {
Copy link
Member

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.

Copy link
Contributor Author

@abhiraut abhiraut Jan 29, 2021

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

tnqn
tnqn previously approved these changes Jan 29, 2021
@abhiraut
Copy link
Contributor Author

/test-all

@abhiraut abhiraut dismissed stale reviews from tnqn and jianjuns via ce2ebb2 January 29, 2021 19:27
@abhiraut
Copy link
Contributor Author

simple rebase to get some jobs passing

/test-all

@abhiraut
Copy link
Contributor Author

@jianjuns @Dyanngg can i get another review, I had to rebase after Quan's review to get some jobs running successfully. Thanks.

@abhiraut abhiraut added this to the Antrea v0.13.0 release milestone Jan 29, 2021
@abhiraut abhiraut merged commit 606b161 into antrea-io:main Jan 29, 2021
@abhiraut abhiraut deleted the cg-status branch January 29, 2021 22:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants