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

NETOBSERV-739: Add prometheus #613

Merged
merged 6 commits into from
May 27, 2024
Merged

NETOBSERV-739: Add prometheus #613

merged 6 commits into from
May 27, 2024

Conversation

jotak
Copy link
Member

@jotak jotak commented Apr 10, 2024

Description

Adds a new config section in CRD to allow reading metrics via prometheus ( / thanos) :

  • Auto mode: (when used in openshift, automatically uses monitoring's thanos)
  prometheus:
    querier:
      enable: true
      mode: Auto
      timeout: 30s
  • Manual mode: to manually configure prometheus endpoint / TLS etc.

This is enabled by default.

Dependencies

Checklist

If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that.

  • Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix (in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes).
  • Does this PR require product documentation?
    • If so, make sure the JIRA epic is labelled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs.
  • Does this PR require a product release notes entry?
    • If so, fill in "Release Note Text" in the JIRA.
  • Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc.
    • If so, make sure it is described in the JIRA ticket.
  • QE requirements (check 1 from the list):
    • Standard QE validation, with pre-merge tests unless stated otherwise.
    • Regression tests only (e.g. refactoring with no user-facing change).
    • No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team).

Copy link

openshift-ci bot commented Apr 10, 2024

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

Copy link

openshift-ci bot commented Apr 10, 2024

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from jotak. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found 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

@jotak jotak changed the title wip NETOBSERV-739: WIP Add prometheus Apr 10, 2024
@openshift-ci-robot
Copy link
Collaborator

openshift-ci-robot commented Apr 10, 2024

@jotak: This pull request references NETOBSERV-739 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 story to target the "4.16.0" version, but no target version was set.

In response to this:

Description

Dependencies

n/a

Checklist

If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that.

  • Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix (in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes).
  • Does this PR require product documentation?
  • If so, make sure the JIRA epic is labelled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs.
  • Does this PR require a product release notes entry?
  • If so, fill in "Release Note Text" in the JIRA.
  • Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc.
  • If so, make sure it is described in the JIRA ticket.
  • QE requirements (check 1 from the list):
  • Standard QE validation, with pre-merge tests unless stated otherwise.
  • Regression tests only (e.g. refactoring with no user-facing change).
  • No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team).

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
Copy link
Collaborator

openshift-ci-robot commented Apr 11, 2024

@jotak: This pull request references NETOBSERV-739 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 story to target the "4.16.0" version, but no target version was set.

In response to this:

Description

Dependencies

Checklist

If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that.

  • Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix (in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes).
  • Does this PR require product documentation?
  • If so, make sure the JIRA epic is labelled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs.
  • Does this PR require a product release notes entry?
  • If so, fill in "Release Note Text" in the JIRA.
  • Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc.
  • If so, make sure it is described in the JIRA ticket.
  • QE requirements (check 1 from the list):
  • Standard QE validation, with pre-merge tests unless stated otherwise.
  • Regression tests only (e.g. refactoring with no user-facing change).
  • No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team).

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.

@jotak jotak added the ok-to-test To set manually when a PR is safe to test. Triggers image build on PR. label Apr 11, 2024
Copy link

New images:

  • quay.io/netobserv/network-observability-operator:dd87eac
  • quay.io/netobserv/network-observability-operator-bundle:v0.0.0-dd87eac
  • quay.io/netobserv/network-observability-operator-catalog:v0.0.0-dd87eac

They will expire after two weeks.

To deploy this build:

# Direct deployment, from operator repo
IMAGE=quay.io/netobserv/network-observability-operator:dd87eac make deploy

# Or using operator-sdk
operator-sdk run bundle quay.io/netobserv/network-observability-operator-bundle:v0.0.0-dd87eac

Or as a Catalog Source:

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: netobserv-dev
  namespace: openshift-marketplace
spec:
  sourceType: grpc
  image: quay.io/netobserv/network-observability-operator-catalog:v0.0.0-dd87eac
  displayName: NetObserv development catalog
  publisher: Me
  updateStrategy:
    registryPoll:
      interval: 1m

@github-actions github-actions bot removed the ok-to-test To set manually when a PR is safe to test. Triggers image build on PR. label Apr 11, 2024
Comment on lines 63 to 66
// `prometheusClient` defines Prometheus client settings, used to fetch metrics from the Console plugin.
PrometheusClient FlowCollectorPrometheusClient `json:"prometheusClient,omitempty"`

Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
// `prometheusClient` defines Prometheus client settings, used to fetch metrics from the Console plugin.
PrometheusClient FlowCollectorPrometheusClient `json:"prometheusClient,omitempty"`
// `prometheus` defines Prometheus client settings, used to fetch metrics from the Console plugin.
Prometheus FlowCollectorPrometheus `json:"prometheus,omitempty"`

