osm ns-list
+------------------+--------------------------------------+---------------------+----------+-------------------+---------------+
| ns instance name | id | date | ns state | current operation | error details |
+------------------+--------------------------------------+---------------------+----------+-------------------+---------------+
| fos_test | 357e974c-d4f1-42d9-8151-b040a927b2a0 | 2020-09-03T09:50:31 | READY | IDLE (None) | N/A |
+------------------+--------------------------------------+---------------------+----------+-------------------+———————+
uri
in the image
section of the descriptor to your image on dockerhub eg. in the case of the simple alpine:nginx image it would become like this …
“image”:{
“uri”:””docker.io/library/nginx:alpine”,
"checksum": "",
"format": “"
}
…
@gabrik Thanks, I tried both (nginx, and ros2-demo) but it was not successfull yet.
when I try to run the ros2-demo, I get "No Nodes in the system".
or I get "Error 404 with message No node found for this FDU" when I use the Linux zenoh.service daemon instead of the eclipse/zenoh docker image. The error comes from this line: inst_info = a.fdu.define(fdu_id)
And I start the script with python3 deploy.py localhost:7447
I have the following components running on my LinuxMint:
fos_agent , fos_ctd, fos_linux, fos_linuxbridge, containerd, zenoh
Do I have all required components to run the ros2-demo or do I need additional components/ nodes ?
journalctl -u fos_agent | grep eval_check_fdu
when you get the error?
>>> api.fdu.migrate(inst_info.get_uuid(),'9806ff42-cecc-48c1-9f44-da51955d4732')
^CTraceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python3.8/dist-packages/fog05/fimapi.py", line 1332, in migrate
self.__wait_specific_node_fdu_state_change(destination_node_uuid, instanceid, 'RUN')
File "/usr/local/lib/python3.8/dist-packages/fog05/fimapi.py", line 914, in __wait_specific_node_fdu_state_change
fdu_info = self.connector.glob.actual.get_node_fdu_instance(
File "/usr/local/lib/python3.8/dist-packages/fog05_sdk/yaks_connector.py", line 827, in get_node_fdu_instance
kvs = self.ws.get(p)
File "/usr/local/lib/python3.8/dist-packages/yaks/workspace.py", line 111, in get
reply = q.get()
File "/usr/lib/python3.8/queue.py", line 170, in get
self.not_empty.wait()
File "/usr/lib/python3.8/threading.py", line 302, in wait
waiter.acquire()
Hi @meeeehdiiii_twitter, yes the communication, I will rather say, networking between distributed applications is in the scope of fog05. The LinuxBridge plugin indeed creates L2 overlay networks between different FDUs (an FDU is anything that fog05 can manage eg. VMs, Containers, binaries), current implementation is using VxLAN with multicast discovery of the end-points, so it works well inside a LAN. There is plan to add to the LinuxBridge plugin also the possibility to create L3 overlay networks (using GRE) and Point-to-Point VxLAN (thus allowing FDUs in differents LANs to communicate). We tend to preferr decentralized solutions but for in case of nodes in different LANs what we see is that the use of a common rendez vous point is needed, (point-to-point VxLAN or GRE) and then inside LANs the communication can still leverage on VxLAN with multicast end-point discovery.
We plan also to support a OVS Plugin, the level of functionalities expected is the same as the LinuxBridge one, they have to implement the same interface with the Agent and other plugins. We think that an OpenVSwitch plugin may have more flexibility.
We are also investigating the possibility to provide a out-of-the-box virtual network to be used by default by fog05 FDUs, something like the docker0 bridge from Docker, to facilitate users in their first approach.
As already stated before, we are currently working on a rewrite and redesign of some internal components in rust (https://www.rust-lang.org/) and this involves offcourse the networking plugins and their interface.
I hope this answers your questions, in any case please feel free to ask.
Hi all,
we are happy to announce fog05 version 0.2.2 that comes with:
fosctl
utility that allows deployments on both fog05 and K8s clusters! More details on fosclt
can be found here: https://fog05.io/docs/getting-started/introducing-fosctl/
While installation instruction for the orchestration engine are available here: https://fog05.io/docs/getting-started/force-installation/
Hi @marcogozzi thanks for reporting this, I guess there is an error in the makefile/debian file.
Regarding connectivity issue, by default the native plugin isolates the binaries in a separate namespace, so network is isolated if not connected to a virtual network that then is able to reach the internet or bridged to an existing virtual bridge.
You can disable isolation, it is a configuration flag in /etc/fos/plugins/plugin-fdu-native/native_plugin.json
just changing isolation to false
Hi @afzalj-t you can just install it from the .deb files that you can found here: https://github.com/eclipse-fog05/fog05/releases/tag/v0.2.2
There also a guide in the docs: https://fog05.io/docs/getting-started/installation/#from-debian-packages
While debugging can be done using the system log, journalctl -u <fog05 component> -f
the fog05 components depends on the component you have installed
I see, it is missing this one: https://github.com/eclipse-fog05/fog05/releases/download/v0.2.2/libzenoh-0.3.0-amd64.deb
We will update the guide, thank for spotting this
Hi @OliLay, that is not yet supported because the latest fog05 release is based on a very old version of Zenoh.
While in the current development branch that will be possible, because we are leveraging the latest version of zenoh and because of some changes on the architecture of fog05.
In that case each node will have its own Zenoh router and then routers in different nodes can discover using the discovery protocol, avoiding all the configuration process necessary today.
We did not yet completed the port for all the plugins we had in the previous version, but if you are curious just take a look at master
branch for https://github.com/eclipse-fog05/fog05
We are in the process of defining the roadmap for the next months, that will probably contain a beta release for the rust rewrite.
Ideally we would like to have the port of all the plugins we had before doing a release, so I would say it would need around 3 months.
Anyway testing the “new” version is quite easy, and you can also generate debian packages by yourself: https://fog05.io/docs/getting-started/installation/#from-source
Hi, port mapping is not currently available, you should attach that container to a virtual network in order for it to get address.
You can see an example of virtual network here: https://github.com/eclipse-fog05/examples/blob/master/fim_api/descriptors/vnet_dhcp.json
And of an FDU attached to that virtual network: https://github.com/eclipse-fog05/examples/blob/master/fim_api/descriptors/fdu_lxd_net.json
In next release FDUs will be attached to the default virtual network of fog05 and therefore port mapping will be possible.