Description of problem: On REST-API, in storage domain with unregister disk under storagedomains/{doamin-id}/disks;unregistered, Action 'register' to disk is missing. Currently the command to register unregistered disk using REST is: /api/storagedomains/{domain-id}/disks;unregistered <disk id='{the id of the disk to be registered}'></disk> To register unregistered VM/Template from storage domain the command is: /api/storagedomains/{domain-id}/vms|templates/{vm/template-id}/register <action> <cluster id='xxxxxxx-xxxx-xxxx-xxxxxx'></cluster> </action> Register Disk should be in the same way as register VM or Template. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1.Create a floating disk on storage domain 2.Detach the storage domain from the data-center 3.Attach the storage domain from step 2 back to the data center 4.Using REST - /api/storagedomains/{domain-id}/disks;unregistered <disk id='{the id of the disk to be registered}'></disk> Actual results: Expected results: Additional info:
Furthermore, The job notification for disk registration is - Registering Disk ... And for registering Vm or template is: Importing Template/VM ... The notification should be consistent.
I've uploaded a patch which fixes the job issue (see https://gerrit.ovirt.org/#/c/62407). Eyal, if you think it should be verified or backported please open a separate bug on it. Regarding the register disk operation in REST, this operation was introduced before the import VM/Template (IINM at version 3.3) and it is also being used for other operations except DR, like moving netapp disks to oVirt storage domains. Replacing the existing API might reflect on existing REST scripts, so we can do one of the following: 1) Add a new API so register disk will be executed in both ways. 2) Change the existing API to be compatible with import VM/Template and add a doc text. 3) Leave the API as it is
If I understand correctly retrieving an unregistered disk doesn't register it. I mean, if you send this request: GET /storagedomains/{storagedomain:id}/disks/{disk:id};unregistered What you get is the description of that disk, but it will stay unregistered. There is actually now way to register the disk, so adding a new "register" operation to the disk doesn't break backwards compatibility, in my opinion is perfectly OK to add it. It should work as follows: POST /storagedomains/{storagedomain:id}/disks/{disk:id}/register <action/> If parameters are needed they should go inside the "action" tag.
I meant "there is *no* way to register the disk", sorry.
(In reply to Juan Hernández from comment #3) > If I understand correctly retrieving an unregistered disk doesn't register > it. I mean, if you send this request: > > GET /storagedomains/{storagedomain:id}/disks/{disk:id};unregistered If you will use POST and use the same API and add the disk id, as so: POST /api/storagedomains/60cec75d-f01d-44a0-9c75-8b415547bc3d/disks;unregistered HTTP/1.1 Accept: application/xml Content-type: application/xml <disk id='8ddb988f-6ab8-4c19-9ea0-b03ab3035347'></disk> It should register it to the DB. > > What you get is the description of that disk, but it will stay unregistered. > There is actually now way to register the disk, so adding a new "register" > operation to the disk doesn't break backwards compatibility, in my opinion > is perfectly OK to add it. It should work as follows: > > POST /storagedomains/{storagedomain:id}/disks/{disk:id}/register > <action/> > > If parameters are needed they should go inside the "action" tag.
Thanks Maor, you are right. As there is already a way to register the disk I think that we can consider this a "nice to have", thus lowering the severity and retargetting to 4.1.
(In reply to Juan Hernández from comment #6) > Thanks Maor, you are right. As there is already a way to register the disk I > think that we can consider this a "nice to have", thus lowering the severity > and retargetting to 4.1. Agreed.
The changes to the specification required for this fix are too risky for 4.1. I am re-targeting to 4.2.
Maor, all the attached patches are merged. Are we missing anything else?
(In reply to Allon Mureinik from comment #9) > Maor, all the attached patches are merged. Are we missing anything else? Yes, we need to implement this in the backend as well, I will update the bug to new until I will get to it.
(In reply to Maor from comment #10) > (In reply to Allon Mureinik from comment #9) > > Maor, all the attached patches are merged. Are we missing anything else? > > Yes, we need to implement this in the backend as well, I will update the bug > to new until I will get to it. Any updates?
(In reply to Yaniv Kaul from comment #11) > (In reply to Maor from comment #10) > > (In reply to Allon Mureinik from comment #9) > > > Maor, all the attached patches are merged. Are we missing anything else? > > > > Yes, we need to implement this in the backend as well, I will update the bug > > to new until I will get to it. > > Any updates? Posted a patch, should be merged soon
Maor, I still can't find the unregistered disks under /api/storagedomains/%domainid%/disks/ The unregistered disk exist under /api/storagedomains/%domainid%/disks;
*The unregistered disk exist under /api/storagedomains/%domainid%/disks;unregistered
It is now done through an attached storage domain. The API is: /api/datacenters/111/storagedomains/222/disks/333/register
Maor, still can't find the unregistered disk under /api/datacenters/%id%/storagedomains/%id%/disks While in Webadmin, the disk is listed under Disk import.
Try to add ";unregistered" at the end: api/datacenters/%id&/storagedomains/%id&/disks;unregistered
POST to: /api/datacenters/111/storagedomains/222/disks/333/register with <action></action> For an unregistered disk works properly. Verified using: ovirt-engine-4.2.0-0.0.master.20170929123516.git007c392.el7.centos.noarch ovirt-engine-restapi-4.2.0-0.0.master.20170929123516.git007c392.el7.centos.noarch
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.