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

Better support for testing with different storage drivers #162

Closed
wants to merge 3 commits into from

Conversation

nalind
Copy link
Member

@nalind nalind commented Jun 26, 2017

This change updates the test helper macros to pass the right flags to tools to use the storage driver named in $STORAGE_DRIVER instead of vfs, if the variable is set when the tests are run. It adds debug logging support to the imgtype test helper, and ensures that it actually shuts down storage, even when it exits with errors.

nalind added 3 commits June 26, 2017 10:54
Make the tests use the storage driver named in $STORAGE_DRIVER, if one's
set, instead of hard-coding the default of "vfs".

Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
In the imgtype test helper, add a -debug flag, correctly handle things
on the off chance that we need to call a reexec handler, and read the
manifest using the Manifest() method of an image that we're already
opening, rather than creating a source image just so that we can call
its GetManifest() method.

Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Logging at Fatal calls os.Exit(), which keeps us from shutting down
storage properly, which prevents test cleanup from succeeding.

Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
@rhatdan
Copy link
Member

rhatdan commented Jun 26, 2017

LGTM

@rhatdan
Copy link
Member

rhatdan commented Jun 26, 2017

@TomSweeneyRedHat PTAL

logrus.Fatalf("error parsing reference %q: %v", image, err)
}

src, err := ref.NewImageSource(systemContext, []string{expectedManifestType})
Copy link
Member

Choose a reason for hiding this comment

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

Is this test/check no longer needed? I don't see it in the new version.

Copy link
Member Author

Choose a reason for hiding this comment

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

The code for handling an error result from ParseStoreReference? The diff is assuming one if err != nil is equivalent to another, but we should still be handling that case in the proposed version.

Copy link
Member

Choose a reason for hiding this comment

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

I wasn't referring to the Transport.ParseStoreReference(), but the call to ref.NewImageSource on line 85 in the old code. I didn't see that elsewhere.

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah, yes. Realized that we can grab the manifest contents from the Image object, so there's no need to create an ImageSource object to read it when we already have an Image object.

Copy link
Member

@TomSweeneyRedHat TomSweeneyRedHat left a comment

Choose a reason for hiding this comment

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

Just one question. If it needs adjustment, I'm fine with submit and separate PR. LGTM otherwise.

@rhatdan
Copy link
Member

rhatdan commented Jun 27, 2017

@TomSweeneyRedHat Can we merge?

@rhatdan
Copy link
Member

rhatdan commented Jun 28, 2017

@rh-atomic-bot r+ ccfde8a

@rh-atomic-bot
Copy link
Collaborator

⌛ Testing commit ccfde8a with merge 7225365...

rh-atomic-bot pushed a commit that referenced this pull request Jun 28, 2017
In the imgtype test helper, add a -debug flag, correctly handle things
on the off chance that we need to call a reexec handler, and read the
manifest using the Manifest() method of an image that we're already
opening, rather than creating a source image just so that we can call
its GetManifest() method.

Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>

Closes: #162
Approved by: rhatdan
rh-atomic-bot pushed a commit that referenced this pull request Jun 28, 2017
Logging at Fatal calls os.Exit(), which keeps us from shutting down
storage properly, which prevents test cleanup from succeeding.

Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>

Closes: #162
Approved by: rhatdan
@rh-atomic-bot
Copy link
Collaborator

☀️ Test successful - status-redhatci
Approved by: rhatdan
Pushing 7225365 to master...

nalind pushed a commit that referenced this pull request Apr 2, 2018
Signed-off-by: TomSweeneyRedHat <tsweeney@redhat.com>

Closes: #162
Approved by: rhatdan
kolyshkin added a commit to kolyshkin/buildah that referenced this pull request May 16, 2020
This subtle bug keeps lurking in because error checking for `Mkdir()`
and `MkdirAll()` is slightly different wrt `EEXIST`/`IsExist`:

 - for `Mkdir()`, `IsExist` error should (usually) be ignored
   (unless you want to make sure directory was not there before)
   as it means "the destination directory was already there";

 - for `MkdirAll()`, `IsExist` error should NEVER be ignored.

This commit removes ignoring the IsExist error, as it should not
be ignored.

For more details, a quote from opencontainers/runc PR containers#162:

-quote-

TL;DR: check for IsExist(err) after a failed MkdirAll() is both
redundant and wrong -- so two reasons to remove it.

Quoting MkdirAll documentation:

> MkdirAll creates a directory named path, along with any necessary
> parents, and returns nil, or else returns an error. If path
> is already a directory, MkdirAll does nothing and returns nil.

This means two things:

1. If a directory to be created already exists, no error is
returned.

