Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [iot-wg] Regarding to the contribution for Eclipse ioFog
Hi Emirhan.

Thank you for sharing this. You implemented many interesting improvements. This is exciting!

For those of you who lack context about this, the development of Eclipse ioFog stalled after the project's main supporter, Edgeworx, closed its doors earlier this year. Eclipse Foundation processes enable the EMO to appoint new leads and committers to abandoned projects, which is vastly preferable to archiving them. 

So, my call to the rest of the community is this: if you are interested in getting involved in ioFog's revival, now is the time to make yourself known. Please get in touch with me by email or on the Eclipse IoT Slack as soon as possible.

Best Regards,

Frédéric DESBIENS

Senior Manager — Embedded and IoT | Eclipse Foundation

Open Community Experience 2024

Join us in Mainz, Germany! October 22-24, 2024




On Fri, 30 Aug 2024 at 11:24, Emirhan Durmuş via iot-wg <iot-wg@xxxxxxxxxxx> wrote:

Dear Eclipse IoT Working Group and ioFog Dev Community,

 

I hope this message finds you well. My name is Emirhan, and I am the founder of Datasance, a seed-stage startup based in Istanbul, Turkey. Our focus is on providing an enterprise open-source distributed edge computing platform, and we've been building on top of Eclipse ioFog.

As we are not official contributors, and considering that the ioFog repository hasn't been maintained for a while, I would like to introduce our work and discuss how we might contribute these improvements to the official repository.

We have focused primarily on enhancing the Kubernetes Control Plane, which we believe is essential for production environments. Below is a summary of our improvements:

Agent:

Docker-Java SDK and API Update: The existing Docker-Java SDK and Docker API were outdated, so we have upgraded them to the latest versions.

WebAssembly Containers Support: We've added runtime and platform definitions to the applications/microservices struct, allowing deployment of WebAssembly containers on Edge devices. This feature is currently in beta, and we plan to add runwasi container shims, especially containerd-WasmEdge shim installation scripts, in the Agent's initial installation process.

GPU Device Mapping: We’ve introduced CdiDevices definitions in the applications/microservices struct to enable CDI supported GPU device mapping to container runtimes.

User Permissions: Added the runAsUser option to allow users to specify the user under which their containers should run.

image.png


Control Plane – Controller:

image.png

 IAM Enhancements: The current data model in the ioFog controller assigns all resources to a single user. To make IAM more enterprise-ready with multi-user support, we removed the internal user authentication mechanism, integrated Keycloak, and added role-based access control for each controller endpoint.

Database Support: We replaced the existing SQLite database with support for MySQL and PostgreSQL. Database migrations and seeder scripts are executed via the operator before the controllers are deployed.

Security and Package Updates: We addressed numerous vulnerabilities by upgrading the existing packages, given that the controller had not been updated in some time.

image.png


Image Management: The control plane CRD already defined with pullSecret, but it could only attach to the controller service account if deployed via kubectl. We modified the image struct of the platform CLI tool, allowing pullSecret to be attached to each service account within the control plane resources.

image.png

Service Annotations: We added annotations in the services struct, enabling users to select which IP pool to assign to cluster services when the service type is LoadBalancer.

image.png

Ingress Management: We added an ingress struct for the controller. When the service type is ClusterIP, users need to define ingress, and the SSL secret is mapped to the controller, which then starts with HTTPS. If the Kubernetes cluster is properly configured with cert-manager and an ingress controller, by defining the annotations of the controller ingress, the secret can be automatically generated and attached to the controller.

Router and Proxy:

  • Skupper Router Integration: Since the Apache community is no longer maintaining the qpid-dispatch router after version 1.19 and the Skupper community has forked it as Skupper Router, we have switched to Skupper Router version 2.6.
  • Security Enhancements: The existing security mechanisms only secures outgoing connections of the default-router deployed on the control plane via auto-created self-signed certificates. To secure both incoming and outgoing connections and enable SASL, it was not possible to manage router and proxy microservices running on the edge side due to limitations in how they were created and attached to the agent. We have modified this logic by auto-creating router and proxy microservices within a system application for each agent, creating system application endpoints on the controller side. This allows users to easily modify these features via the viewer.

image.png

Users can now update their microservices and applications by updating their YAML configurations in the viewer.
image.png
image.png

I would greatly appreciate the opportunity to discuss how we can collaborate and contribute these enhancements to the Eclipse ioFog community. Looking forward to your feedback and guidance on the next steps.

Regards,

-----------

Emirhan Durmuş
Co-founder
Mobile: +90 543 629 2920
Datasance - Web - LinkedIn


 Open for Intelligence Everywhere





_______________________________________________
iot-wg mailing list
iot-wg@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/iot-wg

Back to the top