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": “"
}
…Like you can see in this demo: https://github.com/atolab/eclipse-fog05-ros2-demo
@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 ?
The error you get seems related at the failing of some check during the instantiation process.
Can you check the output of
journalctl -u fos_agent | grep eval_check_fdu when you get the error?
13 replies
I wanted to install the CLI but cannot find the install scripts...
Can the CLI already be used to deploy microservices?
>>> 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()- Currently, there is the LinuxBridge network plugin. Is the communication of distributed applications on different nodes in different physical networks a relevant and important topic for fog05 ? The LinuxBridges on both edge nodes have to find themselves over e.g. VPN in order to support distributed communication, right? Another approach would be to let them communicate over a centralized controlplane. But there will be no contralized controlplane. And fog05 mentions just layer2-networking, but no overlay networking. Is distributed communication out of scope of fog05 ?
- except the plugin-net-linuxbridge, are there any other networks plugins that fog05 plans to support later?
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:
- Decentralized Orchestration Engine!
- K8s interoperability
- A new and shiny
fosctlutility 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/
Also, I cannot seem to get a connection to the internet from within a native application run through fog05 but I remember that a few months I was able to: has something changed?
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
I have several nodes deployed, with only one running zenohd/YAKS and fos_agent + some plugins. To be able to "see" other nodes, every node other than the one running zenohd/YAKS has the ylocator in the config files set to the first node running zenohd/YAKS.
Afaik, zenoh supports a discovery protocol using UDP multicast. In that case it would not be necessary to set the IP of the server running zenohd/YAKS , right? Can we use that in fog05, so that we don't have to change the ylocator on every node, but rather use the discovery protocol?
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.