For consistency, I feel it would be better to simply have prometheus as same as loki

Copy link
Contributor

Choose a reason for hiding this comment

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

that could contains FLP prometheus settings in future

Copy link
Member Author

Choose a reason for hiding this comment

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

idk, I added "client" precisely to avoid confusion with the metrics producing side.
Like, if we use prometheus, then what would the user expect the setting prometheus.enable to be? Likely that it's going to turn off metrics generation, which is not the case.
Or should we come up with something like:

prometheus:
  querier:
    <insert all settings>

?

Copy link
Contributor

@jpinsonneau jpinsonneau Apr 16, 2024

Choose a reason for hiding this comment

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

That makes sense indeed. And we should also end up allowing users to disable prometheus export from FLP too

Copy link
Member Author

Choose a reason for hiding this comment

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

the current way to do this would be to set an empty includeList of metrics

@jotak jotak added the ok-to-test To set manually when a PR is safe to test. Triggers image build on PR. label Apr 16, 2024
Copy link

New images:

  • quay.io/netobserv/network-observability-operator:a7cd60f
  • quay.io/netobserv/network-observability-operator-bundle:v0.0.0-a7cd60f
  • quay.io/netobserv/network-observability-operator-catalog:v0.0.0-a7cd60f

They will expire after two weeks.

To deploy this build:

# Direct deployment, from operator repo
IMAGE=quay.io/netobserv/network-observability-operator:a7cd60f make deploy

# Or using operator-sdk
operator-sdk run bundle quay.io/netobserv/network-observability-operator-bundle:v0.0.0-a7cd60f

Or as a Catalog Source:

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: netobserv-dev
  namespace: openshift-marketplace
spec:
  sourceType: grpc
  image: quay.io/netobserv/network-observability-operator-catalog:v0.0.0-a7cd60f
  displayName: NetObserv development catalog
  publisher: Me
  updateStrategy:
    registryPoll:
      interval: 1m

@github-actions github-actions bot removed the ok-to-test To set manually when a PR is safe to test. Triggers image build on PR. label Apr 16, 2024
Makefile Outdated Show resolved Hide resolved
@codecov-commenter
Copy link

codecov-commenter commented Apr 25, 2024

Codecov Report

Attention: Patch coverage is 51.19048% with 123 lines in your changes are missing coverage. Please review.

Project coverage is 66.53%. Comparing base (18f3da6) to head (daf0382).
Report is 4 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #613      +/-   ##
==========================================
- Coverage   67.00%   66.53%   -0.47%     
==========================================
  Files          68       70       +2     
  Lines        7804     8095     +291     
==========================================
+ Hits         5229     5386     +157     
- Misses       2197     2315     +118     
- Partials      378      394      +16     
Flag Coverage Δ
unittests 66.53% <51.19%> (-0.47%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Coverage Δ
apis/flowcollector/v1beta1/flowcollector_types.go 100.00% <ø> (ø)
apis/flowcollector/v1beta2/flowcollector_types.go 100.00% <ø> (ø)
controllers/consoleplugin/config/config.go 75.00% <ø> (ø)
...trollers/consoleplugin/consoleplugin_reconciler.go 71.21% <100.00%> (-0.22%) ⬇️
pkg/helper/flowcollector.go 82.21% <100.00%> (+0.17%) ⬆️
pkg/metrics/predefined_metrics.go 100.00% <100.00%> (ø)
...pis/flowcollector/v1beta2/zz_generated.deepcopy.go 43.76% <41.66%> (-0.12%) ⬇️
controllers/consoleplugin/consoleplugin_objects.go 87.22% <72.63%> (-4.40%) ⬇️
...pis/flowcollector/v1beta1/zz_generated.deepcopy.go 0.00% <0.00%> (ø)
...s/flowcollector/v1beta1/zz_generated.conversion.go 39.27% <45.94%> (+0.65%) ⬆️

... and 1 file with indirect coverage changes

@jotak jotak changed the title NETOBSERV-739: WIP Add prometheus NETOBSERV-739: Add prometheus May 10, 2024
@jotak jotak marked this pull request as ready for review May 10, 2024 07:16
@jotak jotak added the ok-to-test To set manually when a PR is safe to test. Triggers image build on PR. label May 10, 2024
@openshift-ci-robot
Copy link
Collaborator

openshift-ci-robot commented May 10, 2024

@jotak: This pull request references NETOBSERV-739 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 story to target the "4.16.0" version, but no target version was set.

In response to this:

Description

Dependencies

Checklist

If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that.

  • Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix (in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes).
  • Does this PR require product documentation?
  • If so, make sure the JIRA epic is labelled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs.
  • Does this PR require a product release notes entry?
  • If so, fill in "Release Note Text" in the JIRA.
  • Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc.
  • If so, make sure it is described in the JIRA ticket.
  • QE requirements (check 1 from the list):
  • Standard QE validation, with pre-merge tests unless stated otherwise.
  • Regression tests only (e.g. refactoring with no user-facing change).
  • No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team).

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
Copy link
Collaborator

