| [iot-wg] Regarding to the contribution for Eclipse ioFog |
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:
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.
Control Plane – Controller:
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 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.
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.
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.
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,