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

Add NodeStage to internal CSI implementation #3900

Closed
wants to merge 4 commits into from

Conversation

fierlion
Copy link
Member

Summary

This adds NodeStage to the internal/minimal EBS CSI Driver. This code comes directly from https://github.com/kubernetes-sigs/aws-ebs-csi-driver and is used to create a minimal Node-specific driver.

Implementation details

The driver is updated to use the public.ecr.aws/eks-distro-build-tooling/eks-distro-minimal-base-csi-ebs base image which contains all requisite mount utilities in the path while still keeping the overall driver to ~50mb in size. The NodeStage implementation adds only the files and dependencies which are directly tied to the EBS volume Mount/format/fs resize.

Testing

Manual test process:

  • attach an ebs volume to EC2 host
  • built CSI Driver Image using Dockerfile
  • started driver as an ecs-agent Managed Daemon
  • called NodeStage from ecs-agent-based csiclient with hard coded device name and volume ID
  • validated the mount succeeds with xfs filesystem type.

New tests cover the changes: no

Description for the changelog

Update Minimal CSI Driver with NodeStage method.

Licensing

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@fierlion fierlion requested a review from a team as a code owner September 12, 2023 19:30
@fierlion fierlion force-pushed the fierlion/nodeStageDaemon branch 5 times, most recently from 06652c6 to 6142610 Compare September 13, 2023 17:15
Copy link
Contributor

@Realmonia Realmonia left a comment

Choose a reason for hiding this comment

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

Can you add a brief description about what "stage" is in the process of an ebs mounting?

func isValidVolumeContext(volContext map[string]string) bool {
//There could be multiple volume attributes in the volumeContext map
//Validate here case by case
if partition, ok := volContext[VolumeAttributePartition]; ok {
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need extra handlings if volContext[VolumeAttributePartition] returns a not OK? It returns a true if it happens.

.gitignore Outdated Show resolved Hide resolved
}

func isValidVolumeContext(volContext map[string]string) bool {
//There could be multiple volume attributes in the volumeContext map
Copy link
Contributor

Choose a reason for hiding this comment

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

Not sure if the comment here is accurate. Aren't we only validating partition attribute here?

)

// InFlight is a struct used to manage in flight requests per volumeId.
type InFlight struct {
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we persist this or plan to persist this somehow?

import (
"sync"

"k8s.io/klog/v2"
Copy link
Contributor

Choose a reason for hiding this comment

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

What's the difference betwen klog vs. our existing logging?

func (m *NodeMounter) PathExists(path string) (bool, error) {
return mountutils.PathExists(path)
}

func (m *NodeMounter) NeedResize(devicePath string, deviceMountPath string) (bool, error) {
return mountutils.NewResizeFs(m.Exec).NeedResize(devicePath, deviceMountPath)
Copy link
Contributor

Choose a reason for hiding this comment

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

Would this mean everytime we call this function we need to initialize a new ResizeFs? Is it necessary?

Comment on lines +318 to +319
// This check is already performed on the controller side
// However, because it is potentially security-sensitive, we redo it here to be safe
Copy link
Contributor

Choose a reason for hiding this comment

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

If they are executing the same code and nothing changed, how recheck makes it more secure?


partition := ""
if part, ok := volumeContext[VolumeAttributePartition]; ok {
if part != "0" {
Copy link
Contributor

Choose a reason for hiding this comment

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

Since it is a string, is it possible to have something like "00" here which actually means the same thing?

Copy link
Contributor

@mye956 mye956 Sep 19, 2023

Choose a reason for hiding this comment

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

nit(non-blocking): perhaps we can add a bit more context of what we're checking for here with some comments

}
}

source, err := d.findDevicePath(devicePath, volumeID, partition)
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you add a comment here about if the partition is the "", what does that mean?

msg := fmt.Sprintf("failed to check if target %q exists: %v", target, err)
return nil, status.Error(codes.Internal, msg)
}
// When exists is true it means target path was created but device isn't mounted.
Copy link
Contributor

Choose a reason for hiding this comment

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

When will this happen? Another volume had been mounted to this path and was unmounted?

@fierlion fierlion force-pushed the fierlion/nodeStageDaemon branch 13 times, most recently from bec3465 to 76c47eb Compare September 19, 2023 22:52
Copy link
Contributor

@xxx0624 xxx0624 left a comment

Choose a reason for hiding this comment

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

Btw do we need to make updates in Makefile - https://github.com/aws/amazon-ecs-agent/blob/master/ecs-agent/daemonimages/csidriver/Makefile to somehow use the docker file? or that will be used already?

We depend on the https://github.com/aws/amazon-ecs-agent/blob/master/ecs-agent/daemonimages/csidriver/Makefile to build the tar file.

@fierlion fierlion force-pushed the fierlion/nodeStageDaemon branch 4 times, most recently from 27dc11a to 9fcbe0e Compare September 21, 2023 19:52
@fierlion fierlion closed this Sep 21, 2023
@fierlion fierlion deleted the fierlion/nodeStageDaemon branch September 21, 2023 21:39
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.

None yet

6 participants