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

Implement CLI and E2E testing using the KUDO test harness. #656

Merged

Conversation

jbarrick-mesosphere
Copy link
Member

What type of PR is this?

/kind feature

What this PR does / why we need it:

This adds a kubectl setting to the KUDO test harness TestSuite and TestStep configurations to support running kubectl commands as a part of tests.

Which issue(s) this PR fixes:

Fixes #368 (support CLI commands)
Fixes #369 (support install kudo frameworks)
Fixes #520 (panic when executing test harness)

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

Test harness now supports running kubectl commands as a part of tests.

}

// Kubeconfig converts a rest.Config into a YAML kubeconfig and writes it to w
func Kubeconfig(cfg *rest.Config, w io.Writer) error {
Copy link
Member Author

Choose a reason for hiding this comment

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

I wasn't able to find a method that could convert a rest.Config to a kubeconfig already. There's a number of cases that we need to be able to support:

  • Merged kubeconfig
  • In cluster config
  • Mocked control plane (just requires setting the Server setting)
  • Kind config

In some cases we have the path and could copy it.. but other times the path might not exist or be ambiguous and we would want to generate a kubeconfig.

But maybe there's a better way to do this.. Thoughts?

@jbarrick-mesosphere
Copy link
Member Author

jbarrick-mesosphere commented Jul 26, 2019

@alenkacz that create-operator-in-operator test started failing on here pretty frequently and I noticed that when the test passes it's always close to the timeout (28 seconds or so). I think the tests I've added here have pushed it over the edge to where it times out more often than not.. But I think I'm on to something. When I limit the test parallelism to 2 tests at once instead of 4, everything is a lot faster.

This leads me to wonder if either:

  1. The test harness hammers the API server too hard with its polling.
  2. KUDO's reconciliation is slow and having multiple Instances at once can delay reconciliation.

When running the tests, I noticed the PlanExecution controller trying to fetch lots of instances even once they were deleted, I wonder if it's doing a lot of potentially unnecessary work:

2019/07/25 17:32:53 InstanceController: Received Reconcile request for instance "oio-instance-inner-instance"
2019/07/25 17:32:53 InstanceController: Received Reconcile request for instance "oio-instance"
2019/07/25 17:32:53 PlanExecutionController: Error getting Instance operator-test-instance in kudo-test-fitting-goat: Instance.kudo.dev "operator-test-instance" not found
2019/07/25 17:32:54 PlanExecutionController: Error getting Instance icto-upgrade in kudo-test-teaching-bull: Instance.kudo.dev "icto-upgrade" not found
2019/07/25 17:32:55 PlanExecutionController: Error getting Instance icto-upgrade in kudo-test-teaching-bull: Instance.kudo.dev "icto-upgrade" not found
2019/07/25 17:32:56 PlanExecutionController: Error getting Instance toy1 in kudo-test-solid-lizard: Instance.kudo.dev "toy1" not found
2019/07/25 17:32:57 PlanExecutionController: Error getting Instance operator-test-instance in kudo-test-fitting-goat: Instance.kudo.dev "operator-test-instance" not found
2019/07/25 17:32:58 PlanExecutionController: Error getting Instance icto-no-trigger in kudo-test-vast-bunny: Instance.kudo.dev "icto-no-trigger" not found
2019/07/25 17:32:59 PlanExecutionController: Error getting Instance icto-fallback-to-deploy in kudo-test-diverse-joey: Instance.kudo.dev "icto-fallback-to-deploy" not found
2019/07/25 17:33:00 PlanExecutionController: Error getting Instance icto-no-trigger in kudo-test-vast-bunny: Instance.kudo.dev "icto-no-trigger" not found
2019/07/25 17:33:01 PlanExecutionController: Error getting Instance icto-upgrade-fallback-to-deploy in kudo-test-safe-bullfrog: Instance.kudo.dev "icto-upgrade-fallback-to-deploy" not found
2019/07/25 17:33:02 PlanExecutionController: Error getting Instance racy-instance in kudo-test-supreme-dassie: Instance.kudo.dev "racy-instance" not found
2019/07/25 17:33:03 PlanExecutionController: Error getting Instance immutable-client-ip-instance in kudo-test-healthy-grub: Instance.kudo.dev "immutable-client-ip-instance" not found
2019/07/25 17:33:04 PlanExecutionController: Error getting Instance icto-custom-trigger in kudo-test-wealthy-buffalo: Instance.kudo.dev "icto-custom-trigger" not found
2019/07/25 17:33:05 PlanExecutionController: Error getting Instance icto-custom-trigger in kudo-test-wealthy-buffalo: Instance.kudo.dev "icto-custom-trigger" not found
2019/07/25 17:33:06 PlanExecutionController: Error getting Instance icto-upgrade-fallback-to-deploy in kudo-test-safe-bullfrog: Instance.kudo.dev "icto-upgrade-fallback-to-deploy" not found
2019/07/25 17:33:07 PlanExecutionController: Received update event for an instance named: oio-instance-inner-instance

@jbarrick-mesosphere
Copy link
Member Author

Yup, that did it. That last commit that makes Reconcile() in the PlanExecutionController not return an error cuts test execution time to 20 seconds:

--- PASS: kudo (19.92s)

That's down from the 76 seconds successful runs took before:

--- PASS: kudo (76.05s)

I'm going to drop that commit from here and put it into a separate PR.

@jbarrick-mesosphere
Copy link
Member Author

Okay, submitted that fix as #657 :)

pkg/test/step.go Outdated Show resolved Hide resolved
@jbarrick-mesosphere jbarrick-mesosphere modified the milestones: v0.4.0, 0.5.0 Jul 26, 2019
Copy link
Contributor

@alenkacz alenkacz left a comment

Choose a reason for hiding this comment

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

I have couple of questions but overall it looks good :)

