search

vsoch / django-oci

Open Containers distribution spec module for Django (under development)
https://vsoch.github.io/django-oci/
Other
15 stars 1 forks source link

Goals of projects #20

Open ad-m opened 3 years ago

ad-m commented 3 years ago

I have notice your project. I have started and shipped project of container registry as a service for cloud provider.

Can I ask for an explanation of the planned advantages of this project compared to other OCI registry implementations? What unique requirements does the project meet that are not fulfilled by the implementations available so far?

I have section https://github.com/vsoch/django-oci/blob/5ea7f83b6316316a8ddab4ecc7b94c6881d9a525/docs/_docs/introduction.md#goals in the documentation, but - based on my experience - I do not see a justification to make a completely new implementation, but at most to adopt existing solutions.

vsoch commented 3 years ago

I think someone already asked this on Twitter, and I'm happy to reference that and provide more context. First, the tweet:

https://twitter.com/vsoch/status/1316055385388642309

And to state again for the issue - basically, the research use case (where researchers that might want to create a custom registry are not developers, but are comfortable with Python and associated frameworks). The typical OCI registry that I see is in GoLang, with the exception of Quay which is quite substantial to set up. A research group should be empowered to deploy an OCI registry alongside their custom Django app, with many options for customization for their needs.

Next is the plugin aspect - this isn't a "registry in a box" (although I plan to make one for an example) but rather a plugin. It fits nicely alongside existing or custom Django projects that might warrant it. It comes with customization of storage backends, authentication, rate limits, content types, and pretty much anything that you might want. I am not discouraged that there are many other OCI registries out there - if I am a Django developer and I want OCI support it should be easy.

ad-m commented 3 years ago

A research group should be empowered to deploy an OCI registry alongside their custom Django app, with many options for customization for their needs.

I don't understand why Docker Registry should integrate directly with another application, especially in a container ecosystem that naturally supports smaller, specialized services.

The typical OCI registry that I see is in GoLang, with the exception of Quay which is quite substantial to set up.

I would like to highlight other OCI registry implementations that I have encountered:

It is based on your own notes. More than a year ago (before the specification was submitted to OCI), I conducted research in this area. I am currently unable to locate but encountered an open source implementation that grew out of managing fleet of golang registry into own registry implementation.

vsoch commented 3 years ago

Thanks for your thoughts! It’s ok if we disagree. Have a good day!

ad-m commented 3 years ago

Diversity is valuable. I express my opinion to support the project in this way. I will follow development. I am currently involved in other projects and I do not see the time available to increase my involvement in this project.

vsoch commented 3 years ago

Sounds good! No worries about getting involved, I am good :)

ad-m commented 3 years ago

To registries listed above I would like add https://github.com/sapcc/keppel written in Go.

pivstone commented 3 years ago

There are a few reasons to implement the registry by myself. First one is to understand the OCI registry specification (learning :p). But the more important one is to have the flexibility to add a custom feature like active cache public/popular image or custom auth and quota and etc.