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 e2e test for console operator Unmanaged and Removed states #112

Merged
merged 1 commit into from
Jan 25, 2019

Conversation

jhadvig
Copy link
Member

@jhadvig jhadvig commented Jan 21, 2019

/assign @benjaminapetersen

Adding Unmanaged and Removed test cases.
Each tests is testing several resources from the "openshift-console" namespace - Deployment/ConfigMap/Service/Route and their availability/unavailability for each operator state.

Also added logs.go that I've get from to get better logs.

@openshift-ci-robot openshift-ci-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Jan 21, 2019
@jhadvig
Copy link
Member Author

jhadvig commented Jan 22, 2019

/test e2e-aws

@@ -0,0 +1,162 @@
package testframework
Copy link
Contributor

Choose a reason for hiding this comment

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

Thinking about this now, it might be nice to split it up. Right now it seems to be all the funcs needed just to test management state. I'd prob rather separate out feature tests than keep adding to this one file:

/pkg
   |_ testframework
        |_ console
            |_ managementstate.go
            |_ otherfeature.go
            |_ yetanotherfeature.go
        |_ deployment
        |_ etc

Thoughts?

Copy link
Member Author

Choose a reason for hiding this comment

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

Makes sense to split it here, but Im not sure what the otherfeatures will be. The ones that pop to my head are, to start/stop the operator by scaling it up and down, but that can be on a /pkg/testframework/operator.go file.
Not sure what else at this state of the console-operator we should test.

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, we will probably test the top level console config, which has, for example, LogoutRedirect. Also the Operator config itself has Branding, DocumentationBaseURL, as well as a NodeSelector override.

Eventually we may support custom Route or perhaps a set of Routes (in discussion).

@@ -19,6 +23,19 @@ var (
AsyncOperationTimeout = 5 * time.Minute
)

// Logger is an interface to report events from tests. It is implemented by
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm wondering if framework.go might grow into a kitchen sink of a file. Maybe we can break this up now & encourage future growth into separate files to keep it tidy down the road.

Copy link
Contributor

Choose a reason for hiding this comment

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

(I realize there isn't much here yet, so it could just be /framework/logging.go & framework/resourceavailabilty.go or something a bit like that.)

Copy link
Contributor

Choose a reason for hiding this comment

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

I see you have logs file below already. Nice. Was just thinking about DumpObject... hmm.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yep thats a good question. But I think it mainly depends on how beefy we want our e2e tests for the console operator. If it should just test each operator state(maybe some extra tests, scaling operator down to 0 and back to 1), I wouldn't worry about the scale of the file :)

Copy link
Contributor

Choose a reason for hiding this comment

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

Probably related to the above comment, we have a set of other features to test, but uncertain how much it will grow over time (I dont expect tons).


consoleapi "github.com/openshift/console-operator/pkg/api"
"github.com/openshift/console-operator/pkg/testframework"
)

// TestManaged sets console-operator to Managed state. After that "openshift-console
// deployment is deleted after which the deploymnet is tested for availability, together
Copy link
Contributor

Choose a reason for hiding this comment

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

deploymnet -> deployment

t.Fatal(err)

errChan := make(chan error)
go testframework.IsResourceAvailable(errChan, client, "ConfigMap")
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we want to delete each of these resources & then check each availability?

Copy link
Member Author

Choose a reason for hiding this comment

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

No only the openshift-console deployment is deleted. Wasnt sure if we want to delete all, or just some, or only one.

Copy link
Contributor

Choose a reason for hiding this comment

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

Right, only the deployment is deleted, but it checks if each of the other resources are still there.

Copy link
Member Author

Choose a reason for hiding this comment

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

yes, thinking about it now, I probably would be better to do it the opposite way. Delete more resource (eg.Deployment, Route, ConfigMap). Then check for all the resources.

@@ -57,3 +74,61 @@ func DeleteCompletely(getObject func() (metav1.Object, error), deleteObject func
return obj.GetUID() != uid, nil
})
}

// IsResourceAvailable checks if tested resource is available(recreated by console-ioerator),
Copy link
Contributor

Choose a reason for hiding this comment

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

ioerator -> operator


t.Logf("waiting to check if the operator has not recreate console deployment...")
errChan := make(chan error)
go testframework.IsResourceAvailable(errChan, client, "ConfigMap")
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we be asking for a named resources? For example, we have 2 configmaps now.

Copy link
Contributor

Choose a reason for hiding this comment

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

(other resources are singletons, though there is also more than 1 secret in the namespace)

Copy link
Member Author

Choose a reason for hiding this comment

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

yeah, so here I wasn't sure if we want to nuke all the resources, or just some, or just one?
But since the operator should recreate any resource it should be enough to just test some resources. Thoughts ? :)

Copy link
Contributor

Choose a reason for hiding this comment

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

Agree, though it might be good to know for certain it is recreating all of the expected resources. If our listOpts funcs are ever updated, it could be possible the operator would stop paying attention to a resource it needs to manage. Currently the funcs are noop except for the OAuth client func.

errChan <- err
}

func getResource(client *Clientset, resource string) error {
Copy link
Contributor

Choose a reason for hiding this comment

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

Thinking about this:

// current unnamed
getResource(client, 'ConfigMap')
// vs named?
getResource(client, 'configmap', 'console-config')
// vs specific-to-client funcs?
getConfigmapByName('console-config')
getSecretByName('oauth-config')

Copy link
Member Author

Choose a reason for hiding this comment

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

Makes sense to have resource based getters 👍

Copy link
Contributor

Choose a reason for hiding this comment

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

Realized it doesn't actually get the resource, it returns only an error. So if you don't want to make specific ones, since this is more of a helper, it could be something like resourceExists()

if err != nil {
DumpObject(logger, "the latest observed state of the console resource", cr)
DumpOperatorLogs(logger, client)
return fmt.Errorf("failed to wait to change console operator state to 'Removed': %s", err)
Copy link
Contributor

Choose a reason for hiding this comment

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

This branch is always operator state to 'Removed'?

Copy link
Member Author

Choose a reason for hiding this comment

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

nope, will update ! :)


type operatorStateReactionFn func(cr *v1alpha1.Console) bool

func ensureConsoleIsInDesiredState(logger Logger, client *Clientset, state operatorsv1alpha1.ManagementState) error {
Copy link
Contributor

Choose a reason for hiding this comment

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

So ensureConsoleIsInDesiredStateleads me to think ALL console state, not just ManagementState. I would probably expect the world ensure does an UPDATE as well to set the state if it is not already correct, but it looks like the PATCH is in the functions wrapping this call.

Thinking about this.

Copy link
Member Author

Choose a reason for hiding this comment

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

yeah, probably the wording is not the best.
What about isConsoleInDesiredState || checkConsoleForDesiredState ?

Copy link
Contributor

Choose a reason for hiding this comment

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

or isManagementStateManaged(), isManagementStateRemoved()?

_, err = client.ConsoleV1alpha1Interface.Consoles(consoleapi.OpenShiftConsoleOperatorNamespace).Patch(consoleapi.ResourceName, types.MergePatchType, []byte(`{"spec": {"managementState": "Managed"}}`))
if err != nil {
if errors.IsNotFound(err) {
return nil
Copy link
Contributor

Choose a reason for hiding this comment

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

We are ok here if errors.IsNotFound?

Copy link
Member Author

Choose a reason for hiding this comment

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

no we can get rid of that 👍

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah I bet we want it to fail in this case.

@@ -19,6 +23,19 @@ var (
AsyncOperationTimeout = 5 * time.Minute
)

// Logger is an interface to report events from tests. It is implemented by
// testing.T.
type Logger interface {
Copy link
Contributor

Choose a reason for hiding this comment

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

Should Logger interface be in the logs.go file?

Copy link
Contributor

Choose a reason for hiding this comment

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

Chewing on the logger. In the rest of the project, I've been using logrus.

Copy link
Contributor

Choose a reason for hiding this comment

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

Mostly just asking "what do we gain doing it differently here".

@jhadvig
Copy link
Member Author

jhadvig commented Jan 23, 2019

@benjaminapetersen updated the PR based on our conversation. PTAL :)

@jhadvig
Copy link
Member Author

jhadvig commented Jan 23, 2019

/test e2e-aws

@jhadvig
Copy link
Member Author

jhadvig commented Jan 24, 2019

/retest

@jhadvig
Copy link
Member Author

jhadvig commented Jan 24, 2019

/test e2e-aws

@benjaminapetersen
Copy link
Contributor

/retest

@jhadvig
Copy link
Member Author

jhadvig commented Jan 24, 2019

Last e2e-aws failure

template pod "e2e-aws" failed: the pod ci-op-4hcvy3x2/e2e-aws failed after 43m26s (failed containers: setup, test): ContainerFailed one or more containers exited

Container setup exited with code 1, reason Error
---
level=warning msg="Found override for ReleaseImage. Please be warned, this is not advised"
level=info msg="Consuming \"Install Config\" from target directory"
level=info msg="Creating cluster..."
level=info msg="Waiting up to 30m0s for the Kubernetes API..."
level=fatal msg="waiting for Kubernetes API: context deadline exceeded"
---
Container test exited with code 1, reason Error
---
Another process 
---

@jhadvig
Copy link
Member Author

jhadvig commented Jan 24, 2019

/retest

1 similar comment
@jhadvig
Copy link
Member Author

jhadvig commented Jan 25, 2019

/retest

@jhadvig
Copy link
Member Author

jhadvig commented Jan 25, 2019

@benjaminapetersen we are green :)

@benjaminapetersen
Copy link
Contributor

/lgtm

awesome.

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Jan 25, 2019
@openshift-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: benjaminapetersen, jhadvig

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:

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

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 25, 2019
@openshift-merge-robot openshift-merge-robot merged commit 6f9d527 into openshift:master Jan 25, 2019
@benjaminapetersen
Copy link
Contributor

yay 🦄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants