opensdn-io / community Goto Github PK

Create actual flowchart from Anastasia's SDLC whiteboard diagram (attached).

Larger scale testing for the build system; initial target is ~100 VMs or more.

Discord notifications when a new build is pushed to Docker Hub

On rocky9 network-scripts package was deprecated, including the ifup and ifdown we used in the agent. Up to 9.2 they nevertheless worked, but in 9.3, they stop working as expected (in particular, canceling the receipt of an address via dhcp for a physical interface is broken).

For the 24.1 release can we get a matrix of tested versions of OpenSDN 24.1 with OpenStack versions? Similarly another matrix of OpenSDN 24.1 tested with specific Linux distros.

Reliance to current IPAM is limiting operators in analytics and cloud planning tasks. For tf-neutron-plugin we could try to implement some sort of connector to external IPAM to visualise it like in vanilla neutron as well as API responses.

Case: cloud planning when operators have to keep in mind how much public IPs are not assigned to instances.

Add note to TF repos to go to OpenSDN repos

Scope of OpenSDN for first release

End reliance on Juniper MX for edge?

• Mostly a problem with L2; irrelevant for L3 from your cloud
• Think MPLS interconnect
• May only be a small minority of the community that needs this

Scons prints next parasitic messages:

scons: warning: Two different environments were specified for target svc_static_route_intergration_test3_3.log,
but they appear to have the same action: RunUnitTest(target, source, env)
File "tools/build/rules.py", line 189, in TestSuite

scons: warning: Two different environments were specified for target svc_static_route_intergration_test3_4.log,
but they appear to have the same action: RunUnitTest(target, source, env)
File "tools/build/rules.py", line 189, in TestSuite

scons: warning: Two different environments were specified for target svc_static_route_intergration_test4_1.log,
but they appear to have the same action: RunUnitTest(target, source, env)
File "tools/build/rules.py", line 189, in TestSuite

scons: warning: Two different environments were specified for target svc_static_route_intergration_test4_2.log,
but they appear to have the same action: RunUnitTest(target, source, env)
File "tools/build/rules.py", line 189, in TestSuite
WARN: use new versioning scheme 0.1.dev0 instead of 0.1.dev0
WARN: use new versioning scheme 0.1.dev0 instead of 0.1.dev0
WARN: use new versioning scheme 0.1.dev0 instead of 0.1.dev0

Currently, controller contains several outdated (sometimes even broken) parts:

• bfd application (controller/src/bfd), even doesn't contain needed include files;
• bgp daemon (controller/src/bgp/daemon), the purpose of the program is unclear;
• OVS ToR agent (controller/src/vnsw/agent/ovs_for_tor_agent), most likely even not used today by anyone in the world;
• VxLAN agent (controller/src/vnsw/agent/vxlan_agent/linux) looks like contains wrong linker settings, i.e., most likely not used today;
• etcd client (src/contrail-common/config-client-mgr/config_etcd_client.cc) seems to be unused nowadays.

Some work can be relayed into universities: tutorials, benchmarking, seminar, etc, etc.

Revisit analytics and monitoring

• Prometheus uses analytics DB so more monitoring it becomes slow because DB is huge
• Prometheus exporter for vrouter like Linux node exporter?
• Disconnecting analytics and monitoring, because monitoring needs real time and analytics is extremely large
• Does analytics scale?
• Are there key bugs?
• Perhaps create a small team to look more deeply at the path forward for analytics and monitoring

Rework deploy process of kernel driver for Centos based OS (Rocky, RHEL, ...)

• build it at runtime (deploy stage) instead of pre-build at compile stage
• Ubuntu kernel driver built at run-time
• CentOS/RedHat versions pin kernel version; so built at compile stage instead of run-time

A per VRF flow table? (Alexey Abashkin - T1)

• To have limitation per VRF and not overflow common table is some VM starts produce loot of connection
• Yury: flow limits per port?

1. Ability to compile OpenSDN parts using C++11 standard of language
2. Elemination of old (deprectated) constructions: auto_ptr, NULL, etc

Requires:

• Update log4cplus to the newer version (because the older one uses auto_ptr): setLayout
• Refactoring of contrail-common/database (gen_if.cc, cql_if.cc,etc), since it uses boost::bind, which is not compatible with std::unique_ptr

Send Gerrit review notifications and similar to discord channel.

VPN as a service (see December roadmap discussion)

The latest version of nodejs used in WEB UI is pretty much outdated: https://gerrit.opensdn.io/plugins/gitiles/opensdn-io/tf-packages/+/refs/heads/master/rpm/contrail-web-core/contrail-web-core.spec#34

