Adds kube resize end-to-end test

[akram]

• Uses an TEST_MORE environment variable to run addition tests
• additional tests are expected to be found under hack/more-end-to-end-tests/ directory
• spawn a replication controller in testrc namespace using hello-openshift image
• increase the number of replicas
• check that the number of pods are increased
• decrease the number of replicas
• check that the number of pods are decreased

[mfojtik]

@akram is there a reason to have both Template and Config JSON in the repo? I mean you can create the Config by processing the Template.

[ncdc]

Why is there a test more var? Are these tests that aren't valuable for normal e2e?

Sent from my iPhone

On Apr 21, 2015, at 6:29 AM, Akram Ben Aissi notifications@github.com wrote:

Uses an TEST_MORE environment variable to run addition tests
additional tests are expected to be found under hack/more-end-to-end-tests/ directory
spawn a replication controller in testrc namespace using hello-openshift image
increase the number of replicas
check that the number of pods are increased
decrease the number of replicas
check that the number of pods are decreased
You can view, comment on, or merge this pull request online at:

#1832

Commit Summary

Adds kube resize end-to-end test
File Changes

A examples/hello-openshift/hello-replication-controller.json (66)
A examples/hello-openshift/hello-template.json (61)
A hack/more-end-to-end-tests/test-kube-resize-command.sh (50)
M hack/test-end-to-end.sh (11)
Patch Links:

https://github.com/openshift/origin/pull/1832.patch
https://github.com/openshift/origin/pull/1832.diff
—
Reply to this email directly or view it on GitHub.

[akram]

Hi
@ncdc
I wanted to reach consensus on the question if those tests should be run everytime or not

If you think so, I have no problem removing the variable.

Sent from mobile

On 21 avr. 2015, at 12:56, Andy Goldstein notifications@github.com wrote:

Why is there a test more var? Are these tests that aren't valuable for normal e2e?

Sent from my iPhone

On Apr 21, 2015, at 6:29 AM, Akram Ben Aissi notifications@github.com wrote:

Uses an TEST_MORE environment variable to run addition tests
additional tests are expected to be found under hack/more-end-to-end-tests/ directory
spawn a replication controller in testrc namespace using hello-openshift image
increase the number of replicas
check that the number of pods are increased
decrease the number of replicas
check that the number of pods are decreased
You can view, comment on, or merge this pull request online at:

#1832

Commit Summary

Adds kube resize end-to-end test
File Changes

A examples/hello-openshift/hello-replication-controller.json (66)
A examples/hello-openshift/hello-template.json (61)
A hack/more-end-to-end-tests/test-kube-resize-command.sh (50)
M hack/test-end-to-end.sh (11)
Patch Links:

https://github.com/openshift/origin/pull/1832.patch
https://github.com/openshift/origin/pull/1832.diff
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

[akram]

@mfojtik
For my use case, I wanted to avoid a additional processing of the template to only create the config. I didn't want to rely on processing the template to do these checks.

Thinking about it, it could be useful to add an assertion on the processing, that would ensure that processing remains consistent.

If you agree, I can rely on processing, but I want to add an additional test on the resulting processing compared to the Config that I added. Any opinion ?

[smarterclayton]

These tests should be part of hack/test-cmd, not hack/test-end-to-end. There's no reason we need a kubelet running to test this.

[akram]

@smarterclayton: these tests check that pods are actually spawned+destroyed+respwaned and hence requires docker to be running (and also a kubelet I presume).
If not, can you please point to an example of an equivalent test that does not require kubelet in test-cmd, I can't see any.

[smarterclayton]

I don't want to verify that here. Upstream verifies all that - there should be the primary test (CLI -> API) and then a maybe a deeper test (extended) that verifies pods get recreated. The two shouldn't be lumped together. The latter test is something you could very simply in e2e but I don't want e2e verifying duplicate things from what hack/test-cmd can verify.

----- Original Message -----

@smarterclayton: these tests check that pods are actually
spawned+destroyed+respwaned and hence requires docker to be running (and
also a kubelet I presume).
If not, can you please point to an example of an equivalent test that does
not require kubelet in test-cmd, I can't see any.

---

Reply to this email directly or view it on GitHub:
#1832 (comment)

[akram]

For the kube resize test, this is not doing duplicate verification:

• test-cmd.sh only check that the command runs and return with exit code 0
• test-e2e.sh checks that upsizing deploys new pods up to the specified
  replicas count, and down sizing destroy pods until reaching the
  specified replica count.

This is possibly checked upstream, but the openshift wrapping is not e2e
tested, even if in this case, that is probably a straight forward passing.

Le 22/04/15 17:10, Clayton Coleman a écrit :

I don't want to verify that here. Upstream verifies all that - there
should be the primary test (CLI -> API) and then a maybe a deeper test
(extended) that verifies pods get recreated. The two shouldn't be
lumped together. The latter test is something you could very simply in
e2e but I don't want e2e verifying duplicate things from what
hack/test-cmd can verify.

----- Original Message -----

@smarterclayton: these tests check that pods are actually
spawned+destroyed+respwaned and hence requires docker to be running (and
also a kubelet I presume).
If not, can you please point to an example of an equivalent test
that does
not require kubelet in test-cmd, I can't see any.

---

Reply to this email directly or view it on GitHub:
#1832 (comment)

—
Reply to this email directly or view it on GitHub
#1832 (comment).

[smarterclayton]

test-cmd has the replication controllers running - there's no reason it can't test the controller behavior.