Skip to content

Conversation

@wking
Copy link
Contributor

@wking wking commented Nov 15, 2016

Also add --host-specific checks to SetPlatformOS and SetPlatformArch. The SetPlatformArch check is currently just a warning (details in eda1ac7, validate: With --host-specific, compare config platform vs. runtime, 2016-08-16) but I've added an error to its API so callers will be ready when we do actually raise errors (e.g. for --arch arm on an amd64 box).

Also add IsSet checks to --os and --arch so we don't clobber their template values. Before this commit on my amd64 Linux box:

$ echo '{"platform": {"os": "windows", "arch": "386"}}' >template.json
$ ocitools generate --template template.json | jq .platform
{
  "os": "linux",
  "arch": "amd64"
}

After this commit:

$ ocitools generate --template template.json | jq .platform
{
  "os": "windows",
  "arch": "386"
}

This commit was previously part of #194, but I've pulled it out into its own PR because @Mashimiao isn't sold yet ;).

This is a bit aggressive.  For example, maybe a Linux kernel was
compiled with CONFIG_64BIT, CONFIG_X86, and CONFIG_X86_X32.  Your
ocitools build may be 386 and validating an amd64 image (or vice
versa) and both would run fine.  I'm not sure x32 is supported by Go,
but you could have and x32 container if somebody submits it to the OCI
specs as an extention arch.  So I'd rather have an arch mismatch be a
warning than a fatal error.

But in most cases, you'll want the arch to match (e.g. no arm configs
if ocitools is amd64), so I don't want to ignore the missmatch
completely.  In the absence of warning-support, an overly strict check
seems safer than an overly lax check, because the caller can always
read the error messages and decide if they care ;).

Signed-off-by: W. Trevor King <[email protected]>
Don't fill in a bunch of Linux stuff if runtime.GOOS isn't Linux ;).
We don't have sensible defaults for other OSes yet, so error out in
those cases.

Signed-off-by: W. Trevor King <[email protected]>
Also add --host-specific checks to SetPlatformOS and SetPlatformArch.
The SetPlatformArch check is currently just a warning (details in
eda1ac7, validate: With --host-specific, compare config platform
vs. runtime, 2016-08-16) but I've added an error to its API so callers
will be ready when we do actually raise errors (e.g. for '--arch arm'
on an amd64 box).

Also add IsSet checks to --os and --arch so we don't clobber their
template values.  Before this commit on my amd64 Linux box:

  $ echo '{"platform": {"os": "windows", "arch": "386"}}' >template.json
  $ ocitools generate --template template.json | jq .platform
  {
    "os": "linux",
    "arch": "amd64"
  }

After this commit:

  $ ocitools generate --template template.json | jq .platform
  {
    "os": "windows",
    "arch": "386"
  }

Signed-off-by: W. Trevor King <[email protected]>
@wking wking force-pushed the validate-host-platform-2 branch from 1ae6388 to fedbf90 Compare November 15, 2016 04:39
@wking wking mentioned this pull request Nov 15, 2016
// OS (which defaults to runtime.GOOS).
func New(os *string) (generator Generator, err error) {
var goos string
goos = runtime.GOOS
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

goos := runtime.GOOS

@mrunalp
Copy link
Contributor

mrunalp commented Nov 15, 2016

make failed in the build.

Action: func(context *cli.Context) error {
// Start from the default template.
specgen := generate.New()
var osPointer *string
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe rename the variable to specOs? I don't like that we have Pointer in the name. Go doesn't recommend hungarian notation.

@wking
Copy link
Contributor Author

wking commented Nov 15, 2016

On Tue, Nov 15, 2016 at 11:25:10AM -0800, Mrunal Patel wrote:

make failed in the build.

This PR is for the tip commit from #194. Don't bother reviewing it
until #194 lands.

@liangchenye
Copy link
Member

Since platform is removed, close this PR.

@liangchenye liangchenye closed this Jul 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants