Code Monkey home page Code Monkey logo

easy-nmos's People

Contributors

garethsb avatar pkeroulas avatar rhastie avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

easy-nmos's Issues

Problems with workaround for python mDNS issue

The workaround added by 30b5ad1 means that the testing tool container is not on the Docker network. That's a problem for testing anything that is advertised by the Registry or Node with a docker-network IP address. The first example I've found is IS-07-02 test_04/_05, which result in "Error opening WebSocket connection to ws://172.30.101.4:11001/x-nmos/events/v1.0/devices/77b79486-3b6f-5872-9b9b-dd7e880add50".

I think the real fix is to reinstate both interfaces and solve AMWA-TV/nmos-testing#214 in the testing tool.

How to use the MQTT Broker

Hi Richard,

Thank you for taking care of the NMOS implementation.
You integrate an MQTT broker but I can't find any information about it.
I would like to try to control functions in the nodes and read out statuses via MQTT.
I can reach the broker and I see the #SYS topic.
But which topics do I have to work with to control the virtual node or other devices?
Is the virtual node already registered with the MQTT broker, or do I have to initiate this?
Or have I understood something completely wrong?

thanks in advance,
froschl

Can not access to control page via browser

Hi Richard,

I'm a beginner of docker and Linux only have a little bit experience of docker and docker-compose.
My problem is that when I modify the docker-compose.yaml file and change the ip address to match the subnet of my ubuntu 22.04 laptop NIC, such as the enp4s0 or wlp5s0 interface, cpp will run but nmos-testing will not.
Based on another issue report and the log, I understand that the problem of nmos-testing is relate to internet connection, but my question is, when easy-nmos set the macvlan to based on both the docker0 and enp4s0 or wlp5s0, I cannot access to the easy-nmos controller page via browser, even if I use the ip address or localhost:80.
Could you please guild me to solve this problem?

My docker0 is 172.17.0.0/16, wls5p0 is 192.168.2.0/24, if I modify the macvlan interface to docker0, and use 172.17.0.0/16, the docker-compose shows
failed to create network easy-nmos-master_external: Error response from daemon: Pool overlaps with other one on this address space
if I use wlp5s0 which is a wireless nic but only for testing easy-nmos and to make sure the internet connection, the container will running, but I can't access both controller or others page.

Many thanks!

My docker-compose file content:

version: '3.6'

services:

Create NMOS Registry/Controller container instance

nmos-registry:
image: rhastie/nmos-cpp:latest
container_name: nmos-registry
hostname: nmos-registry
domainname: local
ports:
- "80-81:80-81"
- "1883:1883"
volumes:
- "./registry.json:/home/registry.json"
environment:
- RUN_NODE=FALSE
networks:
external:
ipv4_address: '172.17.0.241'

Create NMOS Virtual Node container instance

nmos-virtnode:
image: rhastie/nmos-cpp:latest
container_name: nmos-virtnode
hostname: nmos-virtnode
domainname: local
ports:
- "80-81:80-81"
volumes:
- "./node.json:/home/node.json"
environment:
- RUN_NODE=TRUE
networks:
external:
ipv4_address: '172.17.0.242'
depends_on:
- nmos-registry

Create AMWA NMOS Testing container instance

nmos-testing:
image: amwa/nmos-testing:latest
container_name: nmos-testing
hostname: nmos-testing
domainname: local
entrypoint: |
/bin/bash -c "/etc/init.d/dbus start;
/etc/init.d/avahi-daemon start;
python3 nmos-test.py"
ports:
- "5000:5000"
volumes:
- "./UserConfig.py:/config/UserConfig.py"
networks:
external:
ipv4_address: '172.17.0.243'
depends_on:
- nmos-virtnode

networks:
external:
# Create external macvlan subnet using host physical interface allowing containers to have their own IP addresses
driver: macvlan
driver_opts:
parent: docker0
ipam:
config:
- subnet: 172.17.0.0/16

RPI with Ubuntu

Hello - had issues with Docker starting the macvlans on the build. I ran across a command that finally made it work. apparently there are some repsitories required for raspberry pi.

The golden command I used was
sudo apt install linux-modules-extra-raspi

no clue what it did or why, but hey. it works.

nmos-testing not starting (2)

Hi there,

i have an issue with starting the easy-nmos docker images. As stated in the readme, in my docker-compose-file i adjusted the ip-addresses for the nmos instances and also the external network but docker complains:

ERROR: for nmos-registry Cannot start service nmos-registry: Invalid address 10.0.230.101: It does not belong to any of this network's subnets.

