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

Fix crash in copyVolumeDataPodFunc when location type is not GCS #2072

Merged
merged 4 commits into from
May 24, 2023

Conversation

e-sumin
Copy link
Contributor

@e-sumin e-sumin commented May 24, 2023

Change Overview

copyVolumeDataPodFunc is crashing when location type is not GCS

Pull request type

Please check the type of change your PR introduces:

  • 🚧 Work in Progress
  • 🌈 Refactoring (no functional changes, no api changes)
  • 🐹 Trivial/Minor
  • 🐛 Bugfix
  • 🌻 Feature
  • 🗺️ Documentation
  • 🤖 Test
  • 💪 Manual
  • ⚡ Unit test
  • 💚 E2E

@github-actions
Copy link
Contributor

Thanks for submitting this pull request 🎉. The team will review it soon and get back to you.

If you haven't already, please take a moment to review our project contributing guideline and Code of Conduct document.

@infraq infraq added this to In Progress in Kanister May 24, 2023
@e-sumin e-sumin force-pushed the fix/copyVolumeDataPodFunc-crash branch from 5a62060 to 7c974f1 Compare May 24, 2023 10:18
Kanister automation moved this from In Progress to Reviewer approved May 24, 2023
Comment on lines 102 to 104
if remover != nil { // WriteCredsToPod might return nil when nothing was written
defer remover.Remove(context.Background()) //nolint:errcheck
}
Copy link
Contributor

Choose a reason for hiding this comment

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

should we use the parent context instead of creating new one.

Copy link
Contributor

Choose a reason for hiding this comment

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

If the parent context dies, the clean up call will be aborted as well. Thus, I think there's no issue here. But maybe it makes sense to put a note.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Exactly, I'll add a comment

@denisvmedia
Copy link
Contributor

denisvmedia commented May 24, 2023

I think the real cause of the failure is that the remover is unexpectedly nil (see: https://github.com/kanisterio/kanister/blob/2babd1ad48c4f408f614c50ded06a2f3eb2a13b0/pkg/function/utils.go#LL102C1-L113C2). I strongly believe (however, my beliefs might be wrong) that returning nil for the object when there is no error (thus return nil, nil) is wrong in most of the cases (and here as well).

If we check

// WriteCredsToPod creates a file with Google credentials if the given profile points to a GCS location
func WriteCredsToPod(ctx context.Context, writer kube.PodFileWriter, profile *param.Profile) (kube.PodFileRemover, error) {
	if profile.Location.Type == crv1alpha1.LocationTypeGCS {
		remover, err := writer.Write(ctx, consts.GoogleCloudCredsFilePath, bytes.NewBufferString(profile.Credential.KeyPair.Secret))
		if err != nil {
			return nil, errors.Wrapf(err, "Unable to write Google credentials to the pod.")
		}

		return remover, nil
	}
	return nil, nil
}

I'd instead implement a NopRemover that would do nothing, and return it instead of nil. This will prevent further mistakes like the one solved in this PR.

@@ -99,7 +99,9 @@ func copyVolumeDataPodFunc(cli kubernetes.Interface, tp param.TemplateParams, na
return nil, errors.Wrapf(err, "Failed to write credentials to Pod %s", pc.PodName())
}

defer remover.Remove(context.Background()) //nolint:errcheck
if remover != nil { // WriteCredsToPod might return nil when nothing was written
Copy link
Contributor

Choose a reason for hiding this comment

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

Check my PR comment: #2072 (comment)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, I agree with NopRemover. I thought about this but decided that probably it's an overkill. But since this came not only to my mind, it probably makes sense.

Comment on lines 105 to 113
var _ kube.PodFileRemover = (*nopRemover)(nil)

func (nr *nopRemover) Remove(ctx context.Context) error {
return nil
}

func (nr *nopRemover) Path() string {
return ""
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
var _ kube.PodFileRemover = (*nopRemover)(nil)
func (nr *nopRemover) Remove(ctx context.Context) error {
return nil
}
func (nr *nopRemover) Path() string {
return ""
}
var _ kube.PodFileRemover = (nopRemover)(nil)
func (nr nopRemover) Remove(ctx context.Context) error {
return nil
}
func (nr nopRemover) Path() string {
return ""
}

@@ -109,7 +122,7 @@ func WriteCredsToPod(ctx context.Context, writer kube.PodFileWriter, profile *pa

return remover, nil
}
return nil, nil
return &nopRemover{}, nil
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
return &nopRemover{}, nil
return nopRemover{}, nil

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

@pavannd1 pavannd1 changed the title FIx crash in copyVolumeDataPodFunc when location type is not GCS Fix crash in copyVolumeDataPodFunc when location type is not GCS May 24, 2023
@pavannd1 pavannd1 added the kueue label May 24, 2023
@mergify mergify bot merged commit 40fb249 into master May 24, 2023
Kanister automation moved this from Reviewer approved to Done May 24, 2023
@mergify mergify bot deleted the fix/copyVolumeDataPodFunc-crash branch May 24, 2023 17:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Development

Successfully merging this pull request may close these issues.

None yet

4 participants