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

adding custom logging test + local runtimes-common integration test #134

Merged
merged 11 commits into from
Sep 7, 2017

Conversation

balopat
Copy link
Contributor

@balopat balopat commented Aug 17, 2017

TODO left:

@balopat balopat requested review from aslo and meltsufin August 17, 2017 15:10
docker build -t $APP_IMAGE . || gcloud docker -- build -t $APP_IMAGE . || usage "Error building test-app image from base image \"${imageUnderTest}\", please make sure it exists!"


if [[ "$WITH_GCP" ]]; then
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think it makes sense to me to add these integration tests to the local_integration_test.sh script. I think we originally added this script in order to test things that were outside the scope of the runtimes_common integraion testing framework (namely, container shutdown hooks).

I think if we wanted to make it easier to run the runtimes_common tests, a better way to do it would be to just simulate a cloudbuild execution locally, using the container-builder-local emulator that was just released as part of the Cloud SDK (see release notes).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

oooo, I'll test out this container-build-local, thanks for the suggestion!
I created a separate script first btw, but then I figured that they were so similar that I integrated it back into the local_integration_test.sh. It's really handy to have as part of the workflow. But if container-build-local can do the magic, I'll have a look at that as that could remove the duplication around the arguments of the runtimes-common driver for example (one place here, the other place is the yaml file).

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 will do this in #126 though, and then separate it out from this pull request.

import static org.mockito.Mockito.mock;

@Configuration
@Profile("mock-gcp")
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 skeptical about having these separate profiles for gcp and mock-gcp. Is it possible to write a single test app implementation, and have the environment in which the test app runs handle the responsibility of passing in google credentials?

Copy link
Contributor Author

@balopat balopat Aug 17, 2017

Choose a reason for hiding this comment

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

One of the reasons I introduced this was that without mock-gcp - the local_integration_test.sh (and I mean the shutdown log testing too, not just the local runtime-commons test) would need to pass in the GCP creds, otherwise the app doesn't start up. Is it okay to expect a valid GCP setup for the user in the local_integration_test.sh?

Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe the local_integration_test.sh script could check for the presence of the GOOGLE_CREDENTIALS environment variable, and either fail or warn the user if it looks like the environment wasn't properly set up. What do you think about that?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's doable, the only thing I have against that is that this decision will force someone to setup a service account even when they start their development...which might not be a too strong issue but we'll have to document it then.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@meltsufin what do you think?

Copy link
Member

Choose a reason for hiding this comment

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

Can we just not invoke this logging test when running locally? Another option would be to have a separate test-app that doesn't depend on GCP for local testing. Otherwise, I don't really mind the mock-gcp profile.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The problem is that I am using Spring to inject the services, so when the beans get created, they need the credentials and thus the application fails to start without the creds - that's why I went down the road to create the two profiles. I just had an idea that I'll check out: I should try to make the components @Lazy.
Re: skipping the GCP related tests locally: if we combine @aslo's idea of separating the runtimes-common tests out into a separate script, then this will naturally skip calling them in the local integration tests.
So, if I can make @Lazy work, we have a "single test app implementation" (without need for profiles), the app starts up and we'll have the runtimes-common tests separated, which might need the GCP creds.

import com.google.cloud.logging.Logging;
import com.google.cloud.logging.Payload;
import com.google.cloud.logging.Severity;
import com.google.cloud.runtimes.stackdriver.StackDriverMonitoringService;
Copy link
Member

Choose a reason for hiding this comment

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

Unused import

import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
import sun.util.logging.resources.logging;
Copy link
Member

Choose a reason for hiding this comment

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

Unusued import

}

@RequestMapping(path = "/logging_custom", method = POST)
public String handleMonitoringRequest(@RequestBody LoggingTestRequest loggingTestRequest) throws IOException, InterruptedException {
Copy link
Member

Choose a reason for hiding this comment

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

handleLoggingRequest?

.setResource(MonitoredResource.newBuilder("global").build())
.build();
entries.add(entry);
logging.write(entries);
Copy link
Member

Choose a reason for hiding this comment

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

Instead of using the Logging client lib directly, we should be able to use the JUL appender. Can you also look at #72 that has been put on the back-burner, and reconcile it with what you're doing in this PR? Ideally, we would like to close out #72 as well, but I think there are some unresolved complications there with setting up JUL.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think that the Custom Logging Test should use the client library and make an explicit call to Stackdriver Logging (by creating only one LogEntry), whereas the Standard Logging Test should redirect the output of JUL to Stackdriver.

Copy link
Contributor Author

@balopat balopat Aug 22, 2017

Choose a reason for hiding this comment

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

I agree with @cassand - I was planning to use JUL for standard logging tests and Logging library directly for custom, just so that we have both covered.
However, we are free to decide what we want to do, as we can setup custom logging with JUL too.

If you're okay with that, I will review #72 in the context of the Standard Logging test (I just added a new, separate issue for it: #139)

Copy link
Member

Choose a reason for hiding this comment

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

I'm OK with Damien's suggestion.


@Configuration
@Profile("gcp")
public class GCPConfiguration {
Copy link
Member

Choose a reason for hiding this comment

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

GcpConfiguration


@Configuration
@Profile("mock-gcp")
public class MockGCPConfiguration {
Copy link
Member

Choose a reason for hiding this comment

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

MockGcpConfiguration

import static org.mockito.Mockito.mock;

@Configuration
@Profile("mock-gcp")
Copy link
Member

Choose a reason for hiding this comment

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

Can we just not invoke this logging test when running locally? Another option would be to have a separate test-app that doesn't depend on GCP for local testing. Otherwise, I don't really mind the mock-gcp profile.

@balopat
Copy link
Contributor Author

balopat commented Sep 7, 2017

@aslo @meltsufin can you please review again this PR? I addressed all of your concerns:

  • @aslo: removed the separate MockGCP profile and introduced container-builder-local for local testing
  • @meltsufin: cleanup of unused imports and method rename (handleLoggingRequest) is done

Thanks!

Copy link
Member

@meltsufin meltsufin left a comment

Choose a reason for hiding this comment

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

I think there is also a fair amount of code duplication between the two local_*.sh scripts. I wonder if there is a way to factor out that duplication. Perhaps for a different PR though.

</dependency>
<dependency>
<groupId>com.google.api</groupId>
<artifactId>gax-grpc</artifactId>
Copy link
Member

Choose a reason for hiding this comment

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

Is this (and the one above) not a transitive dependency of google-cloud-logging?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

good catch - let me double check & I will clarify in comments.

<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<version>2.8.47</version>
Copy link
Member

Choose a reason for hiding this comment

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

<scope>test</scope>

exit 1
fi

if [[ -z ${GOOGLE_APPLICATION_CREDENTIALS} ]]; then
Copy link
Member

Choose a reason for hiding this comment

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

The readme instructions don't mention GOOGLE_APPLICATION_CREDENTIALS.
Can we just leverage gcloud for the default credentials?


docker rm -f $CONTAINER || echo "Integration-test-app container is not running, ready to start a new instance."

# run app container locally to test shutdown logging
Copy link
Member

Choose a reason for hiding this comment

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

You're not really doing a shutdown logging test here.

@balopat balopat merged commit ad4b0a8 into master Sep 7, 2017
@balopat balopat deleted the feature/5_logging_integration_test branch September 7, 2017 22:28
aslo pushed a commit that referenced this pull request Sep 8, 2017
…me into common-test-application

* 'master' of github.com:GoogleCloudPlatform/openjdk-runtime:
  adding custom logging test + local runtimes-common integration test (#134)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants