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

Expose serial number and bus type via GuestOsInfo #10970

Merged
merged 2 commits into from
Jan 24, 2024

Conversation

alromeros
Copy link
Contributor

@alromeros alromeros commented Jan 5, 2024

What this PR does / why we need it:

This PR updates the guestOsInfo command to show additional disk info, like serial number and bus type.

Example:

# virtctl guestosinfo testvmi-7j99w
selecting docker as container runtime
{
  "guestAgentVersion": "6.1.0",
  "supportedCommands": [
 ...
  ],
  "hostname": "testvmi-7j99w",
  "os": {
    "name": "Fedora Linux",
    "kernelRelease": "5.14.10-300.fc35.x86_64",
    "version": "35 (Cloud Edition)",
    "prettyName": "Fedora Linux 35 (Cloud Edition)",
    "versionId": "35",
    "kernelVersion": "#1 SMP Thu Oct 7 20:48:44 UTC 2021",
    "machine": "x86_64",
    "id": "fedora"
  },
  "timezone": "UTC, 0",
  "fsInfo": {
    "disks": [
      {
        "diskName": "vda3",
        "mountPoint": "/boot/efi",
        "fileSystemType": "vfat",
        "usedBytes": 10227712,
        "totalBytes": 104607744,
        "disk": [
          {
            "serial": "WD-WMAP9A966149",
            "bus-type": "virtio"
          }
        ]
      },
...

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 # https://issues.redhat.com/browse/CNV-18671

Special notes for your reviewer:

Added the api exceptions so we can fetch the guest-agent information without unnecessary structs as intermediaries (json names need to match). The api additions are in that way (Disk being an array, for example) to match the guest-agent response.

Release note:

Expose fs disk information via GuestOsInfo

This commit updates the guestOsInfo command to show additional disk info, like serial number and bus type.

Signed-off-by: Alvaro Romero <alromero@redhat.com>
@kubevirt-bot kubevirt-bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jan 5, 2024
@kubevirt-bot
Copy link
Contributor

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@kubevirt-bot kubevirt-bot added dco-signoff: yes Indicates the PR's author has DCO signed all their commits. do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. labels Jan 5, 2024
@kubevirt-bot kubevirt-bot added size/L kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API labels Jan 5, 2024
Signed-off-by: Alvaro Romero <alromero@redhat.com>
@alromeros alromeros marked this pull request as ready for review January 10, 2024 18:40
@alromeros
Copy link
Contributor Author

/test pull-kubevirt-e2e-k8s-1.28-sig-compute-migrations

@alromeros alromeros changed the title [WIP] Expose serial number and bus type via GuestOsInfo Expose serial number and bus type via GuestOsInfo Jan 15, 2024
@kubevirt-bot kubevirt-bot added release-note Denotes a PR that will be considered when it comes time to generate release notes. and removed do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. labels Jan 15, 2024
@mhenriks
Copy link
Member

/approve

@kubevirt-bot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mhenriks

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@kubevirt-bot kubevirt-bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 18, 2024
@enp0s3
Copy link
Contributor

enp0s3 commented Jan 21, 2024

/lgtm

@kubevirt-bot kubevirt-bot added the lgtm Indicates that a PR is ready to be merged. label Jan 21, 2024
@kubevirt-commenter-bot
Copy link

Required labels detected, running phase 2 presubmits:
/test pull-kubevirt-e2e-k8s-1.27-ipv6-sig-network

@enp0s3
Copy link
Contributor

enp0s3 commented Jan 21, 2024

/hold

@mhenriks @alromeros Sorry perhaps I am missing something, since you've added a non-primitive type to the api, don't you miss the piece of code that should prepare the slice as part of the parsing process?

@kubevirt-bot kubevirt-bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jan 21, 2024
@@ -196,6 +197,7 @@ func parseFilesystem(agentReply string) ([]api.Filesystem, error) {
Type: fs.Type,
TotalBytes: fs.TotalBytes,
UsedBytes: fs.UsedBytes,
Disk: fs.Disk,
Copy link
Contributor

@enp0s3 enp0s3 Jan 21, 2024

Choose a reason for hiding this comment

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

Is it safe to just assign it like that w/o iterating and running append to the list you create with a make?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah I think it's safe to just assign slices

@alromeros
Copy link
Contributor Author

/hold

@mhenriks @alromeros Sorry perhaps I am missing something, since you've added a non-primitive type to the api, don't you miss the piece of code that should prepare the slice as part of the parsing process?

Hey @enp0s3, isn't that automatically handled by the generate scripts? What is exactly missing in this one?

@enp0s3
Copy link
Contributor

enp0s3 commented Jan 22, 2024

@alromeros I took GetUsers() as a reference. The code iterates over the data it got from l.agentData.GetUsers(-1) , so how this is different from your case where you receive the fs.disk as a list?

Should you have a function l.agentData.GetDisks(fs) or something similar?

@enp0s3
Copy link
Contributor

enp0s3 commented Jan 22, 2024

@alromeros I think I am confused because of the definition []v1.VirtualMachineInstanceFileSystemDisk, why did you defined it as a slice? do you expect to receive a list of disks from the AgentData in fs.Disk?

@alromeros
Copy link
Contributor Author

alromeros commented Jan 23, 2024

@alromeros I took GetUsers() as a reference. The code iterates over the data it got from l.agentData.GetUsers(-1) , so how this is different from your case where you receive the fs.disk as a list?

Should you have a function l.agentData.GetDisks(fs) or something similar?

Right, I get what you mean. Following your example, GetUsers uses an intermediary struct on the agent-poller side to store the guest agent response. Then, it copies each element of the api.User type to the v1.VirtualMachineInstanceGuestOSUser type here.

We have something similar in GetFilesystems (the command I'm updating). We fetch the whole guest agent response here. Since the new field I added (disks) has the same JSON formatting as the disks field in the guest agent response, there's no need for an intermediary struct and we can just assign it without needing to iterate.

Maybe I'm missing something, but I don't see any good reasons for this intermediary step when we can just adjust the type (v1.VirtualMachineInstanceFileSystemDisk in this case) to match the formatting of the GA response.

@alromeros
Copy link
Contributor Author

@alromeros I think I am confused because of the definition []v1.VirtualMachineInstanceFileSystemDisk, why did you defined it as a slice? do you expect to receive a list of disks from the AgentData in fs.Disk?

Right, I'm just mirroring the guest agent's response (an array of disk).

@enp0s3
Copy link
Contributor

enp0s3 commented Jan 23, 2024

/unhold

@alromeros Thank you for the explanation! So the json.Unmarshal([]byte(response), &result) already allocates the slice.

@kubevirt-bot kubevirt-bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jan 23, 2024
@alromeros
Copy link
Contributor Author

/retest-required

@kubevirt-bot kubevirt-bot merged commit 80e35d3 into kubevirt:main Jan 24, 2024
42 checks passed
Copy link
Member

@xpivarc xpivarc left a comment

Choose a reason for hiding this comment

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

@enp0s3 this PR doesn't add a new test nor does it extend the existing functional test.

@@ -2215,13 +2215,20 @@ type VirtualMachineInstanceFileSystemList struct {
Items []VirtualMachineInstanceFileSystem `json:"items"`
}

// VirtualMachineInstanceFileSystemDisk represents the guest os FS disks
type VirtualMachineInstanceFileSystemDisk struct {
Serial string `json:"serial"`
Copy link
Member

Choose a reason for hiding this comment

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

Missing omitempty

Copy link
Member

Choose a reason for hiding this comment

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

@alromeros is this ever expected to be empty? I would be pretty surprised

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think BusType will never be empty, but Serial is optional: https://qemu-project.gitlab.io/qemu/interop/qemu-ga-ref.html#qapidoc-146.

// VirtualMachineInstanceFileSystemDisk represents the guest os FS disks
type VirtualMachineInstanceFileSystemDisk struct {
Serial string `json:"serial"`
BusType string `json:"bus-type"`
Copy link
Member

Choose a reason for hiding this comment

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

This does break convention, it should be json:"busType".

Copy link
Contributor

Choose a reason for hiding this comment

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

@xpivarc Thanks for the heads up! this check must be automated somehow, it is something hard to remember for the long term.

Copy link
Member

Choose a reason for hiding this comment

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

we can make the make generate fail

Copy link
Contributor Author

Choose a reason for hiding this comment

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

make generate failed but I added an exception to allow this formatting so we don't need an intermediary type:

API rule violation: names_match,kubevirt.io/api/core/v1,VirtualMachineInstanceFileSystemDisk,BusType

I will fix it to avoid breaking the convention.

Copy link
Member

Choose a reason for hiding this comment

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

I assumed we wanted to expose with exact naming naming scheme as libvirt

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah me too. It prevents adding some unnecessary code, but I guess it's odd to only add the exception to BusType.

FileSystemType string `json:"fileSystemType"`
UsedBytes int `json:"usedBytes"`
TotalBytes int `json:"totalBytes"`
Disk []VirtualMachineInstanceFileSystemDisk `json:"disk,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

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

Why is this a slice?

Copy link
Contributor

Choose a reason for hiding this comment

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

I got the explanation here

Copy link
Member

Choose a reason for hiding this comment

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

That doesn't explain the question, @alromeros can you elaborate?

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 are storing here the guest agent response to the guest-get-fsinfo command. The command returns an array of disks, so I'm using one: https://qemu-project.gitlab.io/qemu/interop/qemu-ga-ref.html#qapidoc-161.

@enp0s3
Copy link
Contributor

enp0s3 commented Jan 24, 2024

@enp0s3 this PR doesn't add a new test nor does it extend the existing functional test.

@xpivarc TBH I felt uncomfortable with that as well but I had a doubt whether functional coverage fits here, or unit is enough.

@xpivarc
Copy link
Member

xpivarc commented Jan 24, 2024

@enp0s3 this PR doesn't add a new test nor does it extend the existing functional test.

@xpivarc TBH I felt uncomfortable with that as well but I had a doubt whether functional coverage fits here, or unit is enough.

@enp0s3
There is an existing functional test, all that is needed to include check that the proper field is populated. Zero cost.

@enp0s3
Copy link
Contributor

enp0s3 commented Jan 24, 2024

@enp0s3 this PR doesn't add a new test nor does it extend the existing functional test.

@xpivarc TBH I felt uncomfortable with that as well but I had a doubt whether functional coverage fits here, or unit is enough.

@enp0s3 There is an existing functional test, all that is needed to include check that the proper field is populated. Zero cost.

@xpivarc +1
@alromeros Can you please create a follow-up PR for that?

@alromeros
Copy link
Contributor Author

@enp0s3 this PR doesn't add a new test nor does it extend the existing functional test.

@xpivarc TBH I felt uncomfortable with that as well but I had a doubt whether functional coverage fits here, or unit is enough.

@enp0s3 There is an existing functional test, all that is needed to include check that the proper field is populated. Zero cost.

Didn't see individual checks for most of the fields in fsList but I can add them in a follow-up. Will open it later once we decide if the API is good.

kubevirt-bot added a commit that referenced this pull request Feb 22, 2024
Follow-up #10970: Minor API fixes to get fsList disks
kubevirt-bot added a commit that referenced this pull request Feb 26, 2024
…ase-1.2

[release-1.2] Follow-up #10970: Minor API fixes to get fsList disks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. dco-signoff: yes Indicates the PR's author has DCO signed all their commits. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API lgtm Indicates that a PR is ready to be merged. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/L
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants