UI filters

[hellt]

Hi all,
I've recently discovered edgeshark and started to use it with our containerlab.dev project. Awesome work, thank your for open sourcing it.

There is one immediate UX improvement I thought would be beneficial to have for everyone - namely, filtering capability.

When you have >5 containers running on a system the UI might get busy very quickly, it would be nice to have an input field that would allow setting a query for a node display.

e.g. name: frontend-* filters/displays only elements whos name starts with frontend-

[thediveo]

With the packetflix handler quarantine woes out of our ways -- are you aware that when downloading the handler .app, macos will tell users it is damaged? Downloaders need to do: xattr -d com.apple.quarantine packetflix-handler.zip first 🤦🏼

When it comes to filtering: precise ("nothing given, you spelt it wrong, you get it that way") or fuzzy that might turn up inexact matches?

Which view(s) would you see the filtering provided for: the wiring view I assume? Or would this even maybe a new view?

In case of the wiring view: when filtering, only the "cards" -- to use Material Design speak -- that have containers matching (fuzzy or not) getting displayed, with their network interfaces. Now, what would you expect as to the wiring?

• not needed/shown at all?
• showing only when connecting cards that match the filter?
• showing also connecting to cards, and showing these cards, if they have a direct connection to a card that matches?

[hellt]

In our internal tests using the recent mac os versions and the AppleScript I shared here we didn't see any errors. Users needed to whitelist this script as it comes from a developer without a signature, but that is a usual security chore one needs to do. So, I am not sure what happened to your way of packaging... My apple dev skills started and ended yesterday :D

1 exact vs fuzzy

When it comes to filtering: precise ("nothing given, you spelt it wrong, you get it that way") or fuzzy that might turn up inexact matches?

I think what I am inspired by is some sort of query language. Surely, it doesn't need to be a query language, for our use case the exact match is just fine. A regex would be awesome, it allows for precise and non-precisy matching, and is familiar to most engineers.

2 Views

Which view(s) would you see the filtering provided for: the wiring view I assume? Or would this even maybe a new view?

Yes, I had the wiring view in mind.

3 Wiring with filters

In case of the wiring view: when filtering, only the "cards" -- to use Material Design speak -- that have containers matching (fuzzy or not) getting displayed, with their network interfaces. Now, what would you expect as to the wiring?

This is likely the toughest problem =)

I think showing the wiring that terminates withing the filtered cards is necessary. The other interface (like ones going to the bridge in the root netns) is a different story.

Maybe wiring visual can take form of an external interface where there is a line pointing to the void. But as an MVP I think even no wiring at all would do just fine.

4 Global elements display settings

I wanted to bring another point to the discussion - global elements display setting.

I find it quite useful to allow a user to coarsely set what element types they want to be displayed by using a toggle/checkbox in the top menu bar.

To give you an example that speaks to our use cases - 95% of the time we are interested in container's interfaces only. This means we are not interested in other bind mounted netns, nor root nets, nor some global PID netns. They are considered the visual clutter in our case.

The way to easily tackle this is to implement display settings, for example like Cilium Hubble does it:

Having such an option in gostwire UI would be great.

[thediveo]

Wiring

Heh, you independently arrived at similar conclusions: just showing the matching cards and their wiring should be fine, and the other two-ended connections then rendered as a straight line that -- if I can manage to do this in SVG -- than simply fade out without any direction.

Now I need to ponder a little bit about how to integrate the filter input into the UI. That looks like it should have a shown/hidden state, need to read a little bit on how Material Design apps might do this UI-wise.

[thediveo]

something like this?

this is not a mock-up, but a poc:

• filter string/pattern, +-case sensitive, +-regexp ... gets persisted in browser local storage
  • pattern is substr unless regexp switch has been pressed
• sidebar list of containees shows only matches
• wiring view shows only matches, or an short notice that the filter settings result in nothing.

WDYT?

[thediveo]

that went better than expected, albeit still with some fighting regarding when to set the focus and to get the proper input field HTML element from deep inside up the React component hierarchy. Alas, "Ctrl+f" (~"filter") and "/" both work now, focusing the filter input field; "Enter" closes -- as does "Esc" anyway all the time.

[tiago-amado]

Excellent feature!
I've shared servers running multiple network scenarios, with tens of containers. With this feature, each user is able to filter its own containers, or a specific network setup!
Awesome work guys!

[thediveo]

That's interesting and highly useful feedback. Edgeshark -- not least according to its name -- has been a tool primarily used by Industrial Edge users, both in and out of company, but these tend to operate small hosts and moderate dev systems. Especially some rather small IPCs with two cores and one, at most two gigs of RAM ... and that being already "fat" machines currently in the Industrial domain. We just recently started official product support for the ARM64 platform, and namely one of our ARM64-based IPCs.

The containerlab community now is an extension of the Edgeshark tooling into use cases that are different from our main use cases, where we typically don't use Docker as a very convenient virtualization environment for (pseudo) VMs for networking. Despite this, Edgeshark has its root in our use of GNS3+Docker quite some time ago for IPv6 labs in industrial automation.

In the past years, Edgeshark has often been used to introduce esp. app developers to the container networking in our Industrial Edge devices. For instance, MACVLAN is an integral layer 2 access part in our domain due to layer 2 protocols, such as the RT parts of Profinet and device commissioning. I suspect that most of our users haven't been used Wireshark at all so far. To them, Edgeshark helps understanding the virtual topology and the MAC and IP configuration details ... and especially helps in dispelling incorrect assumptions about (Docker) virtual networking. Edgeshark thus always needs to strongly support these use cases, so the Wireshark/capture aspect must not interfere with this usage.

[hellt]

I just realized the netflix tribute in the packetflix name :D

Thanks for the history background. I was very surprised to see a project like edgeshark coming out of Siemens and the industrial edge use case, frankly.
But nevertheless, it is an absolute treasure for containerlab use case and when we get to the Containerlab UI there is no reason not to package Edgeshark with it as a pluggable service for packet capturing.

[tiago-amado]

Well I see EdgeShark as an amazing tool for all IP network guys. It should be integrated somehow in CLAB. Or at least we could have the option to install CLAB with EdgeShark.
This is useful for all the CLABs users, and that covers Network Engineers or Universities!

[thediveo]

released in new multi-arch image v2.3.4