This feature request aims to bump nodejs to the latest supported version:
https://nodejs.org/en/about/previous-releases

It looks like we don't have hardware and specialists to verify the work of OpenSDN on FreeBSD. Hence, I think it's about to remove it's support.

Move build infra from centos7 to rocky9

1. Get rid of boost::ptr_map by substituting it with std::map / std::unordered_map (see sandesh_uve.h, for instance), usage of std::unordered_map forces the usage of std::auto_ptr

PLEASE PROVIDE MORE DETAILS ON THIS

Need to discuss for next step for alignment of RBAC between TF and OpenStack

Switch tf-ansible-deployer to vanilla kolla-ansible for newer versions of OpenStack

What's the scenario to testing?.
What's the scenario to support (kernel version, OS, NIC vendor)

The instructions under:

http://docs.opensdn.io/contributing-to-opensdn/index.html

Are just not where they need to be. Both inaccurate and have older LFN related processes.

We need to look at the Snyk.io pull requests for package updates. I'm afraid to merge them randomly in case we break the build.

Apologies, I didn't create an issue for this even though the work has already begun. Please update this issue with latest.

What do we do with https://github.com/tnaganawa/tungstenfabric-docs/tree/master

Better bare metal support in OpenStack:

• Ironic / MAAS support and integration with OpenStack for bare metal provisioning on demand with support for the vrouter-agent

Notification activity of OpenSDN to Telegram feed

We need to test that we can use EVPN VXLAN with non-Juniper hardware vendors such as Cisco and Arista.

When requesting information about many (> 5000) elements (virtual machine interfaces, virtual networks, etc) via VNC config client, it might create long delays (due to querying Config or Cassandra DB) which might create timeout errors.

The situation happens, for instance, in Web UI for requests of 5000 VNs : /virtual-networks?detail=true&fields=physical_router_back_refs,floating_ip_pools,bridge_domains

The similar case can be also reproduced using request of information for 5000 ports (virtual machine interfaces)

Automatically create doxygen docs for the codebase.

We need a clear manual to troubleshoot and inspect routing and forwarding problems in OpenSDN.

k8s support and testing [LOW]

• Woj testing nested mode with k8s, service chaining, etc
• Unclear if there are customers actually asking for this

Need a plan for adding layer-7 load balancing to OpenSDN. Example features:

• Terminate HTTPS
• Support for QUIC

Number are:

• count of previous and current users
• number of installations
• maximum number of managed hypervisors
• count of source code lines
• delays
• amount of operational CPU-hours (w/o accident)
• etc, etc

Need a complete map of which documentation is where, who it's for, and how fresh/stale a given piece of documentation is

1. High level document map:

• Architecture (Engineer/Architects): what are the pieces, how do the fit together, and how do they communicate
• Deployment (Operators): how do I get it up and running
• Use Guide (End Users): how do I configure and run it
• Developer Guide (Developers): how do I setup a dev environment, write tests, push code back
• Datasheet / Whitepaper(s) (Business): how does it compare to other SDN options
• Quick Start Guide (Developers, Operators, and End Users): 15 minutes to fame

2. Map the above to existing documents

• Randy to get feedback from the group on the freshness of the existing documents
• Documentation/Tech Writer resources?
• Yury suggests slow and steady re-write a document at a time
• Randy: If we have the document map this might be doable

I had a little conversation with @mkraposhin about eBPF. This could be a nice feature to implement something in a simple way instead of hard-coded into cpp vrouter's code. Seems like Kubernetes dudes are using it for a long time in a lot different ways.
Most simple case that could be solved is QoS (bandwidth limit).
Following original Juniper docs that operator have to configure nova flavor is leading to use linux HTB by default that will cause whole network degradation at some moment (i've observed that it could happen when interfaces with QoS counts more than 200) due to monstrous spin_lock locks (more details you can find here. eBPF could help to limit flows bandwidth for example but actual use case is a lot bigger.
It is possible to hook into vrouter packet processing pipeline to do something on a kernel-level and it is documented behavior.

eBPF programs are event-driven and are run when the kernel or an application passes a certain hook point. Pre-defined hooks include system calls, function entry/exit, kernel tracepoints, network events, and several others.

If a predefined hook does not exist for a particular need, it is possible to create a kernel probe (kprobe) or user probe (uprobe) to attach eBPF programs almost anywhere in kernel or user applications.

Seems like there is no big overhead using eBPF because it is being executed on a kernel-level.

refs:

• https://www.tigera.io/learn/guides/ebpf/ebpf-xdp/
• https://ebpf.io/what-is-ebpf/#hook-overview
• https://habr.com/ru/articles/683566/ (nice article that shows how easy it could be to attach eBPF using Python)