-- excerpt from the compose-file: --
networks:
    external:
      # Create external macvlan subnet using host physical interface allowing containers to have their own IP addresses
      driver: macvlan
      driver_opts:
          parent: eno1
      ipam:
          config:
          - subnet: 10.0.0.0/8
-- snip --

The hosts ethernet has the 10.0.12.9/8.

Any ideas?

Regards, Marco

Initial feedback

Why three separate docker-compose.yml files? Which one should people use?

Can node-json and registry-json be renamed node.json and *registry.json?

node-json can probably be tweaked a little. I suggest:

  • deleting registration_port because that should be picked up from mDNS
  • making the logging level a bit more verbose by default
  • keeping logging on the same port so it's easy to stumble upon
{
  "label": "easy-nmos-node",
  "logging_level": -20,
  "http_port": 11000,
  "how_many": 2
}

Similarly for the registry-json, e.g.

  • more verbose logging by default
  • remove allow_invalid_resources since false is the default
{
  "logging_level": -20,
  "label": "easy-nmos-registry",
  "pri": 10,
  "http_trace": false,
  "http_port": 8010,
  "query_ws_port": 8011
}

nmos-testing fails upon startup due to nameserver issues

Thank you for authoring this orchestration layer.

I am wondering if you've seen this issue: When started using docker-compose, the nmos-testing image fails upon startup because it is unable to resolve the hostname github.com.

 File "nmos-test.py", line 19, in <module>
    NMOSTesting.main(sys.argv)
  File "/home/nmos-testing/nmostesting/NMOSTesting.py", line 978, in main
    init_spec_cache()
  File "/home/nmos-testing/nmostesting/NMOSTesting.py", line 526, in init_spec_cache
    repo = git.Repo.clone_from('https://github.com/AMWA-TV/' + repo_data["repo"] + '.git', path)
  File "/usr/local/lib/python3.6/dist-packages/git/repo/base.py", line 1032, in clone_from
    return cls._clone(git, url, to_path, GitCmdObjectDB, progress, multi_options, **kwargs)
  File "/usr/local/lib/python3.6/dist-packages/git/repo/base.py", line 973, in _clone
    finalize_process(proc, stderr=stderr)
  File "/usr/local/lib/python3.6/dist-packages/git/util.py", line 329, in finalize_process
    proc.wait(**kwargs)
  File "/usr/local/lib/python3.6/dist-packages/git/cmd.py", line 408, in wait
    raise GitCommandError(self.args, status, errstr)
git.exc.GitCommandError: Cmd('git') failed due to: exit code(128)
  cmdline: git clone -v https://github.com/AMWA-TV/nmos-discovery-registration.git cache/is-04
  stderr: 'Cloning into 'cache/is-04'...
fatal: unable to access 'https://github.com/AMWA-TV/nmos-discovery-registration.git/': Could not resolve host: github.com

Interestingly, I don't have this problem if I manually start the container using docker run -d -p "5000:5000" amwa/nmos-testing. I suspect it's related to docker-compose using a custom network.

Hoping you've encountered this and can offer some advice.

Host OS: I've tested on Centos 7 and Ubuntu 20.04 with identical results
docker version 19.03.8, build afacb8b7f0
docker-compose version 1.27.4, build 40524192

System setup:

  1. Install fresh Ubuntu 20.04 (launch new AMI on AWS)
  2. apt-get update
  3. apt-get install docker.io
  4. (install docker-compose using curl/chmod)
  5. install easy-nmos using git clone
  6. Edit docker-compose.yml
  • three unique IP addresses in correct subnet
  • change parent interface name to match host interface name
  • change parent subnet range to match host subnet range
  1. docker-compose pull
  2. docker-compose up

Unable to get easy-nmos running on Mellanox NIC

I've been struggling to get easy-nmos to run on the Mellanox interface of a VM running inside VMware Workstation.

For whatever reason, if the docker container is configured to point at the Mellanox then no connections can be made from either the VM or other systems on the isolated Mellanox subnet (10.0.0.0/8 with no gateway). Some things already tried:

  • Start VM with only a Intel (LAN) NIC present and with the container IPs set in the LAN subnet - this always works fine.
  • Start VM with Intel and Mellanox NICs present and with the container IPs set in the Mellanox subnet - container NICs cannot be pinged.
  • Start VM with only Mellanox NIC present and with container IPs set within Mellanox subnet - container NICs cannot be pinged.

The VM's IP on the Mellanox interface is 10.90.0.2, and when the VM is up this IP can be pinged from anywhere in the Mellanox subnet. So it's not a generic networking problem with the Mellanox interface. It's only a problem with getting the container to work with that interface.

