Closed gorkem closed 1 month ago
Wasn't Harbor first to adopt this proposal?
@gorkem how do you all make decisions? Looking at the OCI specs like https://github.com/opencontainers/image-spec/ and https://github.com/opencontainers/runtime-spec there seems to be a good mechanism for consensus making and taking decisions.. so was wondering how you all do it right now? (and have you thought about what it may look like in the future?)
One more.. Looks like docker folks have something in the same space possibly? are you all in touch? (is there another spec that they may have that will need to be reconciled?)
IMO: with upcoming CRI-O changes here you don't really need new spec, can use OCI and some extra annotations to get same level of functionality.
Hopefully containerd
folks will pick this up also.
@dims So far, we have been running the specification process like any other open-source project. Pull-requests to introduce the changes, which are discussed on the bi-weekly calls and a consensus was reached. This method so far worked but I do not think we had a case when it was challenging to reach consensus. I would rather not create a more formal method until we see that we need one.
Assuming this is the same or related to model-distribution, we were able to connect with them. We all agreed that there are enough similarities between the spec, docker implementations, and KitOps. Docker folks will hopefully participate more actively and propose the changes that will help them align better.
can use OCI and some extra annotations to get same level of functionality.
@s3rj1k The document that explains that some extra annotations
so that others can implement and interoperate the same would be the "spec" :) There are already multiple flavors of OCI artifacts that deal with AI/ML, we aim to introduce a light specification to avoid the wasted efforts and foster the innovation, not only for k8s runtimes but all kinds of tooling.
some extra annotations
are OCI well-known annotations, like close to 95% of needed functionality is already there without a need to build new spec from scratch and use new tooling.
Taking this as base and extending ML spec with additional ML specific annotations would be preferable to inventing new spec from scratch. https://github.com/opencontainers/image-spec/blob/main/specs-go/v1/annotations.go
One more.. Looks like docker folks have something in the same space possibly? are you all in touch? (is there another spec that they may have that will need to be reconciled?)
Hi @dims,
We have been in touch with them since the first day the model-distribution project was published. Please refer to https://github.com/docker/model-distribution/issues/53. Some of the folks (@sabre1041, @gorkem ) of the model-spec had a conversation with @ekcasey at Kubecon. Docker folks have agreed on collaborating and potentially converging on a shared specification and tooling.
We also have a dedicated CNCF channel, #model-spec-discussion, for discussing the consensus. Docker folks like @ekcasey are involved. Feel free to join if you're interested.
Harbor has adopted this spec in the latest release. FYI: https://github.com/goharbor/harbor/releases/tag/v2.13.0
FYI @caniszczyk has kindly offered the modelpack GitHub organization. We intend to use that organization as we move to CNCF.
/vote
@linsun has called for a vote on [Sandbox] ModelPack
(#358).
The members of the following teams have binding votes: | Team |
---|---|
@cncf/cncf-toc-voters |
Non-binding votes are also appreciated as a sign of support!
You can cast your vote by reacting to this
comment. The following reactions are supported:
In favor | Against | Abstain |
---|---|---|
๐ | ๐ | ๐ |
Please note that voting for multiple options is not allowed and those votes won't be counted.
The vote will be open for 2months 30days 2h 52m 48s
. It will pass if at least 66%
of the users with binding votes vote In favor ๐
. Once it's closed, results will be published here as a new comment.
/check-vote
So far 36.36%
of the users with binding vote are in favor and 9.09%
are against (passing threshold: 66%
).
In favor | Against | Abstain | Not voted |
---|---|---|---|
4 | 1 | 1 | 5 |
User | Vote | Timestamp |
---|---|---|
dims | In favor | 2025-05-13 19:38:51.0 +00:00:00 |
linsun | In favor | 2025-05-13 15:36:09.0 +00:00:00 |
kevin-wangzefeng | In favor | 2025-05-14 13:22:24.0 +00:00:00 |
rochaporto | In favor | 2025-05-15 14:26:48.0 +00:00:00 |
chadbeaudin | Abstain | 2025-05-15 16:45:31.0 +00:00:00 |
angellk | Against | 2025-05-13 18:06:20.0 +00:00:00 |
@chira001 | Pending | |
@kfaseela | Pending | |
@TheFoxAtWork | Pending | |
@jeremyrickard | Pending | |
@kgamanji | Pending |
/check-vote
Votes can only be checked once a day.
/check-vote
So far 45.45%
of the users with binding vote are in favor and 9.09%
are against (passing threshold: 66%
).
In favor | Against | Abstain | Not voted |
---|---|---|---|
5 | 1 | 1 | 4 |
User | Vote | Timestamp |
---|---|---|
kfaseela | In favor | 2025-05-16 10:28:50.0 +00:00:00 |
angellk | Against | 2025-05-13 18:06:20.0 +00:00:00 |
linsun | In favor | 2025-05-13 15:36:09.0 +00:00:00 |
kevin-wangzefeng | In favor | 2025-05-14 13:22:24.0 +00:00:00 |
rochaporto | In favor | 2025-05-15 14:26:48.0 +00:00:00 |
chadbeaudin | Abstain | 2025-05-15 16:45:31.0 +00:00:00 |
dims | In favor | 2025-05-13 19:38:51.0 +00:00:00 |
@chira001 | Pending | |
@TheFoxAtWork | Pending | |
@jeremyrickard | Pending | |
@kgamanji | Pending |
Votes can only be checked once a day.
/check-vote
So far 54.55%
of the users with binding vote are in favor and 18.18%
are against (passing threshold: 66%
).
In favor | Against | Abstain | Not voted |
---|---|---|---|
6 | 2 | 1 | 2 |
User | Vote | Timestamp |
---|---|---|
angellk | Against | 2025-05-13 18:06:20.0 +00:00:00 |
linsun | In favor | 2025-05-13 15:36:09.0 +00:00:00 |
kfaseela | In favor | 2025-05-16 10:28:50.0 +00:00:00 |
chira001 | In favor | 2025-05-21 11:10:49.0 +00:00:00 |
dims | In favor | 2025-05-13 19:38:51.0 +00:00:00 |
chadbeaudin | Abstain | 2025-05-15 16:45:31.0 +00:00:00 |
kevin-wangzefeng | In favor | 2025-05-14 13:22:24.0 +00:00:00 |
jeremyrickard | Against | 2025-05-20 20:59:21.0 +00:00:00 |
rochaporto | In favor | 2025-05-15 14:26:48.0 +00:00:00 |
@TheFoxAtWork | Pending | |
@kgamanji | Pending |
Just to comment on why this isn't part of the OCI since it has come up in some discussions: https://opencontainers.org
The OCI can be thought of a trailing spec body, it doesn't do experimentation and really only adopts things that have been baked for awhile and in production (docker registry -> distribution spec, docker image -> image spec etc). I could see a future where OCI adopts the output of ModelPack but there is too much experimentation in this space to have it formalized in OCI at this point. I could see a future where this work influences the OCI image/distribution specs but not right now.
Just to comment on why this isn't part of the OCI since it has come up in some discussions: https://opencontainers.org
The OCI can be thought of a trailing spec body, it doesn't do experimentation and really only adopts things that have been baked for awhile and in production (docker registry -> distribution spec, docker image -> image spec etc). I could see a future where OCI adopts the output of ModelPack but there is too much experimentation in this space to have it formalized in OCI at this point. I could see a future where this work influences the OCI image/distribution specs but not right now.
OCI could have had experimental extensions approach
I agree that OCI can explore experimental extensions.
Also, I'd love to see this project apply as a subproject in the new TAG structure if this vote does not pass.
/check-vote
So far 54.55%
of the users with binding vote are in favor and 18.18%
are against (passing threshold: 66%
).
In favor | Against | Abstain | Not voted |
---|---|---|---|
6 | 2 | 1 | 2 |
User | Vote | Timestamp |
---|---|---|
dims | In favor | 2025-05-13 19:38:51.0 +00:00:00 |
kfaseela | In favor | 2025-05-16 10:28:50.0 +00:00:00 |
rochaporto | In favor | 2025-05-15 14:26:48.0 +00:00:00 |
angellk | Against | 2025-05-13 18:06:20.0 +00:00:00 |
jeremyrickard | Against | 2025-05-20 20:59:21.0 +00:00:00 |
linsun | In favor | 2025-05-13 15:36:09.0 +00:00:00 |
chira001 | In favor | 2025-05-21 11:10:49.0 +00:00:00 |
chadbeaudin | Abstain | 2025-05-15 16:45:31.0 +00:00:00 |
kevin-wangzefeng | In favor | 2025-05-14 13:22:24.0 +00:00:00 |
@TheFoxAtWork | Pending | |
@kgamanji | Pending |
Votes can only be checked once a day.
/check-vote
So far 54.55%
of the users with binding vote are in favor and 18.18%
are against (passing threshold: 66%
).
In favor | Against | Abstain | Not voted |
---|---|---|---|
6 | 2 | 1 | 2 |
User | Vote | Timestamp |
---|---|---|
linsun | In favor | 2025-05-13 15:36:09.0 +00:00:00 |
rochaporto | In favor | 2025-05-15 14:26:48.0 +00:00:00 |
chadbeaudin | Abstain | 2025-05-15 16:45:31.0 +00:00:00 |
kfaseela | In favor | 2025-05-16 10:28:50.0 +00:00:00 |
jeremyrickard | Against | 2025-05-20 20:59:21.0 +00:00:00 |
dims | In favor | 2025-05-13 19:38:51.0 +00:00:00 |
chira001 | In favor | 2025-05-21 11:10:49.0 +00:00:00 |
angellk | Against | 2025-05-13 18:06:20.0 +00:00:00 |
kevin-wangzefeng | In favor | 2025-05-14 13:22:24.0 +00:00:00 |
@TheFoxAtWork | Pending | |
@kgamanji | Pending |
/check-vote
So far 54.55%
of the users with binding vote are in favor and 18.18%
are against (passing threshold: 66%
).
In favor | Against | Abstain | Not voted |
---|---|---|---|
6 | 2 | 1 | 2 |
User | Vote | Timestamp |
---|---|---|
chadbeaudin | Abstain | 2025-05-15 16:45:31.0 +00:00:00 |
kfaseela | In favor | 2025-05-16 10:28:50.0 +00:00:00 |
linsun | In favor | 2025-05-13 15:36:09.0 +00:00:00 |
angellk | Against | 2025-05-13 18:06:20.0 +00:00:00 |
chira001 | In favor | 2025-05-21 11:10:49.0 +00:00:00 |
kevin-wangzefeng | In favor | 2025-05-14 13:22:24.0 +00:00:00 |
rochaporto | In favor | 2025-05-15 14:26:48.0 +00:00:00 |
jeremyrickard | Against | 2025-05-20 20:59:21.0 +00:00:00 |
dims | In favor | 2025-05-13 19:38:51.0 +00:00:00 |
@TheFoxAtWork | Pending | |
@kgamanji | Pending |
@Jwilliamsr You don't need to check the votes every day until you see a vote that exceeds 15: ๐ https://github.com/cncf/sandbox/issues/358#issuecomment-2877003640 This is the current status:
We are still waiting for the last two voters to make their decisions. ๐ช
Note: I have changed my vote to "In favor" now that the TOC will provide additional guidance for specification projects.
/check-vote
So far 63.64%
of the users with binding vote are in favor and 9.09%
are against (passing threshold: 66%
).
In favor | Against | Abstain | Not voted |
---|---|---|---|
7 | 1 | 1 | 2 |
User | Vote | Timestamp |
---|---|---|
linsun | In favor | 2025-05-13 15:36:09.0 +00:00:00 |
dims | In favor | 2025-05-13 19:38:51.0 +00:00:00 |
chira001 | In favor | 2025-05-21 11:10:49.0 +00:00:00 |
angellk | In favor | 2025-06-04 2:06:16.0 +00:00:00 |
rochaporto | In favor | 2025-05-15 14:26:48.0 +00:00:00 |
kevin-wangzefeng | In favor | 2025-05-14 13:22:24.0 +00:00:00 |
kfaseela | In favor | 2025-05-16 10:28:50.0 +00:00:00 |
chadbeaudin | Abstain | 2025-05-15 16:45:31.0 +00:00:00 |
jeremyrickard | Against | 2025-05-20 20:59:21.0 +00:00:00 |
@TheFoxAtWork | Pending | |
@kgamanji | Pending |
Thanks @tarilabs for re-list the current snapshot (after angellk's re-vote)!
a reminder for future folks who want to check the vote status: no need to check the votes until you see that in favor vote exceeds 16: ๐
current status:
quick navigation link to the vote box comment: https://github.com/cncf/sandbox/issues/358#issuecomment-2877003640 quick navigation link to the latest vote details: https://github.com/cncf/sandbox/issues/358#issuecomment-2938921952
/gitvote
/check-vote
Votes can only be checked once a day.
/check-vote
So far 81.82%
of the users with binding vote are in favor and 0.00%
are against (passing threshold: 66%
).
In favor | Against | Abstain | Not voted |
---|---|---|---|
9 | 0 | 1 | 1 |
User | Vote | Timestamp |
---|---|---|
chadbeaudin | Abstain | 2025-05-15 16:45:31.0 +00:00:00 |
angellk | In favor | 2025-06-04 2:06:16.0 +00:00:00 |
kgamanji | In favor | 2025-06-04 15:06:36.0 +00:00:00 |
linsun | In favor | 2025-05-13 15:36:09.0 +00:00:00 |
kfaseela | In favor | 2025-05-16 10:28:50.0 +00:00:00 |
kevin-wangzefeng | In favor | 2025-05-14 13:22:24.0 +00:00:00 |
dims | In favor | 2025-05-13 19:38:51.0 +00:00:00 |
rochaporto | In favor | 2025-05-15 14:26:48.0 +00:00:00 |
chira001 | In favor | 2025-05-21 11:10:49.0 +00:00:00 |
jeremyrickard | In favor | 2025-06-04 18:38:59.0 +00:00:00 |
@TheFoxAtWork | Pending |
Congratulations ModelPack maintainers! For next steps, the CNCF Project team will be opening an onboarding issue to onboard the project to the CNCF. cc: @krook
The vote passed! ๐
81.82%
of the users with binding vote were in favor and 0.00%
were against (passing threshold: 66%
).
In favor | Against | Abstain | Not voted |
---|---|---|---|
9 | 0 | 1 | 1 |
User | Vote | Timestamp |
---|---|---|
@jeremyrickard | In favor | 2025-06-04 18:38:59.0 +00:00:00 |
@kfaseela | In favor | 2025-05-16 10:28:50.0 +00:00:00 |
@angellk | In favor | 2025-06-04 2:06:16.0 +00:00:00 |
@rochaporto | In favor | 2025-05-15 14:26:48.0 +00:00:00 |
@chira001 | In favor | 2025-05-21 11:10:49.0 +00:00:00 |
@linsun | In favor | 2025-05-13 15:36:09.0 +00:00:00 |
@chadbeaudin | Abstain | 2025-05-15 16:45:31.0 +00:00:00 |
@dims | In favor | 2025-05-13 19:38:51.0 +00:00:00 |
@kevin-wangzefeng | In favor | 2025-05-14 13:22:24.0 +00:00:00 |
@kgamanji | In favor | 2025-06-04 15:06:36.0 +00:00:00 |
Congrats! the vote has passed ๐ With that I've opened an issue to begin project onboarding. https://github.com/cncf/sandbox/issues/385
With that, I'm going to go ahead and close this out. We can continue further discussion in the onboarding issue๐
Application contact emails
gorkem@jozu.com bergwolf@antgroup.com xudwang@paypal.com winters.zc@antgroup.com baimo.qwb@antgroup.com suhan.zcy@antgroup.com ablock@redhat.com
Project summary
The project establishes open standards for packaging, distributing and running AI artifacts in the cloud-native environment.
Project description
Artificial Intelligence (AI) and Machine Learning (ML) have become integral components of modern cloud-native application architectures. Despite this, the AI/ML domain remains fragmented due to inconsistent methods of packaging and distributing AI artifacts, which include models, datasets, codebases, and parameters. Open standards are essential for fostering cohesive, interoperable, and scalable ecosystems.
This project aims to define a vendor-neutral, open standard for packaging, distributing, and executing AI artifacts. It will also develop the documentation and libraries necessary to promote widespread adoption.
Org repo URL (provide if all repos under the org are in scope of the application)
N/A
Project repo URL in scope of application
https://github.com/CloudNativeAI/model-spec
Additional repos in scope of the application
No response
Website URL
https://github.com/CloudNativeAI/model-spec
Roadmap
https://github.com/CloudNativeAI/model-spec/blob/2f39436c52f6f853140693bda06b03fc106015a2/ROADMAP.md
Roadmap context
The projectโs overarching goal is to establish a standardized, cloud-native ecosystem for AI model packaging, distribution, and runtime integration. We are in phase 1 where the focus is on defining a model format, and seeking alignment with cloud-native standards.
Contributing guide
https://github.com/CloudNativeAI/model-spec/blob/2f39436c52f6f853140693bda06b03fc106015a2/CONTRIBUTING.md
Code of Conduct (CoC)
https://github.com/CloudNativeAI/model-spec/blob/2f39436c52f6f853140693bda06b03fc106015a2/code-of-conduct.md
Adopters
No response
Contributing or sponsoring org
No response
Maintainers file
https://github.com/CloudNativeAI/model-spec/pull/45
IP policy
Will the project require a license exception?
N/A
Trademark and accounts
Standard or specification?
The primary goal of this project is to establish an open standard for packaging, distributing, and executing AI artifacts, aligned with the OCI standard.
Why CNCF?
This standard builds upon the Open Container Initiative (OCI), which is foundational to numerous CNCF projects. However, while OCI excels in supporting stable, slower-moving standards, the rapidly evolving nature of this AI/ML cloud native standard requires a more dynamic environment. Given OCIโs significance within CNCF and our shared mission to advance open, cloud-native technologies, CNCF represents the most suitable foundation at this stage. Over time, as the standard matures and stabilizes, transitioning it fully into OCI might become appropriate, but currently, CNCFโs agility is essential for its rapid development and innovation.
Benefit to the landscape
Currently, the CNCF ecosystem lacks a unified standard for packaging and versioning AI/ML artifacts. This gap creates deployment challenges for organizations adopting cloud-native AI/ML workloads, resulting in fragmentation and operational inefficiencies. The proposed standard addresses this issue directly, enhancing interoperability and efficiency.
Cloud native 'fit'
The proposed standard integrates seamlessly into the CNCF landscape by standardizing the packaging and distribution of AI/ML artifacts via OCI registries. It complements and interacts effectively with established CNCF projects such as Kubernetes, CRI-O, containerd, KServe, Notary, and others.
Cloud native 'integration'
This standard benefits OCI registries such as Harbor, Kubernetes, containerd, and CRI-O, facilitating streamlined training and inference processes for AI/ML workloads.
Cloud native overlap
Similar projects
ONNX KitOps SkyPilot
Landscape
No, it is not listed
Business Product or Service to Project separation
Not related to any product, service or company.
Project "Domain Technical Review"
Not yet
CNCF contacts
Chris Aniszczyk
Additional information
No response