openshift-ci-robot commented May 10, 2024

@jotak: This pull request references NETOBSERV-739 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 story to target the "4.16.0" version, but no target version was set.

In response to this:

Description

Adds a new config section in CRD to allow reading metrics via prometheus ( / thanos) :

  • Auto mode: (when used in openshift, automatically uses monitoring's thanos)
 prometheus:
   querier:
     enable: true
     mode: Auto
     timeout: 30s
  • Manual mode: to manually configure prometheus endpoint / TLS etc.

Dependencies

Checklist

If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that.

  • Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix (in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes).
  • Does this PR require product documentation?
  • If so, make sure the JIRA epic is labelled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs.
  • Does this PR require a product release notes entry?
  • If so, fill in "Release Note Text" in the JIRA.
  • Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc.
  • If so, make sure it is described in the JIRA ticket.
  • QE requirements (check 1 from the list):
  • Standard QE validation, with pre-merge tests unless stated otherwise.
  • Regression tests only (e.g. refactoring with no user-facing change).
  • No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team).

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.

Copy link

New images:

  • quay.io/netobserv/network-observability-operator:3e9c83b
  • quay.io/netobserv/network-observability-operator-bundle:v0.0.0-3e9c83b
  • quay.io/netobserv/network-observability-operator-catalog:v0.0.0-3e9c83b

They will expire after two weeks.

To deploy this build:

# Direct deployment, from operator repo
IMAGE=quay.io/netobserv/network-observability-operator:3e9c83b make deploy

# Or using operator-sdk
operator-sdk run bundle quay.io/netobserv/network-observability-operator-bundle:v0.0.0-3e9c83b

Or as a Catalog Source:

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: netobserv-dev
  namespace: openshift-marketplace
spec:
  sourceType: grpc
  image: quay.io/netobserv/network-observability-operator-catalog:v0.0.0-3e9c83b
  displayName: NetObserv development catalog
  publisher: Me
  updateStrategy:
    registryPoll:
      interval: 1m

@jotak
Copy link
Member Author

jotak commented May 21, 2024

@memodi FYI: last build adds fix for NETOBSERV-1654 and also a small perf improvement, using exact match with the default quick filters instead of partial matching

default: true
- name: Services network
filter:
dst_kind: 'Service'
dst_kind: '"Service"'
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.

cc'd @memodi

Copy link
Member Author

Choose a reason for hiding this comment

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

it's a perf improvement for queries, have quotes means doing an exact match instead of a partial match, which is more performant

@msherif1234
Copy link
Contributor

another than the API question above
/LGTM

@memodi
Copy link
Contributor

memodi commented May 21, 2024

@memodi FYI: last build adds fix for NETOBSERV-1654 and also a small perf improvement, using exact match with the default quick filters instead of partial matching

this would need update to our tests that verifies "filters"

@jotak
Copy link
Member Author

jotak commented May 22, 2024

this would need update to our tests that verifies "filters"

If you feel this shouldn't be in this PR I can remove it, but it seems to me it's a quick & easy way to improve query perf

@memodi
Copy link
Contributor

memodi commented May 22, 2024

this would need update to our tests that verifies "filters"

If you feel this shouldn't be in this PR I can remove it, but it seems to me it's a quick & easy way to improve query perf

no worries, it's okay to have it in this PR, I just wanted to make a note of it.

@memodi
Copy link
Contributor

memodi commented May 22, 2024

@jotak the other thing I am noticing is below when flowcollector is created newly, plugin goes from Running --> Terminating --> Running state and I see below events for plugin before it stabilizes, not sure why it's scale down and back up:

