Bug 1977454: Use nodejs to test service connection by adambkaplan · Pull Request #26285 · openshift/origin

adambkaplan · 2021-06-29T19:27:17Z

Redis has tighter constraints on client HTTP calls to prevent malicious
attacks. Only official redis clients are guaranteed to receive reliable
HTTP responses. The build test for in-cluster service connections does
not use a redis client, resulting in a test HTTP curl request receiving an
empty repsonse.

This updates the in-cluster service test to use a "hello world" nodejs
application and service. The use of the upstream Redis image is also
removed.

openshift-ci · 2021-06-29T19:27:23Z

@adambkaplan: This pull request references Bugzilla bug 1977454, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker.

3 validation(s) were run on this bug

bug is open, matching expected state (open)
bug target release (4.9.0) matches configured target release for branch (4.9.0)
bug is in the state NEW, which is one of the valid states (NEW, ASSIGNED, ON_DEV, POST, POST)

Requesting review from QA contact:
/cc @xiuwang

Details

In response to this:

Bug 1977454: Use nodejs to test service connection

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

adambkaplan · 2021-06-29T19:27:31Z

/test e2e-aws-proxy

test/extended/builds/service.go

Redis has tighter constraints on client HTTP calls to prevent malicious attacks. Only official redis clients are guaranteed to receive reliable HTTP responses. The build test for in-cluster service connections does not use a redis client, resulting in a test HTTP curl request receiving an empty repsonse. This updates the in-cluster service test to use a "hello world" nodejs application and service. The use of the upstream Redis image is also removed.

adambkaplan · 2021-06-29T19:36:35Z

/cherrypick release-4.8

openshift-cherrypick-robot · 2021-06-29T19:36:36Z

@adambkaplan: once the present PR merges, I will cherry-pick it on top of release-4.8 in a new PR and assign it to you.

Details

In response to this:

/cherrypick release-4.8

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

adambkaplan · 2021-06-29T19:36:53Z

/test e2e-aws-proxy

gabemontero · 2021-06-29T19:39:13Z

test/extended/builds/service.go

-				g.By("standing up a new hello world service")
-				err := oc.Run("new-app").Args("--name", "hello-openshift", k8simage.GetE2EImage(k8simage.Redis)).Execute()
+				g.By("standing up a new hello world nodejs service via oc new-app")
+				err := oc.Run("new-app").Args("nodejs~https://github.com/sclorg/nodejs-ex.git", "--name", "hello-nodejs").Execute()


I've occasionally been curious on the side how the upcoming disconnected tests are going to deal with git cloning from the outside :-)

Can this be "we build the image on the outside with the Git bits already installed, and then mirror the built image into the restricted-network environment before running the tests"? That would make cloning-from-Git or other on-the-fly internet access technical debt that we'd have to clean out before we had the test-case green in restricted-networks where that internet access is not available.

can - yes
do it in relatively minimal cycles like this change - no .... a much much much more involved change based on other recent build test image work we have had to wrt the disconnected e2e stuff

short term, e2e-aws-proxy needs to be unblocked

but as I mentioned to @adambkaplan in slack, our team needs to huddle up at some point and see how we will deal with the git cloning elements of our e2e's (which aside from testing git clone, test several of the upstream s2i base image implementations as part of vetting those)

That's going to be a much bigger endeavor. "Clone source from git over the internet" is the most basic thing OCP builds do, and we do it everywhere in the build suite.

Is having a fully air-gapped CI test a goal? Or is the goal having CI tests run on a cluster that is restricted, but with some caveats. Example - proxy in a DMZ that has an allowlist of domains to access.

gabemontero · 2021-06-29T19:39:27Z

/lgtm

openshift-ci · 2021-06-29T19:39:42Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: adambkaplan, gabemontero

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

~~test/extended/builds/OWNERS~~ [adambkaplan,gabemontero]
~~test/extended/util/image/OWNERS~~ [adambkaplan]

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

openshift-bot · 2021-06-29T21:47:35Z

/retest