Skip to content

Conversation

jpinsonneau
Copy link
Contributor

@jpinsonneau jpinsonneau commented Sep 18, 2025

Description

  • Add text saying it’s a simplified setup, with a link to the full setup page
  • Remove fields
    • Multi-cluster deployment
    • SASL in Kafka config
    • Secondary networks
    • Exporters
  • add disclaimer + text about changing the sampling in calculator
  • remove last stage YAML
  • rename switch labels to True / False to match descriptions and YAML content
image image image image

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).

Copy link

openshift-ci bot commented Sep 18, 2025

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

codecov bot commented Sep 18, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 54.34%. Comparing base (3e1e425) to head (1dd159e).

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #1028   +/-   ##
=======================================
  Coverage   54.34%   54.34%           
=======================================
  Files         203      203           
  Lines       10792    10792           
  Branches     1264     1264           
=======================================
  Hits         5865     5865           
  Misses       4417     4417           
  Partials      510      510           
Flag Coverage Δ
uitests 56.60% <ø> (ø)
unittests 49.27% <ø> (ø)

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

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@jotak jotak self-requested a review September 18, 2025 15:20
@jpinsonneau jpinsonneau changed the title Address feedback on FlowCollector form NETOBSERV-2401 Address feedback on FlowCollector form Sep 19, 2025
@jpinsonneau jpinsonneau changed the title NETOBSERV-2401 Address feedback on FlowCollector form NETOBSERV-2401 Static plugin forms polishing Sep 19, 2025
@jpinsonneau jpinsonneau marked this pull request as ready for review September 19, 2025 10:36
@jotak jotak added the ok-to-test To set manually when a PR is safe to test. Triggers image build on PR. label Sep 19, 2025
Copy link

New image:
quay.io/netobserv/network-observability-console-plugin:1a583ab

It will expire after two weeks.

To deploy this build, run from the operator repo, assuming the operator is running:

USER=netobserv VERSION=1a583ab make set-plugin-image