There are no errors during container start-up, so the presumption is that this is a subtle configuration issue.

As per comments in another case, I tried setting promisc mode on the Mellanox interface within the VM, and adding a pseudo-gateway of 10.90.0.2 in docker-compose.yaml, but again without success.

Not sure where to go from here. Assistance would be greatly appreciated, please let me know if further details are needed.

nmos-testing not starting?

Host Ubuntu 22.04.3 LTS
HOST IP 10.0.0.181

I don't see what's wrong with the settings/subnet/range.
The original docker-compose.yml with ipv4_address: '192.168.6.101' runs but IP doesn.t match host.

~/easy-nmos$ docker-compose up
[+] Running 0/0
⠋ Container nmos-registry Creating 0.0s
Error response from daemon: invalid config for network easy-nmos_external: invalid endpoint settings:
no configured subnet or ip-range contain the IP address 10.0.0.191

~/easy-nmos$ ifconfig
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
ether 02:42:b8:8c:4a:59 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

enp6s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.0.181 netmask 255.255.255.0 broadcast 10.0.0.255
inet6 2601:640:c901:d9e0:463f:c6a7:a971:2ef4 prefixlen 64 scopeid 0x0

docker-compose.yml :

version: '3.6'

services:

Create NMOS Registry/Controller container instance

nmos-registry:
image: rhastie/nmos-cpp:latest
container_name: nmos-registry
hostname: nmos-registry
domainname: local
ports:
- "80-81:80-81"
- "1883:1883"
volumes:
- "./registry.json:/home/registry.json"
environment:
- RUN_NODE=FALSE
networks:
external:
ipv4_address: '10.0.0.191'

Create NMOS Virtual Node container instance

nmos-virtnode:
image: rhastie/nmos-cpp:latest
container_name: nmos-virtnode
hostname: nmos-virtnode
domainname: local
ports:
- "80-81:80-81"
volumes:
- "./node.json:/home/node.json"
environment:
- RUN_NODE=TRUE
networks:
external:
ipv4_address: '10.0.0.192'
depends_on:
- nmos-registry

Create AMWA NMOS Testing container instance

nmos-testing:
image: amwa/nmos-testing:latest
container_name: nmos-testing
hostname: nmos-testing
domainname: local
entrypoint: |
/bin/bash -c "/etc/init.d/dbus start;
/etc/init.d/avahi-daemon start;
python3 nmos-test.py"
ports:
- "5000:5000"
volumes:
- "./UserConfig.py:/config/UserConfig.py"
networks:
external:
ipv4_address: '10.0.0.193'
depends_on:
- nmos-virtnode

networks:
external:
# Create external macvlan subnet using host physical interface allowing containers to have their own IP addresses
driver: macvlan
driver_opts:
parent: enp6s0
ipam:
config:
- subnet: 10.0.0.0/24

Network connection doesn't work to any of the nodes

Hi,

I can't access or ping any of the three nodes.
I tried doing ip link set eth0 promisc on other user suggested but that did not help.

My network settings:

