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 crd #306

Merged
merged 6 commits into from
Jul 31, 2018
Merged

Add crd #306

merged 6 commits into from
Jul 31, 2018

Conversation

dturn
Copy link
Contributor

@dturn dturn commented Jun 28, 2018

Add CRD Resource (part of splitting of https://github.com/Shopify/kubernetes-deploy/pull/188/files)

Success of failure based on the NamesAccepted status condition. Is not very sophisticated, but better than nothing.

screen shot 2018-07-17 at 10 05 31 am

@dturn dturn requested review from KnVerey, klautcomputing and karanthukral and removed request for karanthukral June 28, 2018 00:56
@dturn dturn mentioned this pull request Jul 6, 2018
@karanthukral
Copy link
Contributor

Looks good to me. Simple to start 👍

Copy link
Contributor

@KnVerey KnVerey left a comment

Choose a reason for hiding this comment

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

We also need to do something to clean up the CRDs after every test, otherwise the success tests in particular won't be valid (because the CRD will actually predate them if any of the hello-cloud test have run against that cluster).

if !exists?
super
elsif deploy_succeeded?
"Succeeded"
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 something more specific to what a CRD success means, like maybe "Registered" or even "Names accepted"?

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 wasn't sure if this was a place to be specific or match what other resources. Given the timeout_message "Names accepted" seems good to me

end

def timeout_message
UNUSUAL_FAILURE_MESSAGE
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's be more specific about what happened here, e.g. "The names this CRD is attempting to register were neither accepted nor rejected in time"

# frozen_string_literal: true
module KubernetesDeploy
class CustomResourceDefinition < KubernetesResource
TIMEOUT = 30.seconds
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd suggest being a little more generous here, since something actually does need to happen (vs. configmaps etc. where we're really just creating them and seeing that they showed up)

@@ -94,5 +95,9 @@ def assert_daemon_set_up
def assert_stateful_set_up
assert_stateful_set_present("stateful-busybox")
end

def assert_crd_up
assert_crd_present("mails.stable.example.io")
Copy link
Contributor

Choose a reason for hiding this comment

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

The mails plural still irks me :P

assert_logs_match_all([
"Deploying CustomResourceDefinition/mails.stable.example.io (timeout: 30s)",
"CustomResourceDefinition/mis-matched.stable.example.io: FAILED",
"Final status: ListKindConflict"
Copy link
Contributor

Choose a reason for hiding this comment

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

This is a little cryptic... Does the condition's message have additional information we're not printing?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I wasn't printing the message. I'll add it.

@@ -247,6 +248,10 @@ def discover_resources
@logger.info " - #{r.id}"
end
end
if (global = resources.select(&:global?).presence)
@logger.info("Detected non-namespaced #{'resouce'.pluralize(global.count)} which will never be pruned:")
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

Typo: resouce-> resource

end

def test_crd_can_fail
assert_deploy_success(deploy_fixtures("hello-cloud", subset: ["crd.yml"]))
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this first deploy necessary in this case? Won't mismatched names be rejected even on the first registration?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We're actually creating a conflict between the listKind field in the fixture vs. the slightly modified fixture. A mismatch between the name & plural is caught at validation time and isn't really what we want to test.

@dturn dturn force-pushed the add-crd branch 2 times, most recently from 3b0bb6b to 38381fd Compare July 20, 2018 23:50
@dturn
Copy link
Contributor Author

dturn commented Jul 20, 2018

We also need to do something to clean up the CRDs after every test, otherwise the success tests in particular won't be valid (because the CRD will actually predate them if any of the hello-cloud test have run against that cluster).

Because the CRD resource is global, I think the CRD test either need to create unique CRDs or not be run in parallel. I've gone with the unique route, we're polluting minikube, but I don't think that's a real issue.

Copy link
Contributor

@karanthukral karanthukral left a comment

Choose a reason for hiding this comment

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

LGTM

@timothysmith0609
Copy link
Contributor

Because the CRD resource is global, I think the CRD test either need to create unique CRDs or not be run in parallel. I've gone with the unique route, we're polluting minikube, but I don't think that's a real issue.

Could we not just delete the CRD at the end of each test run?

@dturn
Copy link
Contributor Author

dturn commented Jul 27, 2018

Could we not just delete the CRD at the end of each test run?

We can't because of the parallelism. Test 1 runs, test 2 starts, test 1 finishes and deletes the CR. This could cause test 2 to succeeded when it shouldn't have or fail because in the middle of test 2 the CR is just gone.

@KnVerey
Copy link
Contributor

KnVerey commented Jul 31, 2018

We can't because of the parallelism.

We have a file for tests that should not be run in parallel: test/integration-serial/run_serial_test.rb. Let's move these tests there and remove the CRD from the hello-cloud set.

@KnVerey
Copy link
Contributor

KnVerey commented Jul 31, 2018

I'm 👍 on the code and output now though.

@dturn dturn merged commit 62bfcd6 into master Jul 31, 2018
@dturn dturn deleted the add-crd branch August 17, 2018 22:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants