Hi German,

Can you please have a look at this one.

Hi Ján,

What would be useful to add to signal the new option format?, something like:
"supported-option-formats": ["old", "new"]  (not sure if "old" and "new" are good names)
Just in case we need to add a new format (someone asked for a qmp style format)

I think we should also update the output of '--print_capabilities', here we can also set "features: []" (after checking) if we support file handles, and migration (when finished)

Hi,

naming is hard :)

"old" vs. "new" get "old" over time - is there a better way to describe them? "minus-o", "grouped" vs. "individual"?
Is there any other reason for their deprecation than the duplicity? I see they're referred to as "compat" in the code,
but not sure what the "new" ones would be.

Also, libvirt could infer the new ones just from the presence of the field, e.g.:
"features": ["no-compat-options"]

I'm not sure what the constraints are for the interop files from reading:
https://gitlab.com/qemu-project/qemu/blob/master/docs/interop/vhost-user.json
i.e. whether "supported-option-formats" is ok, or it should be "features".

And yes, --print_capabilities should report the same as the .json file.
So far libvirt only looks for the .json files in the usual locations when there
is no binary path specified in the XML, because they only contain the binary path.
But for other feature flags, it will need to start looking at --print_capabilities too
if we did not learn the features from virtiofsd.json

(In reply to Ján Tomko from comment #3)
> Hi,
> 
> naming is hard :)
> 
> "old" vs. "new" get "old" over time - is there a better way to describe
> them? "minus-o", "grouped" vs. "individual"?
> Is there any other reason for their deprecation than the duplicity? I see
> they're referred to as "compat" in the code,
> but not sure what the "new" ones would be.
> 
> Also, libvirt could infer the new ones just from the presence of the field,
> e.g.:
> "features": ["no-compat-options"]
> 
> I'm not sure what the constraints are for the interop files from reading:
> https://gitlab.com/qemu-project/qemu/blob/master/docs/interop/vhost-user.json
> i.e. whether "supported-option-formats" is ok, or it should be "features".

It seems you are right we need to use "features", but IIUC we need to update
the schema to use "features". Although, it seems @VHostUserBackendCapabilities
is outdated, because it doesn't define the features for block devices either
(@VHostUserBackendCapabilitiesBlock)

I'm ok with: "features": ["no-compat-options"]

I'll find if we need to update the schema.
 
> And yes, --print_capabilities should report the same as the .json file.
> So far libvirt only looks for the .json files in the usual locations when
> there
> is no binary path specified in the XML, because they only contain the binary
> path.
> But for other feature flags, it will need to start looking at
> --print_capabilities too
> if we did not learn the features from virtiofsd.json

I think my idea of showing if we effectively support file handles will not work.
The docs say "The capabilities can be reported dynamically depending on
the host capabilities", but to report the FH it depends on the
shared dir, so it requires to also pass --shared-dir, and I think that 
is not expected.

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.