Bug 1469683 - [BLOCKED][RFE] Provide tool to modify volume metadata values
Summary: [BLOCKED][RFE] Provide tool to modify volume metadata values
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm
Version: 4.1.2
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: Germano Veit Michel
QA Contact: Avihai
URL:
Whiteboard:
Depends On: 1678969
Blocks: 902971 1520566
TreeView+ depends on / blocked
 
Reported: 2017-07-11 15:46 UTC by Gordon Watson
Modified: 2021-06-10 12:35 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-09-25 04:42:24 UTC
oVirt Team: Storage
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1489145 0 high CLOSED [RFE][Tracker] Provide tools to analyze snapshot issues and cross check database and storage metadata. 2024-12-20 18:43:51 UTC
Red Hat Knowledge Base (Article) 3677531 0 None None None 2019-10-29 04:50:11 UTC
oVirt gerrit 91904 0 'None' MERGED storage: fix update_volume documentation 2020-11-17 13:18:47 UTC
oVirt gerrit 93258 0 'None' ABANDONED storage: split validation logic from update_attributes 2020-11-17 13:18:47 UTC
oVirt gerrit 93259 0 'None' ABANDONED storage: add force option to update_volume 2020-11-17 13:19:10 UTC
oVirt gerrit 93260 0 master ABANDONED storage: add capacity option to update_volume 2020-11-17 13:18:49 UTC
oVirt gerrit 94097 0 master ABANDONED storage: add parent option to update_volume 2020-11-17 13:18:48 UTC
oVirt gerrit 94098 0 master ABANDONED storage: add format option to update_volume 2020-11-17 13:18:50 UTC
oVirt gerrit 94099 0 master ABANDONED storage: add allocation option to update_volume 2020-11-17 13:18:49 UTC
oVirt gerrit 94100 0 master ABANDONED storage: allow internal and leaf volume attributes 2020-11-17 13:18:49 UTC
oVirt gerrit 94105 0 master ABANDONED tool: add update-volume command 2020-11-17 13:18:49 UTC
oVirt gerrit 94366 0 'None' ABANDONED api: update_volume on ResourceManager exception 2020-11-17 13:18:50 UTC
oVirt gerrit 94425 0 'None' ABANDONED storage: add update_volume tests without force 2020-11-17 13:19:12 UTC
oVirt gerrit 95258 0 'None' ABANDONED tool: add set-image-chain command 2020-11-17 13:18:51 UTC

Internal Links: 1489145 1545251

Description Gordon Watson 2017-07-11 15:46:06 UTC
Description of problem:

The 'LEGALITY' field in a volume's metadata can currently be modified by the 'vdsm-client' utility. It would be useful if this could be expanded to include the ability to modify the 'VOLTYPE', 'SIZE' and 'PUUID' fields.


Version-Release number of selected component (if applicable):

RHV 4.1


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Yaniv Kaul 2017-07-17 21:17:08 UTC
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.

Comment 3 Martin Perina 2017-07-20 10:32:58 UTC
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

Comment 4 Yaniv Kaul 2018-02-28 08:04:46 UTC
(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?)

Comment 5 Germano Veit Michel 2018-04-24 04:56:17 UTC
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.

Comment 6 Nir Soffer 2018-05-16 22:29:15 UTC
(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).

Comment 7 Germano Veit Michel 2018-05-16 23:15:26 UTC
(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.

Comment 8 Germano Veit Michel 2018-10-08 06:42:23 UTC
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)

Comment 9 Germano Veit Michel 2018-11-26 22:55:16 UTC
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.

Comment 10 Sandro Bonazzola 2019-01-28 09:40:18 UTC
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.

Comment 18 Jean-Louis Dupond 2020-11-09 14:56:29 UTC
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/)


Note You need to log in before you can comment on or make changes to this bug.