Bug 1469683

Additional command:
(From a customer ticket:)
Run below commands on SPM host 'hv1.rhev.corp.example.com' to collect mete data

# dd if=/dev/5d7aeb2b-e386-401a-901a-b57dfafbd6b5/metadata of=/tmp/meta_5d7.out
# dd if=/dev/95b286cf-cdef-4e73-81a3-16eac1c8486e/metadata of=/tmp/meta_95b.out

And then they ask to tgz it (though I assume it's quite small?).

vdsm-client could surely spit out the domain metadata.
It could probably then be added to the log collector.

vdsm-client is based purely on VDSM schema which reflects VDSM API. Such command doesn't exist in the API, so moving to storage to implement required commands and once they are part of API/schema, they will be available in vdsm-client

(In reply to Martin Perina from comment #3)
> vdsm-client is based purely on VDSM schema which reflects VDSM API. Such
> command doesn't exist in the API, so moving to storage to implement required
> commands and once they are part of API/schema, they will be available in
> vdsm-client

Perhaps a different tool that will use the metadata from vdsm-client makes more sense then, instead of those manual 'dd' commands. Even simple Ansible playbooks (is there anything that Ansible can't do?)

IMO, enabling this via the VDSM api would be the best.

We already have "vdsm-client SDM update_volume" -> volume/update_attributes() but its currently limited to legality, description, generation and type. And even type has some constraints.

(In reply to Germano Veit Michel from comment #5)
> IMO, enabling this via the VDSM api would be the best.
> 
> We already have "vdsm-client SDM update_volume" ->
> volume/update_attributes() but its currently limited to legality,
> description, generation and type. And even type has some constraints.

I agree.

I think the next step is:
- add the missing attributes to the api
- create  a vdsm-tool command to perform the change using easy to use api.

Something like:

    vdsm-tool dump-volume-metadata vol-uuid > json
    vdsm-tool update-volume-metadata --voltype=value --size=value vol-uuid

Or:

    vdsm-tool dump-volume-metadata vol-uuid > vol.json
    edit vol.json
    vdsm-tool load-volume-metadata vol-uuid < vol.json

Of course making it easy to modify volume metadata means a user can break stuff
easier. The tool will have to log detailed warnings about this.

Similar solution is needed for any other metadata (domain, ovf store, etc).

(In reply to Nir Soffer from comment #6)

> Something like:
> 
>     vdsm-tool dump-volume-metadata vol-uuid > json
>     vdsm-tool update-volume-metadata --voltype=value --size=value vol-uuid
> 
> Or:
> 
>     vdsm-tool dump-volume-metadata vol-uuid > vol.json
>     edit vol.json
>     vdsm-tool load-volume-metadata vol-uuid < vol.json
> 
> Of course making it easy to modify volume metadata means a user can break
> stuff
> easier. The tool will have to log detailed warnings about this.

Much easier to read and safer than our dd with skip/seek and sed, but I would still prefer a single command taking care of this.

Perhaps if we add a new api command, that reads the current volume attributes (including generation), applies the changes in memory and then uses the existing facilities (which need to be extended for more attributes) to make the actual modification in the shared storage?

Ideally just this:
vdsm-tool update-volume-metadata --attr=value vol-uuid

Any ideas?

> Similar solution is needed for any other metadata (domain, ovf store, etc).
Certainly. However, we probably do 100's of volume metadata edits for each domain metadata edit. So probably not a priority.

All patches have been posted and are passing CI. Waiting for reviews.

https://gerrit.ovirt.org/#/q/topic:update-volume+(status:open+OR+status:merged)

I've renamed them to snapshot-tools:

https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:snapshot-tools

CI has been randomly failing on some problems on each rebase which we are investigating, but the patches are ready to be reviewed.

This bug has not been marked as blocker for oVirt 4.3.0.
Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.

Would be nice if this got some more attention.

In some cases (see https://bugzilla.redhat.com/show_bug.cgi?id=1895840) its very useful to be able to edit volume type etc.
So a proper option to do this is very wanted :)

If maybe some parts can be merged for example (like https://gerrit.ovirt.org/#/c/94100/)