<span className="co-pre-line">
{t(
// eslint-disable-next-line max-len
'The estimations are based on the number of nodes in the cluster and the sampling rate. They do not take into account the number of namespaces or pods, as their impact is comparatively lower than that of nodes.\nThe estimations are calculated using a linear regression model based on data collected from various OpenShift clusters. Actual resource consumption may vary depending on your specific workload and cluster configuration.\n\nTo change the sampling rate, select a row in the table below.'
Copy link
Member

Choose a reason for hiding this comment

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

I think the reason why I was surprised that clicking on the table changed the sampling, is that it was already configured in a previous step.
To make it more explicit, what about doing this:

  • No change when the page is loaded first, with "current" written next to the current sampling value
  • When the user clicks a row, instead of "current" we would write "previous value" and "new value" next to the corresponding lines

?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Why not removing it from the previous step and make it clear that you need to pick a sampling in the table ?

I'd like to avoid previous / current value as it feel confusing since the resource is not created yet. We should ask the sampling only once and the resources impact is an important factor for the user to decide which sampling to start with.
If the table is not clear enough, we can add text or even have the sampling dropdown above it.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah sounds a good idea, to keep sampling configuration only at the end

Copy link
Member

Choose a reason for hiding this comment

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

done here b7975ad

<br /> <br />
{t(
// eslint-disable-next-line max-len
'This wizard is a helper to create a first FlowCollector resource. It does not cover all the available configuration options, but only the most common ones.\nFor advanced configuration, please use the'
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
'This wizard is a helper to create a first FlowCollector resource. It does not cover all the available configuration options, but only the most common ones.\nFor advanced configuration, please use the'
'This wizard is a helper to create a first FlowCollector resource. It does not cover all the available configuration options, but only the most common ones.\nFor advanced configuration, please use YAML or the'

Copy link
Member

@jotak jotak Sep 22, 2025

Choose a reason for hiding this comment

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

Also can you add something like that, to mention what's in the advanced config:

Advanced configuration includes:

  • Filtering options
  • Configuring custom exporters
  • IP-based custom labels
  • Pod identification for secondary networks
  • Performance fine-tuning
    etc.

You can always edit a FlowCollector later when you start with the simplified configuration.

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 YAML been removed in that view so you need to switch form by clicking on the button first.

  • Sure I'm in favor of listing advanced configs here

Copy link
Member

Choose a reason for hiding this comment

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

On YAML: this is to mention users can still use the non-UI YAML config, I wasn't thinking about the YAML form

<span className="co-pre-line">
{t(
// eslint-disable-next-line max-len
'The example outlined in the table demonstrate a scenario that is tailored to your workload. Consider this example only as a baseline from which adjustments can be made to accommodate your needs.'
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
'The example outlined in the table demonstrate a scenario that is tailored to your workload. Consider this example only as a baseline from which adjustments can be made to accommodate your needs.'
'The example outlined in the table demonstrates a scenario that is tailored to your workload. Consider this example only as a baseline from which adjustments can be made to accommodate your needs.'

@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 Sep 23, 2025
<span className="co-pre-line">
{t(
// eslint-disable-next-line max-len
'Network Observability Operator deploys a monitoring pipeline that consists in:\n - an eBPF agent, that generates network flows from captured packets\n - flowlogs-pipeline, a component that collects, enriches and exports these flows\n - a Console plugin for flows visualization with powerful filtering options, a topology representation and more\n\nFlow data is then available in multiple ways, each optional:\n - As Prometheus metrics\n - As raw flow logs stored in Grafana Loki\n - As raw flow logs exported to a collector\n\nThe FlowCollector resource is used to configure the operator and its managed components.\nThis setup will guide you on the common aspects of the FlowCollector configuration.'
Copy link
Member

Choose a reason for hiding this comment

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

FYI: since I was adding more text here (a description of the advanced config), it appeared that this first dialog was bloated of texts ... So I think we can remove the overall description after all, to make it lighter.
Users coming here probably just went through the operator installation which already has its description, so I think it's ok to remove it .. makes sense ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, the user is coming from operator installation and must have seen the operator description somehow 👍

>
<Button className={`co-pre-line description`} variant="plain" style={{ paddingLeft: 0 }}>
{`${parts[0]}...`}
{formatText(parts[0])} {t('(see more...)')}
Copy link
Member

Choose a reason for hiding this comment

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

@jpinsonneau on the text ellipsis, I think why I was surprised is that in general ellipsis are used in small constrained space as a necessity. Here there's large space and I didn't expect at first to have to click to read more. I don't know if it's just me... But having a more explicit text would have lessened the "surprise".

const getSamplings = React.useCallback(() => {
const current = getCurrentSampling();
let samplings = [1, 25, 50, 100, 125, 150];
let samplings = [1, 25, 50, 100, 500, 1000];
Copy link
Member

Choose a reason for hiding this comment

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

BTW, I forgot to mention this, I've changed the proposed values here to include higher ones, which we regularly see customers are using

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is the formula still working fine with those ?

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 not sure what "work" means, they continue to provide estimations (with very small consumption on my little cluster obviously), now it's hard to tell if that's accurate

Copy link
Member

Choose a reason for hiding this comment

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

On my 6-nodes cluster it's over-estimated but the other sampling rates like 50 is also over-estimated, when I inject some test workload

Copy link
Member

Choose a reason for hiding this comment

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

I think the formula over-estimates the impact of sampling TBH
But we can refine that later, that's still much a TODO

@memodi
Copy link
Member

memodi commented Sep 23, 2025

/ok-to-test

@openshift-ci openshift-ci bot added the ok-to-test To set manually when a PR is safe to test. Triggers image build on PR. label Sep 23, 2025
Copy link

New image:
quay.io/netobserv/network-observability-console-plugin:daf1abe

It will expire after two weeks.

To deploy this build, run from the operator repo, assuming the operator is running:

USER=netobserv VERSION=daf1abe make set-plugin-image

@openshift-ci openshift-ci bot added the lgtm label Sep 25, 2025
@jotak jotak added ok-to-test To set manually when a PR is safe to test. Triggers image build on PR. and removed ok-to-test To set manually when a PR is safe to test. Triggers image build on PR. labels Sep 25, 2025
Copy link

New image:
quay.io/netobserv/network-observability-console-plugin:da852fc

It will expire after two weeks.

To deploy this build, run from the operator repo, assuming the operator is running:

USER=netobserv VERSION=da852fc make set-plugin-image

1 similar comment
Copy link

New image:
quay.io/netobserv/network-observability-console-plugin:da852fc

It will expire after two weeks.

To deploy this build, run from the operator repo, assuming the operator is running:

USER=netobserv VERSION=da852fc make set-plugin-image

@memodi
Copy link
Member

memodi commented Sep 25, 2025

/test plugin-cypress

@memodi
Copy link
Member

memodi commented Sep 25, 2025

the default namespace for flowMetric is openshift-netobserv-operator which users will need to update to match with ns of flowcollector because of dependency with FLP's servicemonitor.

Not sure if we can read that from flowcollector to have in flowmetric ? at minimum we should clarify in Flowmetric API to use the same namespace and update the default ns to be netobserv

@jotak
Copy link
Member

jotak commented Sep 26, 2025

the default namespace for flowMetric is openshift-netobserv-operator which users will need to update to match with ns of flowcollector because of dependency with FLP's servicemonitor.

It's not really that the default is openshift-netobserv-operator, the default is whatever project the user is selecting in the top header (which indeed will often be openshift-netobserv-operator if they come from the operatorhub page)

Not sure if we can read that from flowcollector to have in flowmetric ?

I was thinking either to do that or to make FlowMetrics truly namespace-based, but we need to think more about it before rushing into something IMO... So in the meantime I just added a text to mention which namespace to write here.
I was thinking that per-namespace FlowMetrics could be part of this epic: https://issues.redhat.com/browse/NETOBSERV-1690 (which some customers are asking and we might soon start working on) - but given the ETA being unclear, perhaps we'll have to do a temporary solution... Maybe create a bug for that, that we'll look into in 1.11, if the epic is done later ?

at minimum we should clarify in Flowmetric API to use the same namespace and update the default ns to be netobserv

I'm surprised that you say that, I think I've added that text already? (not in the API, but in the form)

@openshift-ci openshift-ci bot removed the lgtm label Sep 26, 2025
Copy link

openshift-ci bot commented Sep 26, 2025

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 Sep 26, 2025
Copy link

openshift-ci bot commented Sep 26, 2025

[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 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
Copy link
Member

jotak commented Sep 26, 2025

@memodi as a temporary measure I've set the default to "netobserv", so at least it matches FlowCollector's default, but users still need to make it match if they changed the default.

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

New image:
quay.io/netobserv/network-observability-console-plugin:736ec3a

It will expire after two weeks.

To deploy this build, run from the operator repo, assuming the operator is running:

USER=netobserv VERSION=736ec3a make set-plugin-image

@memodi
Copy link
Member

memodi commented Sep 26, 2025

@memodi as a temporary measure I've set the default to "netobserv", so at least it matches FlowCollector's default, but users still need to make it match if they changed the default.

@jotak - I still see openshift-netobserv-operator as default with newest image:

image

I missed the ns recommendation is in the header text I was looking for it under the NS input box

@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 Sep 29, 2025
@jotak
Copy link
Member

jotak commented Sep 29, 2025

@memodi as a temporary measure I've set the default to "netobserv", so at least it matches FlowCollector's default, but users still need to make it match if they changed the default.

@jotak - I still see openshift-netobserv-operator as default with newest image

Weird, it works for me ... Are you sure you refreshed the page (in case you had the previous version already loaded)?
Here's for me:
Capture d’écran du 2025-09-29 09-32-53

Do you have specific reproducing steps?
What I do is: 1. install v0.0.0-sha-main catalog; 2. install operator; 3. set this console plugin image build; 4. go to installed operators > FlowMetric API > Create FlowMetric

I missed the ns recommendation is in the header text I was looking for it under the NS input box

Fair point, I've just added a commit to move that text under Namespace

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

New image:
quay.io/netobserv/network-observability-console-plugin:9995156

It will expire after two weeks.

To deploy this build, run from the operator repo, assuming the operator is running:

USER=netobserv VERSION=9995156 make set-plugin-image

Copy link

openshift-ci bot commented Sep 29, 2025

@jpinsonneau: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ci/prow/plugin-cypress 2bbb41e link true /test plugin-cypress

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

@memodi
Copy link
Member

memodi commented Sep 29, 2025

I missed the ns recommendation is in the header text I was looking for it under the NS input box

Fair point, I've just added a commit to move that text under Namespace

thanks, it shows up good now.

image

@memodi
Copy link
Member

memodi commented Sep 29, 2025

/label qe-approved

@openshift-ci openshift-ci bot added the qe-approved QE has approved this pull request label Sep 29, 2025
@jotak jotak merged commit 418cd67 into netobserv:main Sep 29, 2025
9 of 11 checks passed
@jotak
Copy link
Member

jotak commented Sep 29, 2025

/cherry-pick release-1.10

@openshift-cherrypick-robot

@jotak: new pull request created: #1051

In response to this:

/cherry-pick release-1.10

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-sigs/prow repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

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.

4 participants