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

feat: initial implementation of microvm create #98

Merged
merged 2 commits into from
Oct 7, 2021
Merged

Conversation

richardcase
Copy link
Member

@richardcase richardcase commented Sep 29, 2021

What this PR does / why we need it:

This change contains the initial implementation of microvm create.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #31
Fixes #71
Fixes: #96

Special notes for your reviewer:

Checklist:

  • squashed commits
  • includes documentation
  • adds unit tests
  • adds or updates e2e tests

Release note:

Create microvm via API call has been implemented.

@richardcase richardcase added the kind/feature New feature or request label Sep 29, 2021
@github-actions
Copy link
Contributor

This PR is so big! Please, split it 😊

This change implements the initial microvm create flow. It
includes the "create plane" and various other changes to make
this work.

Test coverage has dropped as a result and we'll follow up with
additional tests.

Signed-off-by: Richard Case <[email protected]>
@github-actions
Copy link
Contributor

This PR is so big! Please, split it 😊

@richardcase
Copy link
Member Author

This PR is so big! Please, split it blush

Even GitHub Actions are telling me i've done a bad thing!

@github-actions
Copy link
Contributor

This PR is so big! Please, split it 😊

Signed-off-by: Richard Case <[email protected]>
@github-actions
Copy link
Contributor

This PR is so big! Please, split it 😊

@richardcase richardcase changed the title WIP: feat: initial implementation of microvm create feat: initial implementation of microvm create Sep 30, 2021
@yitsushi yitsushi mentioned this pull request Oct 4, 2021
2 tasks
Copy link
Contributor

@yitsushi yitsushi left a comment

Choose a reason for hiding this comment

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

I could manage around half way through the PR, looks good, only a few questions/suggestions.

// AllowMetadataReq indicates if the network interface allows metadata requests.
bool allow_metadata_req = 1;
bool allow_metadata_req = 3;
// GuestMAC allows the specifying of a specifi MAC address to use for the interface. If
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
// GuestMAC allows the specifying of a specifi MAC address to use for the interface. If
// GuestMAC allows the specifying of a specific MAC address to use for the interface.

// GuestDeviceName is the name of the network interface to create in the microvm. If this
// is not supplied than a device name will be assigned automatically
optional string guest_device_name = 3;
// not supplied a autogenerated MAC address will be used.
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
// not supplied a autogenerated MAC address will be used.
// If not supplied an auto-generated MAC address will be used.

@@ -14,7 +14,8 @@ type MicroVMRepository interface {
Delete(ctx context.Context, microvm *models.MicroVM) error
// Get will get the microvm spec with the given name/namespace.
Get(ctx context.Context, name, namespace string) (*models.MicroVM, error)
// GetAll will get a list of microvm details.
// GetAll will get a list of microvm details. If namespace is an empty string all
// details of microvms will be returned.
GetAll(ctx context.Context, namespace string) ([]*models.MicroVM, error)
Copy link
Contributor

Choose a reason for hiding this comment

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

I know it's already there, but wouldn't be List a better name for this functionality?

// make it available via a mount point.
GetAndMount(ctx context.Context, input GetImageInput) ([]models.Mount, error)
PullAndMount(ctx context.Context, input *ImageMountSpec) ([]models.Mount, error)
Copy link
Contributor

Choose a reason for hiding this comment

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

If it has a separate Pull, maybe a Mount function can be useful. For example if we want to control the full workflow and call Pull, verify, and then Mount. With this, we can call Pull, verify, and PullAndMerge, which is fine if it's guaranteed it will be the same and does not try to pull and/or check if the remote has been change again

Copy link
Contributor

@yitsushi yitsushi left a comment

Choose a reason for hiding this comment

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

Looks good to me, I suggest to merge it as it is (assuming everything is working) and create follow-up tickets/PRs. Large PRs tend to grow bigger and bigger in the name of "fix/add just this one" and it becomes harder and harder to review and test.

@richardcase richardcase merged commit 28f2a5b into main Oct 7, 2021
@richardcase richardcase deleted the create_plan branch October 7, 2021 06:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature New feature or request size/xl
Projects
None yet
2 participants