2. If the error returned is IsExist (EEXIST), it means there exists
a non-directory with the same name as MkdirAll need to use for
directory. Example: we want to MkdirAll("a/b"), but file "a"
(or "a/b") already exists, so MkdirAll fails.

The above is a theory, based on quoted documentation and my UNIX
knowledge.

3. In practice, though, current MkdirAll implementation [1] returns
ENOTDIR in most of cases described in containers#2, with the exception when
there is a race between MkdirAll and someone else creating the
last component of MkdirAll argument as a file. In this very case
MkdirAll() will indeed return EEXIST.

Because of containers#1, IsExist check after MkdirAll is not needed.

Because of containers#2 and containers#3, ignoring IsExist error is just plain wrong,
as directory we require is not created. It's cleaner to report
the error now.

Note this error is all over the tree, I guess due to copy-paste,
or trying to follow the same usage pattern as for Mkdir(),
or some not quite correct examples on the Internet.

> [1] https://github.com/golang/go/blob/f9ed2f75/src/os/path.go

-end-quote-

Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
kolyshkin added a commit to kolyshkin/buildah that referenced this pull request Jun 11, 2020
This subtle bug keeps lurking in because error checking for `Mkdir()`
and `MkdirAll()` is slightly different wrt `EEXIST`/`IsExist`:

 - for `Mkdir()`, `IsExist` error should (usually) be ignored
   (unless you want to make sure directory was not there before)
   as it means "the destination directory was already there";

 - for `MkdirAll()`, `IsExist` error should NEVER be ignored.

This commit removes ignoring the IsExist error, as it should not
be ignored.

[v2: skip patching (*Builder).Run]

For more details, a quote from opencontainers/runc PR containers#162:

-quote-

TL;DR: check for IsExist(err) after a failed MkdirAll() is both
redundant and wrong -- so two reasons to remove it.

Quoting MkdirAll documentation:

> MkdirAll creates a directory named path, along with any necessary
> parents, and returns nil, or else returns an error. If path
> is already a directory, MkdirAll does nothing and returns nil.

This means two things:

1. If a directory to be created already exists, no error is
returned.

2. If the error returned is IsExist (EEXIST), it means there exists
a non-directory with the same name as MkdirAll need to use for
directory. Example: we want to MkdirAll("a/b"), but file "a"
(or "a/b") already exists, so MkdirAll fails.

The above is a theory, based on quoted documentation and my UNIX
knowledge.

3. In practice, though, current MkdirAll implementation [1] returns
ENOTDIR in most of cases described in containers#2, with the exception when
there is a race between MkdirAll and someone else creating the
last component of MkdirAll argument as a file. In this very case
MkdirAll() will indeed return EEXIST.

Because of containers#1, IsExist check after MkdirAll is not needed.

Because of containers#2 and containers#3, ignoring IsExist error is just plain wrong,
as directory we require is not created. It's cleaner to report
the error now.

Note this error is all over the tree, I guess due to copy-paste,
or trying to follow the same usage pattern as for Mkdir(),
or some not quite correct examples on the Internet.

> [1] https://github.com/golang/go/blob/f9ed2f75/src/os/path.go

-end-quote-

Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
kolyshkin added a commit to kolyshkin/buildah that referenced this pull request Jul 1, 2020
This subtle bug keeps lurking in because error checking for `Mkdir()`
and `MkdirAll()` is slightly different wrt `EEXIST`/`IsExist`:

 - for `Mkdir()`, `IsExist` error should (usually) be ignored
   (unless you want to make sure directory was not there before)
   as it means "the destination directory was already there";

 - for `MkdirAll()`, `IsExist` error should NEVER be ignored.

This commit removes ignoring the IsExist error, as it should not
be ignored.

[v2: skip patching (*Builder).Run]

For more details, a quote from opencontainers/runc PR containers#162:

-quote-

TL;DR: check for IsExist(err) after a failed MkdirAll() is both
redundant and wrong -- so two reasons to remove it.

Quoting MkdirAll documentation:

> MkdirAll creates a directory named path, along with any necessary
> parents, and returns nil, or else returns an error. If path
> is already a directory, MkdirAll does nothing and returns nil.

This means two things:

1. If a directory to be created already exists, no error is
returned.

2. If the error returned is IsExist (EEXIST), it means there exists
a non-directory with the same name as MkdirAll need to use for
directory. Example: we want to MkdirAll("a/b"), but file "a"
(or "a/b") already exists, so MkdirAll fails.

The above is a theory, based on quoted documentation and my UNIX
knowledge.

3. In practice, though, current MkdirAll implementation [1] returns
ENOTDIR in most of cases described in containers#2, with the exception when
there is a race between MkdirAll and someone else creating the
last component of MkdirAll argument as a file. In this very case
MkdirAll() will indeed return EEXIST.