netobserv-plugin-7d76c88489-89cf5   1/1     Running             0          5s
netobserv-plugin-bf7d457d8-rgv2z    1/1     Terminating         0          7s
netobserv-plugin-bf7d457d8-rgv2z    0/1     Terminating         0          7s
netobserv-plugin-bf7d457d8-rgv2z    0/1     Terminating         0          8s
netobserv-plugin-bf7d457d8-rgv2z    0/1     Terminating         0          8s
netobserv-plugin-bf7d457d8-rgv2z    0/1     Terminating         0          8s

$ oc get events
7m36s       Normal    Scheduled                pod/netobserv-plugin-7d76c88489-89cf5    Successfully assigned netobserv/netobserv-plugin-7d76c88489-89cf5 to memodi-05221042-qqhgt-worker-c-9zrdj
7m36s       Normal    AddedInterface           pod/netobserv-plugin-7d76c88489-89cf5    Add eth0 [10.130.2.30/23] from ovn-kubernetes
7m36s       Normal    Pulling                  pod/netobserv-plugin-7d76c88489-89cf5    Pulling image "quay.io/netobserv/network-observability-console-plugin:1b91ab5"
7m33s       Normal    Pulled                   pod/netobserv-plugin-7d76c88489-89cf5    Successfully pulled image "quay.io/netobserv/network-observability-console-plugin:1b91ab5" in 2.292s (2.293s including waiting)
7m33s       Normal    Created                  pod/netobserv-plugin-7d76c88489-89cf5    Created container netobserv-plugin
7m33s       Normal    Started                  pod/netobserv-plugin-7d76c88489-89cf5    Started container netobserv-plugin
7m36s       Normal    SuccessfulCreate         replicaset/netobserv-plugin-7d76c88489   Created pod: netobserv-plugin-7d76c88489-89cf5
7m38s       Normal    Scheduled                pod/netobserv-plugin-bf7d457d8-rgv2z     Successfully assigned netobserv/netobserv-plugin-bf7d457d8-rgv2z to memodi-05221042-qqhgt-worker-c-9zrdj
7m38s       Warning   FailedMount              pod/netobserv-plugin-bf7d457d8-rgv2z     MountVolume.SetUp failed for volume "console-serving-cert" : secret "console-serving-cert" not found
7m37s       Normal    AddedInterface           pod/netobserv-plugin-bf7d457d8-rgv2z     Add eth0 [10.130.2.28/23] from ovn-kubernetes
7m37s       Normal    Pulling                  pod/netobserv-plugin-bf7d457d8-rgv2z     Pulling image "quay.io/netobserv/network-observability-console-plugin:1b91ab5"
7m33s       Normal    Pulled                   pod/netobserv-plugin-bf7d457d8-rgv2z     Successfully pulled image "quay.io/netobserv/network-observability-console-plugin:1b91ab5" in 3.411s (3.411s including waiting)
7m33s       Normal    Created                  pod/netobserv-plugin-bf7d457d8-rgv2z     Created container netobserv-plugin
7m33s       Normal    Started                  pod/netobserv-plugin-bf7d457d8-rgv2z     Started container netobserv-plugin
7m31s       Normal    Killing                  pod/netobserv-plugin-bf7d457d8-rgv2z     Stopping container netobserv-plugin
7m38s       Normal    SuccessfulCreate         replicaset/netobserv-plugin-bf7d457d8    Created pod: netobserv-plugin-bf7d457d8-rgv2z
7m33s       Normal    SuccessfulDelete         replicaset/netobserv-plugin-bf7d457d8    Deleted pod: netobserv-plugin-bf7d457d8-rgv2z
7m38s       Normal    ScalingReplicaSet        deployment/netobserv-plugin              Scaled up replica set netobserv-plugin-bf7d457d8 to 1
7m36s       Normal    ScalingReplicaSet        deployment/netobserv-plugin              Scaled up replica set netobserv-plugin-7d76c88489 to 1
7m33s       Normal    ScalingReplicaSet        deployment/netobserv-plugin              Scaled down replica set netobserv-plugin-bf7d457d8 to 0 from 1

confirming this doesn't happen on a latest bundle, but only when Operator bundle is v0.0.0-3e9c83b and Plugin image is 1b91ab5

@jotak
Copy link
Member Author

jotak commented May 23, 2024

@memodi I don't reproduce this either :-(
Can you share the operator logs when that happens? And the FlowCollector config?
And if possible get the plugin's pod YAML before and after restart

@memodi
Copy link
Contributor

memodi commented May 23, 2024

@memodi I don't reproduce this either :-( Can you share the operator logs when that happens? And the FlowCollector config? And if possible get the plugin's pod YAML before and after restart

