INVALID_ARGUMENT from CreateMicroVM when using Bloom/Node Client

[richardcase]

What happened:
When using BloomRPC or Node's grpc/proto-loader to call CreateMicroVM the following errors are returned:

From BloomRPC:

{
  "error": "3 INVALID_ARGUMENT: an error occurred when attempting to validate the request: validation failures found: Key: 'MicroVM.Spec.RootVolume.MountPoint' Error:Field validation for 'MountPoint' failed on the 'required' tag"
}

And Node:

Error: 3 INVALID_ARGUMENT: an error occurred when attempting to validate the request: validation failures found: Key: 'MicroVM.Spec.NetworkInterfaces[1].GuestDeviceName' Error:Field validation for 'GuestDeviceName' failed on the 'required' tag
Key: 'MicroVM.Spec.RootVolume.MountPoint' Error:Field validation for 'MountPoint' failed on the 'required' tag
    at Object.exports.createStatusError (/Users/cauld/projects/custom-tasks/ts-flintlock/node_modules/grpc/src/common.js:91:15)
    at Object.onReceiveStatus (/Users/cauld/projects/custom-tasks/ts-flintlock/node_modules/grpc/src/client_interceptors.js:1209:28)
    at InterceptingListener._callNext (/Users/cauld/projects/custom-tasks/ts-flintlock/node_modules/grpc/src/client_interceptors.js:568:42)
    at InterceptingListener.onReceiveStatus (/Users/cauld/projects/custom-tasks/ts-flintlock/node_modules/grpc/src/client_interceptors.js:618:8)
    at callback (/Users/cauld/projects/custom-tasks/ts-flintlock/node_modules/grpc/src/client_interceptors.js:847:24) {
  code: 3,
  metadata: Metadata { _internal_repr: {}, flags: 0 },
  details: "an error occurred when attempting to validate the request: validation failures found: Key: 'MicroVM.Spec.NetworkInterfaces[1].GuestDeviceName' Error:Field validation for 'GuestDeviceName' failed on the 'required' tag\n" +
    "Key: 'MicroVM.Spec.RootVolume.MountPoint' Error:Field validation for 'MountPoint' failed on the 'required' tag"
}

What did you expect to happen:
I expect to be able to call CreateMicroVM (and the other API calls) from different clients including BloomRPC and NodeJS.

How to reproduce it:

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Environment:

• flintlock version:
• containerd version:
• OS (e.g. from /etc/os-release):

[richardcase]

This sounds like MountPoint isn't being set. I'm currently creating a test node app.

[richardcase]

I have re-created the issue and have got the same error:

Error: 3 INVALID_ARGUMENT: an error occurred when attempting to validate the request: validation failures found: Key: 'MicroVM.Spec.RootVolume.MountPoint' Error:Field validation for 'MountPoint' failed on the 'required' tag
    at Object.callErrorFromStatus (/home/richard/code/ww/flintlock_nodejstest/node_modules/@grpc/grpc-js/build/src/call.js:31:26)
    at Object.onReceiveStatus (/home/richard/code/ww/flintlock_nodejstest/node_modules/@grpc/grpc-js/build/src/client.js:189:52)
    at Object.onReceiveStatus (/home/richard/code/ww/flintlock_nodejstest/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:365:141)
    at Object.onReceiveStatus (/home/richard/code/ww/flintlock_nodejstest/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:328:181)
    at /home/richard/code/ww/flintlock_nodejstest/node_modules/@grpc/grpc-js/build/src/call-stream.js:187:78
    at processTicksAndRejections (internal/process/task_queues.js:77:11) {code: 3, details: 'an error occurred when attempting to validat…or 'MountPoint' failed on the 'required' tag', metadata: Metadata, stack: 'Error: 3 INVALID_ARGUMENT: an error occurred …tions (internal/process/task_queues.js:77:11)', message: '3 INVALID_ARGUMENT: an error occurred when a…or 'MountPoint' failed on the 'required' tag'}

This is because there is no mount point specified on the create request:

    root_volume: {
        id: "root",
        is_read_only: "false",
        //mount_point: "/",
        source: {
            container_source: "ghcr.io/weaveworks-liquidmetal/capmvm-kubernetes:1.23.5"
        }
    },

[Callisto13]

As a related FYI, just in case you were thinking about it: I remember having a conversation around whether we should default the root_volume mount point to "/" and think we ended up saying that we... shouldn't? There is a thread somewhere... I hope.

[richardcase]

Using this code: https://gist.github.com/richardcase/23cb3b0b74c5c768de16895844aa8a9f

The short-term workaround is to set the mount point for the root volume: mount_point: "/".

[richardcase]

As a related FYI, just in case you were thinking about it: I remember having a conversation around whether we should default the root_volume mount point to "/" and think we ended up saying that we... shouldn't? There is a thread somewhere... I hope.

I have actually just made that change locally and think we should probably reconsider this. wdyt @Callisto13 ?

[richardcase]

@Callisto13 this is the dicussion: #241 (comment)

[Callisto13]

I think if we default this, just to be totally cautious, we should add a check on other volumes that they are not being mounted at "/", wdyt?

Admittedly the risk is small, but it is exactly the kind of irritating little thing which could come back to annoy us

[richardcase]

Sounds good, i will make that change.

[richardcase]

We have decided to remove MountPoint from flintlock for the time being as its not being used anywhere and so it seems weird that we require it.

[richardcase]

This has been fixed to closing