Makefile Outdated
@@ -117,6 +117,11 @@ generate:
generate-clean:
rm -rf hack/code-gen

.PHONY: cli-test
# Build CLI for tests
cli-test:
Copy link
Contributor

Choose a reason for hiding this comment

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

why do we need a special build for tests? why is make cli not good enough?

Copy link
Member Author

Choose a reason for hiding this comment

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

make cli also runs all of the code generation and such so it takes quite a while to run (30 seconds or so?). As well as all of the linting (personally, I like to lint before I commit but that's just me). I thought it made sense to have a separate build that is quick for testing. What do you think?

Copy link
Contributor

Choose a reason for hiding this comment

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

I actually agree with you now that I think about it, everytime I am building CLI locally I hate when it stops on linting error. WDYT then about having just one build and one that is fast? If not we should at least comment why we need two.

Copy link
Member Author

Choose a reason for hiding this comment

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

So it actually occurs to me that we don't use make cli in CI or releasing at all - if it is used, it's used only by developers while developing.

Maybe we just drop the slow one then?

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm gonna take your suggestion:

make cli
make cli-fast

And then we can discuss what to do about the other targets separately.

pkg/test/case.go Show resolved Hide resolved
pkg/test/harness.go Outdated Show resolved Hide resolved
pkg/test/step.go Outdated Show resolved Hide resolved
pkg/test/step.go Outdated Show resolved Hide resolved
pkg/test/utils/kubernetes.go Outdated Show resolved Hide resolved
test/integration/cli-install/00-install.yaml Show resolved Hide resolved
Fixes kudobuilder#368 (support CLI commands)
Fixes kudobuilder#369 (support install kudo frameworks)
Fixes kudobuilder#520 (panic when executing test harness)

This adds a `kubectl` setting to the KUDO test harness TestSuite and TestStep configurations to support running kubectl commands
as a part of tests.
@jbarrick-mesosphere
Copy link
Member Author

Okay, I think I addressed everything!

Copy link
Contributor

@alenkacz alenkacz left a comment

Choose a reason for hiding this comment

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

I have only one comment in the makefile, otherwise nice work 👏

@kudo-ci
Copy link

kudo-ci commented Jul 30, 2019

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: alenkacz, jbarrick-mesosphere

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:
  • OWNERS [alenkacz,jbarrick-mesosphere]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@alenkacz
Copy link
Contributor

I've set the do not merge label to make sure you have time to see my makefile comment even though it's not a huge issue :)

@jbarrick-mesosphere
Copy link
Member Author

/hold cancel

@jbarrick-mesosphere jbarrick-mesosphere merged commit 3f45ece into kudobuilder:master Jul 31, 2019
@jbarrick-mesosphere jbarrick-mesosphere deleted the cli-testing branch July 31, 2019 00:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants