Skip to content

Don't patch non-stub drives #240

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

Merged
merged 3 commits into from
Aug 6, 2019
Merged

Conversation

kzys
Copy link
Contributor

@kzys kzys commented Aug 5, 2019

Issue #, if available:

Related to, but may need more changes to actually fix #230

Description of changes:

Currently the drive handler knows non-stub drives (root drive). Because of that PatchStubDrive() replace non-stub drives, once all stub drives are patched.

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

@kzys kzys requested a review from xibz August 5, 2019 18:50
@kzys
Copy link
Contributor Author

kzys commented Aug 5, 2019

Honestly speaking, I'm unsure this is the right place to address the issue. We could argue that the drive handler shouldn't know about a root drive and the caller of the handler must pass only stub drives.

@kzys kzys force-pushed the fix-patch-drive branch from 0b5c159 to 597a18d Compare August 5, 2019 19:01
@@ -125,10 +125,20 @@ func (h *stubDriveHandler) createStubDrive(driveID, path string) error {
return nil
}

func filterOnlyStubDrives(drives []models.Drive) []models.Drive {
Copy link
Contributor

Choose a reason for hiding this comment

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

May be a good idea to document why this occurs which is due to the root drive being always being the last element when Build is called on the drive builder from the SDK.

Copy link
Contributor Author

@kzys kzys Aug 5, 2019

Choose a reason for hiding this comment

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

You meant, this Build.

https://github.com/firecracker-microvm/firecracker-go-sdk/blob/29621e288fa1333809e5b43d867dbb73d82b5456/drives.go#L63

BTW, why do we want to place the root drive at the end of the drives?

Copy link
Contributor

Choose a reason for hiding this comment

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

The location of root drive is arbitrary. End was chosen since you didn't need to create a []models.Drive to append to.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks. The new revision has some comments around drives initialization. Would it be good enough?

@@ -125,10 +125,20 @@ func (h *stubDriveHandler) createStubDrive(driveID, path string) error {
return nil
}

func filterOnlyStubDrives(drives []models.Drive) []models.Drive {
stubDrives := make([]models.Drive, 0)
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: I'd rather prefer preallocating here as we know the size in advance: make([]models.Drive, 0, len(drives))

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Wouldn't it allocate more than what we need?

Copy link
Contributor

Choose a reason for hiding this comment

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

Should it be just make([]models.Drive) then?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We don't have the filter logic anymore, and all make calls explicitly specify the capacity.

@xibz
Copy link
Contributor

xibz commented Aug 5, 2019

I wonder if it makes sense to just have an array of stub drives that is passed into SetDrives. See here. We only use a single drive builder, but it doesn't mean we can't use two. That may simpler than trying to filter, and if we prefer filtering we may want to filter on what is a stub drive as opposed to what is root.

@kzys
Copy link
Contributor Author

kzys commented Aug 5, 2019

It does make sense. runtime/service.go knows about stub drives, but Firecracker doesn't have the notion of stub drives. Thus finding stub-drives on Firecracker-origin structs (such as cfg.Drives) is not straightforward.

Before this change, a stub drive handler knew non-stub drives, including
the root drive. However patching non-stub drives is not supported and
must be prevented.

Related: firecracker-microvm#230

Signed-off-by: Kazuyoshi Kato <[email protected]>
@kzys kzys force-pushed the fix-patch-drive branch from 597a18d to 0cf15f3 Compare August 6, 2019 18:23
@kzys kzys force-pushed the fix-patch-drive branch from 10498c8 to 0f7744f Compare August 6, 2019 21:30
Copy link
Contributor

@xibz xibz left a comment

Choose a reason for hiding this comment

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

LGTM! :shipit:

@kzys kzys merged commit 4e8ad74 into firecracker-microvm:master Aug 6, 2019
@kzys kzys deleted the fix-patch-drive branch August 13, 2019 16:40
fangn2 pushed a commit to fangn2/firecracker-containerd that referenced this pull request Mar 23, 2023
…ependabot/go_modules/github.com/stretchr/testify-1.6.1

Bump github.com/stretchr/testify from 1.6.0 to 1.6.1
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.

Cannot reuse a Firecracker VM from multiple containers without specifying Container Count
4 participants