Because of containers#1, IsExist check after MkdirAll is not needed.

Because of containers#2 and containers#3, ignoring IsExist error is just plain wrong,
as directory we require is not created. It's cleaner to report
the error now.

Note this error is all over the tree, I guess due to copy-paste,
or trying to follow the same usage pattern as for Mkdir(),
or some not quite correct examples on the Internet.

> [1] https://github.com/golang/go/blob/f9ed2f75/src/os/path.go

-end-quote-

Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
rhatdan added a commit to rhatdan/buildah that referenced this pull request Oct 31, 2020
This subtle bug keeps lurking in because error checking for `Mkdir()`
and `MkdirAll()` is slightly different wrt `EEXIST`/`IsExist`:

 - for `Mkdir()`, `IsExist` error should (usually) be ignored
   (unless you want to make sure directory was not there before)
   as it means "the destination directory was already there";

 - for `MkdirAll()`, `IsExist` error should NEVER be ignored.

This commit removes ignoring the IsExist error, as it should not
be ignored.

[v2: skip patching (*Builder).Run]

For more details, a quote from opencontainers/runc PR containers#162:

-quote-

TL;DR: check for IsExist(err) after a failed MkdirAll() is both
redundant and wrong -- so two reasons to remove it.

Quoting MkdirAll documentation:

> MkdirAll creates a directory named path, along with any necessary
> parents, and returns nil, or else returns an error. If path
> is already a directory, MkdirAll does nothing and returns nil.

This means two things:

1. If a directory to be created already exists, no error is
returned.

2. If the error returned is IsExist (EEXIST), it means there exists
a non-directory with the same name as MkdirAll need to use for
directory. Example: we want to MkdirAll("a/b"), but file "a"
(or "a/b") already exists, so MkdirAll fails.

The above is a theory, based on quoted documentation and my UNIX
knowledge.

3. In practice, though, current MkdirAll implementation [1] returns
ENOTDIR in most of cases described in #2, with the exception when
there is a race between MkdirAll and someone else creating the
last component of MkdirAll argument as a file. In this very case
MkdirAll() will indeed return EEXIST.

Because of #1, IsExist check after MkdirAll is not needed.

Because of #2 and #3, ignoring IsExist error is just plain wrong,
as directory we require is not created. It's cleaner to report
the error now.

Note this error is all over the tree, I guess due to copy-paste,
or trying to follow the same usage pattern as for Mkdir(),
or some not quite correct examples on the Internet.

> [1] https://github.com/golang/go/blob/f9ed2f75/src/os/path.go

-end-quote-

Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
rhatdan added a commit to rhatdan/buildah that referenced this pull request Nov 3, 2020
This subtle bug keeps lurking in because error checking for `Mkdir()`
and `MkdirAll()` is slightly different wrt `EEXIST`/`IsExist`:

 - for `Mkdir()`, `IsExist` error should (usually) be ignored
   (unless you want to make sure directory was not there before)
   as it means "the destination directory was already there";

 - for `MkdirAll()`, `IsExist` error should NEVER be ignored.

This commit removes ignoring the IsExist error, as it should not
be ignored.

[v2: skip patching (*Builder).Run]

For more details, a quote from opencontainers/runc PR containers#162:

-quote-

TL;DR: check for IsExist(err) after a failed MkdirAll() is both
redundant and wrong -- so two reasons to remove it.

Quoting MkdirAll documentation:

> MkdirAll creates a directory named path, along with any necessary
> parents, and returns nil, or else returns an error. If path
> is already a directory, MkdirAll does nothing and returns nil.

This means two things:

1. If a directory to be created already exists, no error is
returned.

2. If the error returned is IsExist (EEXIST), it means there exists
a non-directory with the same name as MkdirAll need to use for
directory. Example: we want to MkdirAll("a/b"), but file "a"
(or "a/b") already exists, so MkdirAll fails.

The above is a theory, based on quoted documentation and my UNIX
knowledge.

3. In practice, though, current MkdirAll implementation [1] returns
ENOTDIR in most of cases described in #2, with the exception when
there is a race between MkdirAll and someone else creating the
last component of MkdirAll argument as a file. In this very case
MkdirAll() will indeed return EEXIST.

Because of #1, IsExist check after MkdirAll is not needed.

Because of #2 and #3, ignoring IsExist error is just plain wrong,
as directory we require is not created. It's cleaner to report
the error now.

Note this error is all over the tree, I guess due to copy-paste,
or trying to follow the same usage pattern as for Mkdir(),
or some not quite correct examples on the Internet.

> [1] https://github.com/golang/go/blob/f9ed2f75/src/os/path.go

-end-quote-

Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 30, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants