implementation for storing native oci

[poonai]

I've been working on implementing native oci support in rkt.
now I have made changes for storing the oci blobs.
I would like to get early feedback on this 😄
#3378

[iaguis]

Sorry for the late response.

I've been reading up on this for some time and the current state of things is confusing and untangling it seems complicated.

Implementing native OCI support is not easy and will probably be a lot of work, I'll try to summarize my findings. Most of what I say is taken from proposals/oci.md.

Following devel/distribution-point.md, you need to implement an OCI distribution point. In oci.md, two remotes are described: oci and oci-layout, it's probably enough with the former for now.

Then we need to agree on the fetchers refactor proposal and implement it.

In parallel, we need to modify the store to allow storing OCI images: pick the relevant things from #3071 and figure out if what you did until now is valid or not.

After all this, having an OCI image, we need to convert the OCI image spec config to the App part of an appc pod manifest (discussed in #3039).

In conclusion, this will require quite a bit of work. If you're still up to the task I'll try to help you as much as I can, but I wanted to get a confirmation before spending more time on it.

Mentioning @lucab, @sgotti and @s-urbaniak to correct me (since I wasn't involved in any of the OCI efforts) if they still remember something about this.

[poonai]

@iaguis Thanks for helping me by aggregating all the resources. I'm really willing to take this. If possible, I would like to do as my GSoC project.
I have few doubts on implementing distribution point.
oci's and docker's remote are same, then how it'll differ each other.

for now, I'll start working on implementing oci-layout

[poonai]

@iaguis I have implemented oci-layout distribution. I have read the fetcher refactor proposal.
These are my knowledge of the proposal.
distribution handler will call the transport handler of the specific image(located in stage 0).
then it'll invoke transport plugin(it'll be separate binary). transport handler continues its logic based on the JSON output from the plugin binary(after fetching stage 1 invokation).
I have few doubts.
if the plugin binary directly interacts with the rkt store, why there is a need for plugin isolation? (image storing mechanism will be unique for rkt)
I may be wrong.

[iaguis]

This week has been very busy, I'll get back to you next week.

[murarisumit]

@Sch00lb0y still working on it ?

[kallisti5]

How goes it?