Add some unit tests for apply on TPR #40841

mengqiy · 2017-02-02T02:48:51Z

Copied from #40666 (comment)

Initial attempt: #40775

We should at least have the following unit tests:

create object with unknown group/version (covers TPR creation scenario)
changing patch of object with unknown group/version (covers TPR apply scenario)
no-op patch (idempotent apply) object with unknown group/version (covers TPR re-apply scenario)
changing patch of known object (like deployments) in an unknown version (will need to add the unknown version to the fake discovery doc - see cf74abd#diff-685443e183899c880f3c3150021d7229 as an example) - makes sure kubectl is resilient to future versions of known objects being introduced

The text was updated successfully, but these errors were encountered:

mengqiy · 2017-02-02T02:49:18Z

@ahakanbaba This is for you.

ahakanbaba · 2017-02-02T07:01:53Z

Thanks I will follow up with this.

mengqiy · 2017-02-03T18:38:36Z

@ahakanbaba You should be good to go. #40666 merged.

ahakanbaba · 2017-02-03T22:38:11Z

Thanks

ahakanbaba · 2017-02-03T22:41:25Z

@GnawNom This is the issue we can collaborate on.
I will mention this issue in my PR's so you can also keep track.

ahakanbaba · 2017-02-07T00:17:50Z

@GnawNom I will work on
no-op patch (idempotent apply) object with unknown group/version (covers TPR re-apply scenario)
first.
FYI .

The test in apply_test follows the general pattern of other tests. We load from a file in test/fixtures and mock the API server in the function closure in the HttpClient call. The apply operation expects a last-modified-configuration annotation. That is written verbatim in the test/fixture file. References kubernetes#40841

The tests in apply_test follows the general pattern of other tests. We load from a file in test/fixtures and mock the API server in the function closure in the HttpClient call. In PATCH request rount-tripper we check that the kubectl apply implementation worked as expected. References kubernetes#40841

Automatic merge from submit-queue (batch tested with PRs 41937, 41151, 42092, 40269, 42135) Add a unit test for idempotent applys to the TPR entries. The test in apply_test follows the general pattern of other tests. We load from a file in test/fixtures and mock the API server in the function closure in the HttpClient call. The apply operation expects a last-modified-configuration annotation. That is written verbatim in the test/fixture file. References #40841 **What this PR does / why we need it**: Adds one unit test for TPR's using applies. **Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes # References: kubernetes/enhancements#95 #40841 (comment) **Special notes for your reviewer**: I am not super proud of the tpr-entry name. But I feel like we need to call the two objects differently. The one which has Kind:ThirdPartyResource and the one has Kind:Foo. Is the name "ThirdPartyResource" used interchangeably for both ? I used tpr-entry for the Kind:Foo object. Also I !assume! this is testing an idempotent apply because the last-applied-configuration annotation is the same as the object itself. This is the state I see in the logs of kubectl if I do a proper idempotent apply of a third party resource entry. I guess I will know more once I start playing around with apply command that change TPR objects. **Release note**: ```release-note ```

0xmichalis · 2017-06-21T20:17:58Z

/sig apps

0xmichalis · 2017-06-21T20:18:05Z

/sig api-machinery

fejta-bot · 2017-12-29T11:23:41Z

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

liggitt · 2018-01-16T00:17:40Z

These exist now:

kubernetes/hack/make-rules/test-cmd-util.sh

Lines 1731 to 1852 in bc0e706

    
           # Test that we can create single item via apply 
        
           kubectl "${kube_flags[@]}" apply -f hack/testdata/CRD/foo.yaml 
        
           # Test that we have create a foo named test 
        
           kube::test::get_object_assert foos "{{range.items}}{{$id_field}}:{{end}}" 'test:' 
        
           # Test that the field has the expected value 
        
           kube::test::get_object_assert foos/test '{{.someField}}' 'field1' 
        
           # Test that apply an empty patch doesn't change fields 
        
           kubectl "${kube_flags[@]}" apply -f hack/testdata/CRD/foo.yaml 
        
           # Test that the field has the same value after re-apply 
        
           kube::test::get_object_assert foos/test '{{.someField}}' 'field1' 
        
           # Test that apply has updated the subfield 
        
           kube::test::get_object_assert foos/test '{{.nestedField.someSubfield}}' 'subfield1' 
        
           # Update a subfield and then apply the change 
        
           kubectl "${kube_flags[@]}" apply -f hack/testdata/CRD/foo-updated-subfield.yaml 
        
           # Test that apply has updated the subfield 
        
           kube::test::get_object_assert foos/test '{{.nestedField.someSubfield}}' 'modifiedSubfield' 
        
           # Test that the field has the expected value 
        
           kube::test::get_object_assert foos/test '{{.nestedField.otherSubfield}}' 'subfield2' 
        
           # Delete a subfield and then apply the change 
        
           kubectl "${kube_flags[@]}" apply -f hack/testdata/CRD/foo-deleted-subfield.yaml 
        
           # Test that apply has deleted the field 
        
           kube::test::get_object_assert foos/test '{{.nestedField.otherSubfield}}' '<no value>' 
        
           # Test that the field does not exist 
        
           kube::test::get_object_assert foos/test '{{.nestedField.newSubfield}}' '<no value>' 
        
           # Add a field and then apply the change 
        
           kubectl "${kube_flags[@]}" apply -f hack/testdata/CRD/foo-added-subfield.yaml 
        
           # Test that apply has added the field 
        
           kube::test::get_object_assert foos/test '{{.nestedField.newSubfield}}' 'subfield3' 
        
           # Delete the resource 
        
           kubectl "${kube_flags[@]}" delete -f hack/testdata/CRD/foo.yaml 
        
           # Make sure it's gone 
        
           kube::test::get_object_assert foos "{{range.items}}{{$id_field}}:{{end}}" '' 
        
           # Test that we can create list via apply 
        
           kubectl "${kube_flags[@]}" apply -f hack/testdata/CRD/multi-crd-list.yaml 
        
           # Test that we have create a foo and a bar from a list 
        
           kube::test::get_object_assert foos "{{range.items}}{{$id_field}}:{{end}}" 'test-list:' 
        
           kube::test::get_object_assert bars "{{range.items}}{{$id_field}}:{{end}}" 'test-list:' 
        
           # Test that the field has the expected value 
        
           kube::test::get_object_assert foos/test-list '{{.someField}}' 'field1' 
        
           kube::test::get_object_assert bars/test-list '{{.someField}}' 'field1' 
        
           # Test that re-apply an list doesn't change anything 
        
           kubectl "${kube_flags[@]}" apply -f hack/testdata/CRD/multi-crd-list.yaml 
        
           # Test that the field has the same value after re-apply 
        
           kube::test::get_object_assert foos/test-list '{{.someField}}' 'field1' 
        
           kube::test::get_object_assert bars/test-list '{{.someField}}' 'field1' 
        
           # Test that the fields have the expected value 
        
           kube::test::get_object_assert foos/test-list '{{.someField}}' 'field1' 
        
           kube::test::get_object_assert bars/test-list '{{.someField}}' 'field1' 
        
           # Update fields and then apply the change 
        
           kubectl "${kube_flags[@]}" apply -f hack/testdata/CRD/multi-crd-list-updated-field.yaml 
        
           # Test that apply has updated the fields 
        
           kube::test::get_object_assert foos/test-list '{{.someField}}' 'modifiedField' 
        
           kube::test::get_object_assert bars/test-list '{{.someField}}' 'modifiedField' 
        
           # Test that the field has the expected value 
        
           kube::test::get_object_assert foos/test-list '{{.otherField}}' 'field2' 
        
           kube::test::get_object_assert bars/test-list '{{.otherField}}' 'field2' 
        
           # Delete fields and then apply the change 
        
           kubectl "${kube_flags[@]}" apply -f hack/testdata/CRD/multi-crd-list-deleted-field.yaml 
        
           # Test that apply has deleted the fields 
        
           kube::test::get_object_assert foos/test-list '{{.otherField}}' '<no value>' 
        
           kube::test::get_object_assert bars/test-list '{{.otherField}}' '<no value>' 
        
           # Test that the fields does not exist 
        
           kube::test::get_object_assert foos/test-list '{{.newField}}' '<no value>' 
        
           kube::test::get_object_assert bars/test-list '{{.newField}}' '<no value>' 
        
           # Add a field and then apply the change 
        
           kubectl "${kube_flags[@]}" apply -f hack/testdata/CRD/multi-crd-list-added-field.yaml 
        
           # Test that apply has added the field 
        
           kube::test::get_object_assert foos/test-list '{{.newField}}' 'field3' 
        
           kube::test::get_object_assert bars/test-list '{{.newField}}' 'field3' 
        
           # Delete the resource 
        
           kubectl "${kube_flags[@]}" delete -f hack/testdata/CRD/multi-crd-list.yaml 
        
           # Make sure it's gone 
        
           kube::test::get_object_assert foos "{{range.items}}{{$id_field}}:{{end}}" '' 
        
           kube::test::get_object_assert bars "{{range.items}}{{$id_field}}:{{end}}" '' 
        
           ## kubectl apply --prune 
        
           # Test that no foo or bar exist 
        
           kube::test::get_object_assert foos "{{range.items}}{{$id_field}}:{{end}}" '' 
        
           kube::test::get_object_assert bars "{{range.items}}{{$id_field}}:{{end}}" '' 
        
           # apply --prune on foo.yaml that has foo/test 
        
           kubectl apply --prune -l pruneGroup=true -f hack/testdata/CRD/foo.yaml "${kube_flags[@]}" --prune-whitelist=company.com/v1/Foo --prune-whitelist=company.com/v1/Bar 
        
           # check right crds exist 
        
           kube::test::get_object_assert foos "{{range.items}}{{$id_field}}:{{end}}" 'test:' 
        
           kube::test::get_object_assert bars "{{range.items}}{{$id_field}}:{{end}}" '' 
        
           # apply --prune on bar.yaml that has bar/test 
        
           kubectl apply --prune -l pruneGroup=true -f hack/testdata/CRD/bar.yaml "${kube_flags[@]}" --prune-whitelist=company.com/v1/Foo --prune-whitelist=company.com/v1/Bar 
        
           # check right crds exist 
        
           kube::test::get_object_assert foos "{{range.items}}{{$id_field}}:{{end}}" '' 
        
           kube::test::get_object_assert bars "{{range.items}}{{$id_field}}:{{end}}" 'test:'

/close

mengqiy mentioned this issue Feb 2, 2017

apply falls back to generic JSON patch computation if no go struct is registered for the target GVK #40666

Merged

6 tasks

ahakanbaba mentioned this issue Feb 4, 2017

Added the first TPR unit test. #40956

Closed

ahakanbaba mentioned this issue Feb 8, 2017

Add a unit test for idempotent applys to the TPR entries. #41151

Merged

ahakanbaba mentioned this issue Feb 15, 2017

Umbrella Issue for Box-affecting issues #39900

Closed

liggitt added the area/custom-resources label Apr 14, 2017

k8s-github-robot added the needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. label May 31, 2017

k8s-ci-robot added the sig/apps Categorizes an issue or PR as relevant to SIG Apps. label Jun 21, 2017

k8s-ci-robot added the sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. label Jun 21, 2017

k8s-github-robot removed the needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. label Jun 21, 2017

enisoc added this to Backlog in CustomResourceDefinition Jul 13, 2017

k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Dec 29, 2017

k8s-ci-robot closed this as completed Jan 16, 2018

liggitt moved this from Backlog to Done in CustomResourceDefinition Jan 16, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add some unit tests for apply on TPR #40841

Add some unit tests for apply on TPR #40841

mengqiy commented Feb 2, 2017

mengqiy commented Feb 2, 2017

ahakanbaba commented Feb 2, 2017

mengqiy commented Feb 3, 2017

ahakanbaba commented Feb 3, 2017

ahakanbaba commented Feb 3, 2017

ahakanbaba commented Feb 7, 2017

0xmichalis commented Jun 21, 2017

0xmichalis commented Jun 21, 2017

fejta-bot commented Dec 29, 2017

liggitt commented Jan 16, 2018

Add some unit tests for apply on TPR #40841

Add some unit tests for apply on TPR #40841

Comments

mengqiy commented Feb 2, 2017

mengqiy commented Feb 2, 2017

ahakanbaba commented Feb 2, 2017

mengqiy commented Feb 3, 2017

ahakanbaba commented Feb 3, 2017

ahakanbaba commented Feb 3, 2017

ahakanbaba commented Feb 7, 2017

0xmichalis commented Jun 21, 2017

0xmichalis commented Jun 21, 2017

fejta-bot commented Dec 29, 2017

liggitt commented Jan 16, 2018