add unit test for ValidateLayout function

[xiekeyang]

Signed-off-by: xiekeyang xiekeyang@huawei.com

[xiekeyang]

cc @wking @stevvooe @jonboulle @runcom

[wking]

I don't see anything about these in serialization.md. Can we remove them?

[xiekeyang]

removed, I adapt spec patten as serialization.md#image-json-description

[xiekeyang]

@wking
fixed, PTAL.
cc @runcom @jonboulle @stevvooe

[vbatts]

LGTM

[runcom]

are we merging this here? or does this need to be moved (and possibly merged) in image-tools?

[wking]

On Thu, Sep 15, 2016 at 07:07:52AM -0700, Antonio Murdaca wrote:

are we merging this here? or does this need to be moved (and
possibly merged) in image-tools?

It can be merged on the command line, just add an image-spec remote.
Or we can move it over if folks want a green button ;).

[runcom]

It can be merged on the command line, just add an image-spec remote.

and that's is awful to me given we have another repo and the code here is just for image-tools, do we want to cherry-pick/merge every outstanding PR from image-spec once merged here - anyway whatever

[wking]

On Thu, Sep 15, 2016 at 07:24:40AM -0700, Antonio Murdaca wrote:

It can be merged on the command line, just add an image-spec remote.

and that's is awful to me given we have another repo and the code
here is just for image-tools, do we want to cherry-pick/merge every
outstanding PR from image-spec once merged here - anyway whatever

You have to migrate them over somehow. image-tools has preserved the
full image-spec history, so there's no need to cherry-pick or rebase
(unless subsequent image-tools development leads to a conflict you
need to rebase around). Merging from the command line seems easier
than asking OPs to re-open new PRs, assuming you've already collected
the LGTMs (and the maintainer sets are currently the same, so
PullApprove will flag those appropriately).

[vbatts]

Are these sources just for image-tools though?

[runcom]

Are these sources just for image-tools though?

they're seem to be just used in cmd/ which has moved to image-tools (according to my ability with grep which may be bad - that's basically the reason I left image/ in image-tools)

[wking]

On Thu, Sep 15, 2016 at 07:35:12AM -0700, Antonio Murdaca wrote:

Are these sources just for image-tools though?

they're seem to be just used in cmd/ which has moved to
image-tools (according to my ability with grep which may be bad -
that's basically the reason I left image/ in image-tools)

And I expect image-tools to eventually expose this sort of thing in Go
libraries like runtime-tools has been doing (starting with
opencontainers/runtime-tools#130).

[vbatts]

i guess i meant, like runtime-spec has ./specs-go/ that are used by the runtime-tools and runc, I figured there would be a similar relationship here. I could likely be wrong though.

[runcom]

i guess i meant, like runtime-spec has ./specs-go/ that are used by the runtime-tools and runc, I figured there would be a similar relationship here. I could likely be wrong though.

@vbatts I left ./specs-go/ which contains the types here in image-spec indeed. image/ is just a set of functions used only in image-tools

[vbatts]

ah. my bad. you're right.

On Thu, Sep 15, 2016 at 10:47 AM, Antonio Murdaca notifications@github.com
wrote:

i guess i meant, like runtime-spec has ./specs-go/ that are used by the
runtime-tools and runc, I figured there would be a similar relationship
here. I could likely be wrong though.

@vbatts https://github.com/vbatts I left ./specs-go/ which contains the
types here in image-spec indeed. image/ is just a set of functions used
only in image-tools

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#310 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEF6bRxzKDJ-R2GaFIoDMB2yJyma2Upks5qqVqHgaJpZM4J8dfx
.

[wking]

On Thu, Sep 15, 2016 at 07:47:35AM -0700, Antonio Murdaca wrote:

i guess i meant, like runtime-spec has ./specs-go/ that are used
by the runtime-tools and runc, I figured there would be a similar
relationship here. I could likely be wrong though.

@vbatts I left ./specs-go/ which contains the types here in
image-spec indeed. image/ is just a set of functions used only in
image-tools

Yeah. +1 for leaving dead stuff (JSON Schema, Go types) in image-spec
but putting the moving parts (image/, cmd/) in image-tools.