It is recommended to separate the Sedna SDK into ianvs.

[tangming1996]

The existing Python SDK in Sedna was mainly created to facilitate developers in developing algorithms for the four paradigms in Sedna. However, with the emergence of ianvs, all algorithms have been migrated to ianvs for development. Thus, it no longer makes much sense to keep the SDK in Sedna. Moreover, the main function of Sedna is to orchestrate AI tasks in Kubernetes. In essence, it is a Kubernetes operator and does not involve specific AI business within containers. The SDK, on the other hand, is exactly about the in - container business and has no relation to Sedna's main functions.

In addition, the algorithm development in ianvs strongly depends on the SDK. For developers, they need to package the SDK in the Sedna repository and then move it to the ianvs repository for development. This is extremely inefficient and not conducive to project maintenance. Once there are issues to be fixed or new features to be added to the SDK, developers need to frequently switch between the two projects.

Furthermore, Sedna is developed in Go, while ianvs is in Python. As a Python package, it is more appropriate to move the SDK to ianvs.

[tangming1996]

After migrating the SDK to ianvs, we need to ensure that the model algorithms designed in ianvs can run seamlessly in Sedna.

[MooreZheng]

As we know, ianvs aims at benchmarking, thus ianvs is not designed to replace the Sedna SDK. It could help to incubate algorithms for sedna. But as mentioned, the way to migrate ianvs algorithms to sedna paradigm needs careful design. As for Sedna, it needs to ensure computing, storage, and networking for ianvs algorithms and that is why the four paradigms exist.

For other members, there is a previous discussion in https://github.com/kubeedge/sedna/issues/470, talking about "Sedna paradigms: beyond algorithm implementation" and "Sedna examples v.s. business solutions"

[tangming1996]

In addition, it is recommended that when releasing an ianvs version, the whl package of the Sedna-SDK should be automatically packaged and pushed to the official Python package management repository, which will facilitate users who want to use the Sedna-SDK for custom application development in the future.

[MooreZheng]

@FuryMartin @hsj576 @jaypume @Ratuchetp note significant issue of scope changing requirements for both Sedna and Ianvs.

From my point of view, there are the following concerns that need to be clarified to avoid the impact on existing production services and frequent code refactoring:

1. As K8S operator, what is the essential difference between Sedna and Kubeflow? The loss of standardization components could weaken Sedna which aims to develop edge based paradigms.
2. How to ensure the normal execution of new Sedna services, such as requirements to load or install ianvs (future Sedna SDK) algorithms when using a Sedna service?
3. How to support the normal execution of historical Sedna cases and examples, especially paradigms that match business cases?
4. How would the new codes be compatible with the previous six versions of Sedna core, especially management for paradigm process?

Ref: Sedna previous case studies in paper and blog.

• Project Epidemic Surveillance for Shenzhen government using Multi-edge Joint Inference.
• Project Pangu Mining Large Model for Shandong Energy Group using Cloud-edge Lifelong Learning.
• Project Satellite Remote Sensing for Hunan xxxxxxx Constellation using Cloud-Edge Joint Inference.
• ...

[MooreZheng]

As co-founder and maintainer of Ianvs and KubeEdge SIG AI, hereby I try to share the discussions in the past, which could be helpful for the community to catch up about what is going on.

Ianvs, as benchmarking tools, also incubate algorithms integrated into Sedna SDK. Before the ianvs project proposed on July 2022, KubeEdge SIG AI TLs have intensive discussion on three potential solutions, including the proposed one in this issue on April 2025.

1. [Current solution] Sedna SDK is placed in Sedna. Then Ianvs incubated algorithms are gradually merged into Sedna;
2. Sedna SDK is maintained independently. That is, Sedna, Sedna SDK, and ianvs become three independent repositories.
3. [This issue] Sedna SDK is placed in Ianvs. ianvs incubates algorithms on its own, and Sedna uses them when needed;

After discussion, Solution 1) was chosen on 2022 mainly for two reasons.

1. Reduce the management cost of the three repositories.
2. Urge ianvs algorithm developers to consider how algorithms can be used in real-world Sedna service.

We also welcome any advice or comment from KubeEdge TSC and maintainers @kevin-wangzefeng @fisherxu @Shelley-BaoYue

[tangming1996]

We also welcome @WillardHu, a maintainer of KubeEdge, to offer us suggestions.

[MooreZheng]

We also welcome @WillardHu, a maintainer of KubeEdge, to offer us suggestions.

As far as I am concerned, the current maintainer of KubeEdge is @Shelley-BaoYue

[MooreZheng]

We discussed the issue in the routine meeting on 3rd April 2025

1. Members exchange thoughts and concerns about this issue in detail.
2. We see the necessity to bridge Sedna and Ianvs. We all agree to find more possible methods to bring AI system developers (Golang users from Sedna) and AI algorithm developers (Python users from Ianvs) together in KubeEdge SIG AI.

As mentioned, regardless of which action is taken, related discussions can help everyone have a deeper understanding of the goals and positions of each repository, which is very meaningful for KubeEdge SIG AI.