Some questions about ACI push spec

[MabinGo]

I have implemented server to support rkt fetch&push that is following the ACI push spec,but I got some questions as below,
1.Is it necessary to validate ACI manifest in the server?
As ACI push spec said,when rkt push ACI to server,it would upload manifest,aci file and asc file,then as we know,there is also a manifest be compressed in aci file,so,
1) whether to validate these two manifests to ensure they are consistent in ther server?
2) whether to validate manifest content in the server just like rkt client do?

2.Is it necessary to handle with ACI dependencies in the server?
Currently, all ACI dependencies are analyzed and handled with in rkt client,then is there any plan to do some changes or optimizations about dependencies between server and client in the future?

Thanks

[alban]

/cc @dgonyeo

[cgonyeo]

So sorry about the delay on this, I was unable to do very much work over the past couple of weeks.

1. It is not necessary for the server to validate the ACI manifest. It's provided separately from the ACI so that the server can know things about the ACI without performing the expensive operation of decompressing and digging around in the ACI to get it.

   1. The server is welcome to validate the two manifests to ensure that they are consistent, but pulling the manifest out of the ACI is relatively expensive and this is not necessary.

   2. Again, the server is welcome to do this but it is not necessary.

2. Dependencies of an ACI might be intentionally hosted elsewhere. If an ACI has a dependency on "quay.io/coreos/alpine-sh", your registry shouldn't be hosting that dependency. If an ACI has dependencies, the onus is on the ACI creator to get them all into the proper registry. I'm not aware of any plans to do changes or optimizations about this in the future.

[MabinGo]

OK,Thanks.
BTW, is it necessary to clear this in ACI push spec?

[jonboulle]

@MabinGo perhaps you could submit a clarification?