LOG-5030: functional tests for testing log forwarding to Azure Monitor Log #2334

vparfonov · 2024-02-02T15:11:48Z

Signed-off-by: Vitalii Parfonov vparfono@redhat.com

Description

This pull request addresses adding functional tests for testing log forwarding to Azure Monitor Log.

Changes:

Implemented functional tests using Mockoon, a mocking API tool for describing environments via JSON files.
Mockoon has capabilities to define rules for checking HTTP requests and sending responses accordingly.
Proposed rules to validate the log-type header and body fields in each record (message and log_type) to ensure that log records are properly formatted, e.g.:

"rules": [
            {
              "target": "header",
              "modifier": "log-type",
              "value": "myLogType",
              "invert": false,
              "operator": "equals"
            },
            {
              "target": "body",
              "modifier": "$.[0].message",
              "value": "This is my test message",
              "invert": false,
              "operator": "equals"
            },
            {
              "target": "body",
              "modifier": "$.[0].log_type",
              "value": "application",
              "invert": false,
              "operator": "equals"
            }
          ],

Set up a mocking environment within a Pod and made it available via a Route to emulate the original API URI format
Emulate the original API URI format (https://<CustomerId>.<Host>/api/logs?api-version=2016-04-01), including the <CustomerID> and <Host> components, to accurately replicate the production environment

/cc
/assign

/cherry-pick

Links

Depending on PR(s): LOG-4606:Forwarding logs to the Azure Monitor Logs #2213
Bugzilla:
Github issue:
JIRA: https://issues.redhat.com/browse/LOG-5030
Enhancement proposal:

openshift-ci-robot · 2024-02-02T15:11:51Z

@vparfonov: This pull request references LOG-4606 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the spike to target either version "4.8." or "openshift-4.8.", but it targets "Logging 5.9.0" instead.

In response to this:

Signed-off-by: Vitalii Parfonov vparfono@redhat.com

Description

This pull request addresses adding functional tests for testing log forwarding to Azure Monitor Log.

Changes:

Implemented functional tests using Mockoon, a tool for describing environments via JSON files.

Mockoon has capabilities to define rules for checking HTTP requests and sending responses accordingly.

Proposed rules to validate the log-type header and body fields in each record (message and log_type) to ensure that log records are properly formatted, e.g.:
"rules": [
           {
             "target": "header",
             "modifier": "log-type",
             "value": "myLogType",
             "invert": false,
             "operator": "equals"
           },
           {
             "target": "body",
             "modifier": "$.[0].message",
             "value": "This is my test message",
             "invert": false,
             "operator": "equals"
           },
           {
             "target": "body",
             "modifier": "$.[0].log_type",
             "value": "application",
             "invert": false,
             "operator": "equals"
           }
         ],
Set up a mocking environment within a Pod and made it available via a Route to emulate the original API URI format

Emulate the original API URI format (https://<CustomerId>.<Host>/api/logs?api-version=2016-04-01), including the <CustomerID> and <Host> components, to accurately replicate the production environment

/cc
/assign

/cherry-pick

Links

Depending on PR(s): LOG-4606:Forwarding logs to the Azure Monitor Logs #2213

Bugzilla:

Github issue:

JIRA: https://issues.redhat.com/browse/LOG-5030

Enhancement proposal:

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 openshift-eng/jira-lifecycle-plugin repository.

openshift-ci · 2024-02-02T15:11:54Z

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

vparfonov · 2024-02-02T15:12:20Z

/assign @jcantrill

openshift-ci-robot · 2024-02-02T16:02:09Z

@vparfonov: This pull request references LOG-4606 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the spike to target either version "4.8." or "openshift-4.8.", but it targets "Logging 5.9.0" instead.

In response to this:

Signed-off-by: Vitalii Parfonov vparfono@redhat.com

Description

This pull request addresses adding functional tests for testing log forwarding to Azure Monitor Log.

Changes:

Implemented functional tests using Mockoon, a mocking API tool for describing environments via JSON files.

Mockoon has capabilities to define rules for checking HTTP requests and sending responses accordingly.

Proposed rules to validate the log-type header and body fields in each record (message and log_type) to ensure that log records are properly formatted, e.g.:
"rules": [
           {
             "target": "header",
             "modifier": "log-type",
             "value": "myLogType",
             "invert": false,
             "operator": "equals"
           },
           {
             "target": "body",
             "modifier": "$.[0].message",
             "value": "This is my test message",
             "invert": false,
             "operator": "equals"
           },
           {
             "target": "body",
             "modifier": "$.[0].log_type",
             "value": "application",
             "invert": false,
             "operator": "equals"
           }
         ],
Set up a mocking environment within a Pod and made it available via a Route to emulate the original API URI format

Emulate the original API URI format (https://<CustomerId>.<Host>/api/logs?api-version=2016-04-01), including the <CustomerID> and <Host> components, to accurately replicate the production environment

/cc
/assign

/cherry-pick

Links

Depending on PR(s): LOG-4606:Forwarding logs to the Azure Monitor Logs #2213

Bugzilla:

Github issue:

JIRA: https://issues.redhat.com/browse/LOG-5030

Enhancement proposal:

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 openshift-eng/jira-lifecycle-plugin repository.

openshift-ci-robot · 2024-02-08T12:32:56Z

@vparfonov: This pull request references LOG-5030 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.8.0" version, but no target version was set.

In response to this:

Signed-off-by: Vitalii Parfonov vparfono@redhat.com

Description

This pull request addresses adding functional tests for testing log forwarding to Azure Monitor Log.

Changes:

Implemented functional tests using Mockoon, a mocking API tool for describing environments via JSON files.

Mockoon has capabilities to define rules for checking HTTP requests and sending responses accordingly.

Proposed rules to validate the log-type header and body fields in each record (message and log_type) to ensure that log records are properly formatted, e.g.:
"rules": [
           {
             "target": "header",
             "modifier": "log-type",
             "value": "myLogType",
             "invert": false,
             "operator": "equals"
           },
           {
             "target": "body",
             "modifier": "$.[0].message",
             "value": "This is my test message",
             "invert": false,
             "operator": "equals"
           },
           {
             "target": "body",
             "modifier": "$.[0].log_type",
             "value": "application",
             "invert": false,
             "operator": "equals"
           }
         ],
Set up a mocking environment within a Pod and made it available via a Route to emulate the original API URI format

Emulate the original API URI format (https://<CustomerId>.<Host>/api/logs?api-version=2016-04-01), including the <CustomerID> and <Host> components, to accurately replicate the production environment

/cc
/assign

/cherry-pick

Links

Depending on PR(s): LOG-4606:Forwarding logs to the Azure Monitor Logs #2213

Bugzilla:

Github issue:

JIRA: https://issues.redhat.com/browse/LOG-5030

Enhancement proposal:

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 openshift-eng/jira-lifecycle-plugin repository.

vparfonov · 2024-02-08T13:59:11Z

/hold

vparfonov · 2024-02-08T14:48:46Z

/test functional

vparfonov · 2024-02-09T13:02:34Z

/test functional

vparfonov · 2024-02-12T09:57:55Z

/hold cancel

jcantrill · 2024-02-13T16:11:19Z

test/functional/outputs/azuremonitor/forward_to_azuremonitor_test.go

+	BeforeEach(func() {
+		framework = functional.NewCollectorFunctionalFrameworkUsingCollector(logging.LogCollectionTypeVector)
+		// Start mockServer server
+		mockServer = azuremonitor.NewMockServer(framework.Namespace, azuremonitor.Mockoon)


Why can this test not rely upon the output container being added to the pod of the functional test? It is just a container and there are benefits to all the containers running in the same pod. If we really can not us the functional framework we should move this test to rely upon the e2e framework but I suspect its possible with the functional one

The problem is: i need to know public URL of Route, before deploy collector, that's why i did it in this way.
See my comment here: forward_to_azuremonitor_test.go#L43.
I will try to find way how do it in one pod

@jcantrill

We do we need a public URL? I thought there was a place to set the host? Can we not craft the URL from "localhost" and a port?

Another thing we could do is to modify the framework to mount the /etc/host file into the collector container using either an emptydir or maybe a configmap. This would provide a way to resolve a name without needing a route

Maybe we can do something with /etc/host, at the end URL must have format: https://some-id.host/

merged to one pod

test/functional/outputs/azuremonitor/forward_to_azuremonitor_test.go

test/helpers/azuremonitor/azure-http-data-collector-api.json

jcantrill · 2024-02-13T16:17:51Z

test/helpers/azuremonitor/mockServer.go

+var AzureHttpDataCollectorApi string
+
+const (
+	image         = "mockoon/cli:latest"


lets tag a version of this and push it to quay.io/openshift-logging so we can ensure it will not change from under us

vparfonov · 2024-02-16T15:35:54Z

/test functional
/test functional-target

vparfonov · 2024-02-16T19:37:55Z

/test functional
/test functional-target

vparfonov · 2024-02-16T22:55:55Z

/test functional
/test functional-target

vparfonov · 2024-02-19T10:28:19Z

/test e2e-ocp-target-minus-one
/test functional
/test functional-target

jcantrill

This is much closer to what I would expect. Good work

jcantrill · 2024-02-20T16:46:14Z

test/functional/outputs/azuremonitor/forward_to_azuremonitor_test.go

+		Expect(strings.Count(collectorLog, failedReason)).To(BeEquivalentTo(0))
+
+		//read log from mock server container and validate it
+		mockoonLogs := readLogFromMockoon(framework)


My statement of "filter" was more in the direction of we control what we return from the "read" function. Within that function we can return only the bits that are of interest to us. The following lines already do some of this logic by separating receiver logs from the logs we are interested.

vparfonov · 2024-02-21T15:31:00Z

/test lint

vparfonov · 2024-02-21T15:51:02Z

/retest all

openshift-ci · 2024-02-21T15:52:30Z

@vparfonov: The /retest command does not accept any targets.
The following commands are available to trigger required jobs:

/test ci-index-cluster-logging-operator-bundle
/test e2e-target
/test functional-target
/test images
/test lint
/test unit

The following commands are available to trigger optional jobs:

/test e2e-ocp-target-minus-one
/test e2e-ocp-target-minus-two
/test functional

Use /test all to run all jobs.

In response to this:

/retest all

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.

vparfonov · 2024-02-21T17:16:52Z

/retest

… Monitor Log Signed-off-by: Vitalii Parfonov <vparfono@redhat.com>

jcantrill · 2024-02-21T17:59:43Z

/approve
/lgtm

openshift-ci · 2024-02-21T18:00:10Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jcantrill, vparfonov

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~~ [jcantrill]

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

vparfonov · 2024-02-21T20:25:54Z

/test functional

openshift-ci-robot · 2024-02-21T20:54:27Z

/retest-required

Remaining retests: 0 against base HEAD e03cbb8 and 2 for PR HEAD df05fff in total

openshift-ci · 2024-02-21T22:09:58Z

@vparfonov: all tests passed!

Full PR test history. Your PR dashboard.

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. I understand the commands that are listed here.

openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Feb 2, 2024

openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Feb 2, 2024

openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Feb 2, 2024

openshift-ci bot assigned jcantrill Feb 2, 2024

vparfonov changed the title ~~LOG-4606: Forwarding logs to the Azure Monitor Logs~~ LOG-4606: functional tests for testing log forwarding to Azure Monitor Log Feb 2, 2024

jcantrill added the release/5.9 label Feb 6, 2024

openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Feb 8, 2024

vparfonov force-pushed the log5030 branch 5 times, most recently from ee5a3a3 to 70f5f42 Compare February 8, 2024 12:32

vparfonov marked this pull request as ready for review February 8, 2024 12:32

openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Feb 8, 2024

vparfonov changed the title ~~LOG-4606: functional tests for testing log forwarding to Azure Monitor Log~~ LOG-5030: functional tests for testing log forwarding to Azure Monitor Log Feb 8, 2024

openshift-ci bot requested review from cahartma and Clee2691 February 8, 2024 12:33

vparfonov force-pushed the log5030 branch from 70f5f42 to ca8bfbe Compare February 8, 2024 12:59

openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 8, 2024

openshift-ci bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 12, 2024

jcantrill reviewed Feb 13, 2024

View reviewed changes

openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Feb 16, 2024

vparfonov force-pushed the log5030 branch from 477ce05 to 433ab66 Compare February 16, 2024 15:35

vparfonov force-pushed the log5030 branch from 433ab66 to c6721ed Compare February 16, 2024 17:20

vparfonov marked this pull request as ready for review February 16, 2024 17:20

openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Feb 16, 2024

vparfonov requested a review from jcantrill February 16, 2024 17:23

openshift-ci bot requested a review from alanconway February 16, 2024 17:24

jcantrill reviewed Feb 20, 2024

View reviewed changes

vparfonov force-pushed the log5030 branch from c6721ed to cc37ee5 Compare February 21, 2024 15:00

vparfonov requested a review from jcantrill February 21, 2024 15:01

vparfonov force-pushed the log5030 branch from cc37ee5 to 753721d Compare February 21, 2024 17:30

LOG-5030: adding functional tests for testing log forwarding to Azure…

df05fff

… Monitor Log Signed-off-by: Vitalii Parfonov <vparfono@redhat.com>

vparfonov force-pushed the log5030 branch from 753721d to df05fff Compare February 21, 2024 17:32

openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Feb 21, 2024

openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 21, 2024

openshift-merge-bot bot merged commit 56a5a91 into openshift:master Feb 21, 2024
10 checks passed

vparfonov deleted the log5030 branch February 21, 2024 23:45

LOG-5030: functional tests for testing log forwarding to Azure Monitor Log #2334

LOG-5030: functional tests for testing log forwarding to Azure Monitor Log #2334

Conversation

vparfonov commented Feb 2, 2024 • edited

Description

Links

openshift-ci-robot commented Feb 2, 2024 • edited by openshift-ci bot

Description

Links

openshift-ci bot commented Feb 2, 2024

vparfonov commented Feb 2, 2024

openshift-ci-robot commented Feb 2, 2024 • edited by openshift-ci bot

Description

Links

openshift-ci-robot commented Feb 8, 2024 • edited by openshift-ci bot

Description

Links

vparfonov commented Feb 8, 2024

vparfonov commented Feb 8, 2024

vparfonov commented Feb 9, 2024

vparfonov commented Feb 12, 2024

jcantrill Feb 13, 2024

Choose a reason for hiding this comment

vparfonov Feb 13, 2024

Choose a reason for hiding this comment

jcantrill Feb 13, 2024

Choose a reason for hiding this comment

jcantrill Feb 13, 2024 • edited

Choose a reason for hiding this comment

vparfonov Feb 14, 2024 • edited

Choose a reason for hiding this comment

vparfonov Feb 15, 2024

Choose a reason for hiding this comment

jcantrill Feb 13, 2024

Choose a reason for hiding this comment

vparfonov Feb 15, 2024

Choose a reason for hiding this comment

vparfonov commented Feb 16, 2024

vparfonov commented Feb 16, 2024

vparfonov commented Feb 16, 2024

vparfonov commented Feb 19, 2024

jcantrill left a comment

Choose a reason for hiding this comment

jcantrill Feb 20, 2024

Choose a reason for hiding this comment

vparfonov commented Feb 21, 2024

vparfonov commented Feb 21, 2024

openshift-ci bot commented Feb 21, 2024

vparfonov commented Feb 21, 2024

jcantrill commented Feb 21, 2024

openshift-ci bot commented Feb 21, 2024

vparfonov commented Feb 21, 2024

openshift-ci-robot commented Feb 21, 2024

openshift-ci bot commented Feb 21, 2024

vparfonov commented Feb 2, 2024 •

edited

openshift-ci-robot commented Feb 2, 2024 •

edited by openshift-ci bot

openshift-ci-robot commented Feb 2, 2024 •

edited by openshift-ci bot

openshift-ci-robot commented Feb 8, 2024 •

edited by openshift-ci bot

jcantrill Feb 13, 2024 •

edited

vparfonov Feb 14, 2024 •

edited