nmos@7thnmos:~$ ifconfig
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
ether 02:42:0f:4c:c3:27 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth0: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST> mtu 1500
inet 10.100.116.40 netmask 255.255.252.0 broadcast 10.100.119.255
inet6 fe80::215:5dff:fe64:a902 prefixlen 64 scopeid 0x20
ether 00:15:5d:64:a9:02 txqueuelen 1000 (Ethernet)
RX packets 551471 bytes 593363017 (593.3 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 40471 bytes 3906995 (3.9 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 478 bytes 48068 (48.0 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 478 bytes 48068 (48.0 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

docker-compose.yml:

version: '3.6'

services:

Create NMOS Registry/Controller container instance

nmos-registry:
image: rhastie/nmos-cpp:latest
container_name: nmos-registry
hostname: nmos-registry
domainname: local
ports:
- "80-81:80-81"
- "1883:1883"
volumes:
- "./registry.json:/home/registry.json"
environment:
- RUN_NODE=FALSE
networks:
external:
ipv4_address: '10.100.116.41'

Create NMOS Virtual Node container instance

nmos-virtnode:
image: rhastie/nmos-cpp:latest
container_name: nmos-virtnode
hostname: nmos-virtnode
domainname: local
ports:
- "80-81:80-81"
volumes:
- "./node.json:/home/node.json"
environment:
- RUN_NODE=TRUE
networks:
external:
ipv4_address: '10.100.116.42'
depends_on:
- nmos-registry

Create AMWA NMOS Testing container instance

nmos-testing:
image: amwa/nmos-testing:latest
container_name: nmos-testing
hostname: nmos-testing
domainname: local
entrypoint: |
/bin/bash -c "/etc/init.d/dbus start;
/etc/init.d/avahi-daemon start;
python3 nmos-test.py"
ports:
- "5000:5000"
volumes:
- "./UserConfig.py:/config/UserConfig.py"
networks:
external:
ipv4_address: '10.100.116.43'
depends_on:
- nmos-virtnode

networks:
external:
# Create external macvlan subnet using host physical interface allowing containers to have their own IP addresses
driver: macvlan
driver_opts:
parent: eth0
ipam:
config:
- subnet: 10.100.116.0/22 nmos

Easy is just a name.... It's not easy at all!!!

Just a comment to say that for a technology that is supposed to be the actual and future revolutionary standard it look so far to become one. It's not easy at all. I had troubles at every steps of the installation process... And it's still not completely working. That's not user friendly and it will need still a lot of developpment to really get the name easy.

I will not explain my issues here. it's a general issue to say that this is impossible to use this in a serious production process.

Th

nmos-testing not starting?

I get this error when running docker-compose up

nmos-testing     |   cmdline: git clone -v https://github.com/AMWA-TV/nmos-discovery-registration.git cache/is-04
nmos-testing     |   stderr: 'Cloning into 'cache/is-04'...
nmos-testing     | fatal: unable to access 'https://github.com/AMWA-TV/nmos-discovery-registration.git/': Failed to connect to github.com port 443: No route to host

virtnode and registry seem to be working fine. My suspicion is it's to do with IP gateway setups on macvlan but it's not clear how to resolve that. This is running on Ubuntu 20.04 on Rasp. Pi 4. Can reach github.com without issue from console.

General newby questions about subscriptions...

Hello,

Can you explain me what parameters I have to write to make subscriptions by the web-interface ?
And maybe also by HTTP request (to try some external automations)
For the moment we were able to make work easy-nmos and we see all our devices:

  • Coax SFPs from Embrionix
  • Blackmagic 2110 Converters

We'd like to make some virtual routing between all that stuff but it's not totally clear for us.
I was able to make some route by the receivers page ("connect" tab)
But in that way, the "subscriptions" page stays empty

Thanks in advance for your help

Kind regards

can't seem to get macvlan to expose the nodes

short version: everything starts up and the running logs look like they should, but I can't get access from another VM. Seems like I'm missing something on the macvlan setup.

Would appreciate any advice. Not a giant urgency, but thanks


Details:
running VirtualBox on a WIN10 machine-
Created a NATnetwork, and added:
VM1: "UbuntuSDW", running Ubuntu 20.04.2.0 LTS (to put the main components and run the docker bits).
ifconfig shows me a docker interface ("docker0") and "enp0s3" adapters. enp0s3 is at 192.168.6.4

VM2: "Unbunt2aux", running Ubuntu 20.04.2.0 LTS (to be a client and explore the easy-nmos result through a browser.)
ifconfig shows me a docker interface ("docker0") and "enp0s3" adapters. enp0s3 is at 192.168.6.5

These 2 VMs can ping each other, and access the outside world in a browser session. I can startup the docker containers and everything looks great, the running logs look exactly like the examples...but I can't access the nmos-registry node from the other VM.

From VM2, no result from a ping to the nmos-registry IP or "nmos-registry.local/admin". No response from the browser. Nothing I've tried can see the new devices (registry, virtual node, and test).

The yml file looks correct, but the macvlan external nodes don't seem to be available. The subnet is 192.168.6.0/24 and the adapter is enp0s3.

I tried a few variations on allowing promiscuous mode, but no change.

Off subnet availability

Hi Richard,

First, thanks for providing this tool. I've been using it since it was first published and has been incredibly helpful for various different scenerios.

One use case I have continually had to configure is a gateway for the containers to talk to remote networks. I've found myself writing documentation for colleagues are various points over the years and figured I should probably raise an issue to cut out the middle man.

The process is to create a macvlan outside of docker-compose using docker. This allows you to attach a gateway to the network. And then in the docker-compose.yml, reference the newly created network rather than create a new one.

Would you be open to me submitting you a PR for a section in the README and an example docker-compose.yml file? More than happy to contribute.

Cheers!

Promiscious mode needed on network device

To access the IPs from outside the docker containers it is necessary to set the network adapter into promiscuous mode.
In Ubuntu this is possible with:
ip link set eth1 promisc on
Maybe you could add a hint to the readme file?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.