NETOBSERV-135 super columns + NETOBSERV-204 filters

[jpinsonneau]

This PR is an alternative to #83 using FQDN fields

Full Qualified Name fields can either contains ip:port or namespace.pod

Filtering on SrcFQDN + DstFQDN with match any option will group query by (SrcNamespace AND SrcPod) OR (DstNamespace AND DstPod) so it solves NETOBSERV-204

http://localhost:3100/loki/api/v1/query_range?query={app="netobserv-flowcollector",FlowDirection="0"}|json|(DstNamespace=~".*openshift-monitoring.*"+or+DstPod=~`.*prometheus-k8s-1.*`)+or+(SrcNamespace=~".*openshift-apiserver.*"+or+SrcPod=~`.*apiserver-f65cb946b-7mckt.*`)&limit=100&start=1646324861

Also added the ability to filter on Source / Destination / Both for Common fields using an accordion in filter dropdown

These new filters appears in the table as fields for PoC.

[openshift-ci]

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

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please ask for approval from jpinsonneau after the PR has been reviewed.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[openshift-ci]

New changes are detected. LGTM label has been removed.

[jotak]

It could be risky to handle so many different cases under the "FQDN" case, no? For instance, what if we're doing a partial matches? could "10.9" be seen as namespace + pod, whereas we're looking for an IP with partial match?

I just wonder if you're not trying to do too much here, beyond the main use case of a FQDN which would just be "namespace.pod" ?
by the way, I think it should be reversed, "pod.namespace" rather than "namespace.pod", it more on page with the actual kube domain naming: https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-s-hostname-and-subdomain-fields

[jpinsonneau]

Yes there are a lot of cases but I guess we can improve front end input to split them correctly. As a user I feel it's easier to type namespace first.
What if we separate ip:port from namespace.pod cases in two filters and implement autocompletes for namespaces & pods ?
It could show a first AC for namespaces then a second one for pods (filtered by selected namespace).
Then the concatenation will be done by the code and added to filters to avoid mistakes.

[jotak]

yes, if the user is presented specific fields for namespace and pod, it solves the FQDN order problem (but it's more work to do, especially with auto-completion).
+1 also to separate ip/port to a different filter type.

[jpinsonneau]

Sure I can handle it 👍
Thanks for the feedback

[jpinsonneau]

• Spitted FQDN field to Namespace & Pod and Address & Port filters
• Added auto completion for Namespace / Pod / Namespace & Pod filters
  • Namespaces are get only when user select a namespace filter type
  • Pods are get only when at least one filter already exists on a specific namespace
  • Namespace & Pod shows namespaces at first, then pods from selected namespace.
    User can't filter if namespace + pod is not found (only for this field)
  • Address & Port manage IPv4 / Range / CIDR only since we use : to split

[jpinsonneau]

I have played a bit around a more generic Kubernetes Object filter for Service / Deployment / StatefulSet / DaemonSet / Job / CronJob.

We can either wait for FLP merge or go ahead with it and do the proper modification in processKubeObjectFilter function when FLP is ready