@jotak here's the must-gather tar file: https://drive.google.com/file/d/1O6eduOKzr8SqoxZyylJ1HKxsG8u9eZm9/view?usp=drive_link

jotak added 6 commits May 23, 2024 18:11
- FlowCollector CRD: new config for prometheus client
- Allow disabling Loki and still use the console plugin (with
  prometheus)
- Add some labels in metrics to maximize coverage of plugin queries to
  prom: K8S_FlowLayer, Src|DstK8S_Type on workload metrics

Fix configuring metrics with openshift

Use explicit metrics config, use enable bool for prom

fix tests

Use nested `prometheus.querier` in API
Copy link

openshift-ci bot commented May 23, 2024

New changes are detected. LGTM label has been removed.

@github-actions github-actions bot removed the ok-to-test To set manually when a PR is safe to test. Triggers image build on PR. label May 23, 2024
@jotak
Copy link
Member Author

jotak commented May 23, 2024

Ok @memodi I think I've fixed it, that's a weird thing I never noticed before, but it seems like when you apply a custom resource without setting fields explicitly, relying on their default value, there's a small time where the CR is actually stored without the fields set, and quickly after it's automatically updated with the default fields. Here, I found that your custom resource did not have any config for prom, so it was first seeing prometheus.querier.mode="" then quickly after it's amended to prometheus.querier.mode="Auto" which is the default.
The reason why I was not able to reproduce was because I didn't rely on defaults in my CR, I had this mode explcitly defined. When I remove the prom config then I can reproduce.

So my fix just considers empty mode is equivalent to "Auto" mode

@jotak jotak added the ok-to-test To set manually when a PR is safe to test. Triggers image build on PR. label May 23, 2024
Copy link

New images:

  • quay.io/netobserv/network-observability-operator:1c6ec02
  • quay.io/netobserv/network-observability-operator-bundle:v0.0.0-1c6ec02
  • quay.io/netobserv/network-observability-operator-catalog:v0.0.0-1c6ec02

They will expire after two weeks.

To deploy this build:

# Direct deployment, from operator repo
IMAGE=quay.io/netobserv/network-observability-operator:1c6ec02 make deploy

# Or using operator-sdk
operator-sdk run bundle quay.io/netobserv/network-observability-operator-bundle:v0.0.0-1c6ec02

Or as a Catalog Source:

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: netobserv-dev
  namespace: openshift-marketplace
spec:
  sourceType: grpc
  image: quay.io/netobserv/network-observability-operator-catalog:v0.0.0-1c6ec02
  displayName: NetObserv development catalog
  publisher: Me
  updateStrategy:
    registryPoll:
      interval: 1m

@memodi
Copy link
Contributor

memodi commented May 23, 2024

thanks @jotak , yes, we usually work with defaults in our tests as much as possible and turn on/off only if we need to for our testing. Last commit fixed the bug.

/label qe-approved

@openshift-ci openshift-ci bot added the qe-approved QE has approved this pull request label May 23, 2024
@openshift-ci-robot
Copy link
Collaborator

openshift-ci-robot commented May 23, 2024

@jotak: This pull request references NETOBSERV-739 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 story to target the "4.17.0" version, but no target version was set.

In response to this:

Description

Adds a new config section in CRD to allow reading metrics via prometheus ( / thanos) :

  • Auto mode: (when used in openshift, automatically uses monitoring's thanos)
 prometheus:
   querier:
     enable: true
     mode: Auto
     timeout: 30s
  • Manual mode: to manually configure prometheus endpoint / TLS etc.

This is enabled by default.

Dependencies

Checklist

If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that.

  • Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix (in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes).
  • Does this PR require product documentation?
  • If so, make sure the JIRA epic is labelled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs.
  • Does this PR require a product release notes entry?
  • If so, fill in "Release Note Text" in the JIRA.
  • Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc.
  • If so, make sure it is described in the JIRA ticket.
  • QE requirements (check 1 from the list):
  • Standard QE validation, with pre-merge tests unless stated otherwise.
  • Regression tests only (e.g. refactoring with no user-facing change).
  • No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team).

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.

@jotak
Copy link
Member Author

jotak commented May 23, 2024

unit tests are failing weirdly on CI, they work fine locally - I'll see on Monday if that's all clean before merging

@jotak jotak merged commit f278746 into netobserv:main May 27, 2024
11 of 12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
jira/valid-reference ok-to-test To set manually when a PR is safe to test. Triggers image build on PR. qe-approved QE has approved this pull request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants