Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

oci-image-tool: more verbose output #22

Open
6 tasks
philips opened this issue Sep 21, 2016 · 6 comments
Open
6 tasks

oci-image-tool: more verbose output #22

philips opened this issue Sep 21, 2016 · 6 comments

Comments

@philips
Copy link
Contributor

philips commented Sep 21, 2016

From @s-urbaniak on August 30, 2016 12:55

As per https://docs.google.com/document/d/1bsi9JCnmOMSZCDh3VmDCO1m17w1aNexX09naomcpUOs/edit the oci-image-tool should have more verbose output, more concretely:

Print ...

  • the digests of objects
  • the version of the spec tested against
  • canonical mimetypes and alternative
  • the version of the validator code
  • a list of tests that were ran
  • a list of errors

I did implement the last point ("a list of errors") actually already, so I am wondering what additional requirements are needed here.

/cc @philips

Copied from original issue: opencontainers/image-spec#222

@philips
Copy link
Contributor Author

philips commented Sep 21, 2016

From @runcom on August 30, 2016 13:50

@s-urbaniak If there's anything I can help with this please let me know

@philips
Copy link
Contributor Author

philips commented Sep 21, 2016

From @s-urbaniak on August 30, 2016 14:51

@runcom thanks for the help! Sure, just go ahead, I'll try tackle each of those in parallel with other rkt work. Just let me know if you want to tackle all of them or just a subset. Seem like low-hanging fruits to me.

@philips
Copy link
Contributor Author

philips commented Sep 21, 2016

From @coolljt0725 on August 31, 2016 1:57

@runcom If you just tackle a subnet of them, I'd like to help with the rest

@philips
Copy link
Contributor Author

philips commented Sep 21, 2016

From @xiekeyang on August 31, 2016 2:11

@s-urbaniak If it need to be done based on #159 ?
It refactor the image tool completely. If we did before it is merged, we may be meet a big conflict.

@philips
Copy link
Contributor Author

philips commented Sep 21, 2016

From @wking on August 31, 2016 4:21

On Tue, Aug 30, 2016 at 07:11:01PM -0700, xiekeyang wrote:

@s-urbaniak If it need to be done based on #159 ?
It refactor the image tool completely. If we did before it is
merged, we may be meet a big conflict.

I'm all for avoiding conflicts, but #159 tries to stay away from the
existing image-validation logic. So I expect you can wade into these issues without butting heads with #159.

My long-term plan was to land #159 and then rewrite the
validation/unpacking logic to use callback registries. Something
like:

type Validator func(ctx context.Context, engine cas.Engine, ref specs.Descriptor, recursive bool) (errors []string)

var Validaters map[string]Validator {
"application/vnd.oci.descriptor.v1+json": ValidateDescriptor,
"application/vnd.oci.image.manifest.v1+json": ValidateManifest,
"application/vnd.oci.image.manifest.list.v1+json": ValidateManifestList,

}

But I don't have any work in progress on that front, so there won't be
any conflicts if validation shifts around in the meantime ;).

@glestaris
Copy link
Contributor

Is this related to #14? Should we first introduce a logging framework and then add logs for the above cases?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants