Bug 1439692
| Summary: | Unable to determine the correct call signature for deleteluns | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Kapetanakis Giannis <bilias> | ||||
| Component: | BLL.Storage | Assignee: | Idan Shaby <ishaby> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Elad <ebenahar> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 4.1.1.8 | CC: | amureini, bilias, bugs, derez, ishaby, laravot, lveyde, stirabos, tnisan | ||||
| Target Milestone: | ovirt-4.1.3 | Flags: | rule-engine:
ovirt-4.1+
amureini: devel_ack+ |
||||
| Target Release: | 4.1.3 | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2017-07-06 13:36:00 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | Storage | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Kapetanakis Giannis
2017-04-06 12:07:39 UTC
Looking through the code history, frankly, I'm not sure how (if?) this ever worked. Should be a reasonably easy fix to deliver in 4.1.2 though. Is it related to bug 1403839 ? (In reply to Kapetanakis Giannis from comment #2) > Is it related to bug 1403839 ? Not as far as I can tell. But perhaps Liron (who implemented that RFE) would have a different insight. Liron? (In reply to Allon Mureinik from comment #3) > (In reply to Kapetanakis Giannis from comment #2) > > Is it related to bug 1403839 ? > > Not as far as I can tell. But perhaps Liron (who implemented that RFE) would > have a different insight. > Liron? Hi Giannis/Aloon This RFE isn't related to that issue - the issue is in a different flow. I see that Allon already sent a fix, so it should be merged soon. Regards, Liron Allon/Liron, can you please add steps to reproduce? To be completely honest, I worked back from the stack trace, created a DAO test and developed the fix based on that. From reading the code, this faulty call should occur when you activate a block domain and the database has an old lun that isn't returned by getVGInfo. I think the easiest way to simulate this is to move a block domain to maintenance and then manually insert a row to the "luns" table. Unless Kapetanakis has a better suggestion? no suggestion from me :) Set block domain to maintenance and inserted a line to 'luns' table:
engine=# insert INTO luns values ('lun','lun','lun','lun','3','lun','lun','10','233','t');
INSERT 0 1
physical_volume_id | lun_id
----------------------------------------+-------------------
XJRsDH-13bf-29bB-6c9G-6vMP-j3pL-CXr3XI | 3514f0c5a516004ac
2Vlo30-ciJY-d6xf-zEVz-YYY8-sbKl-IVJWEB | 3514f0c5a516004ab
DSbwKT-rGJu-aOma-G8lf-vg9q-Yk52-ds4TZf | 3514f0c5a516004aa
4fpBIy-Hpxg-P0Ej-t9db-ZZt7-N4Ge-vloyaS | 3514f0c5a51600215
L7XnOI-A5r1-B8uq-gaOH-Sgbd-ySoB-mWDbdG | 3514f0c5a51600213
LJmZ5x-0avg-rS32-fyOw-1SdW-nLHY-m0fkQh | 3514f0c5a516004ad
lun | lun
T3SH1U-sgQq-ItqR-wl4h-1ZpY-NJiC-VQEm0X | 3514f0c5a51600214
(8 rows)
Then, activated the domain. The LUN wasn't removed from 'luns' table.
Allon, what am I missing?
Used: rhevm-4.1.2-0.1.el7.noarch (In reply to Elad from comment #8) > Set block domain to maintenance and inserted a line to 'luns' table: > > engine=# insert INTO luns values > ('lun','lun','lun','lun','3','lun','lun','10','233','t'); > INSERT 0 1 > > physical_volume_id | lun_id > ----------------------------------------+------------------- > XJRsDH-13bf-29bB-6c9G-6vMP-j3pL-CXr3XI | 3514f0c5a516004ac > 2Vlo30-ciJY-d6xf-zEVz-YYY8-sbKl-IVJWEB | 3514f0c5a516004ab > DSbwKT-rGJu-aOma-G8lf-vg9q-Yk52-ds4TZf | 3514f0c5a516004aa > 4fpBIy-Hpxg-P0Ej-t9db-ZZt7-N4Ge-vloyaS | 3514f0c5a51600215 > L7XnOI-A5r1-B8uq-gaOH-Sgbd-ySoB-mWDbdG | 3514f0c5a51600213 > LJmZ5x-0avg-rS32-fyOw-1SdW-nLHY-m0fkQh | 3514f0c5a516004ad > lun | lun > T3SH1U-sgQq-ItqR-wl4h-1ZpY-NJiC-VQEm0X | 3514f0c5a51600214 > (8 rows) > > > > Then, activated the domain. The LUN wasn't removed from 'luns' table. > > Allon, what am I missing? This LUN is unrelated to the domain you're activating, so it won't be affected. You need to set the volume_group_id column to match the domain's. Thanks Allon.
Inserted the following row to 'luns' table while iscsi domain with VG UUID is vj7PzK-pAUn-u6tC-mgLG-0mKV-G9f9-8tGsQy was in maintenance (iscsi_0).
storage_name | status
------------------------+--------
rhevm-qe-infra-glance |
ovirt-image-repository |
iscsi_1 | 3
fcp_1 | 3
test_gluster_1 | 3
nfs_1 | 3
fcp_2 | 3
fcp_0 | 3
nfs_0 | 3
nfs_2 | 3
export_domain | 3
test_gluster_2 | 3
test_gluster_0 | 3
iscsi_2 | 3
iscsi_0 | 6
(15 rows)
engine=# insert INTO luns values ('pv_id','lun_id','vj7PzK-pAUn-u6tC-mgLG-0mKV-G9f9-8tGsQy','serial','3','vendor','product','11','233','t');
Then, activated the domain. The row didn't get removed upon domain activation.
Logs will be provided.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release. Created attachment 1277090 [details]
engine.log
The urgent part for 4.1.2 is that the activate should succeed, which it does. The remaining LUN that Elad reported in comment 11 is obviously still a bug though. Idan - can you look into this please? Yes, sure. I will soon push a fix for it. Inserted the following row to 'luns' table while iscsi domain with VG UUID is 8murUB-rAYZ-y63c-Oljm-bjy3-3Lwe-o7cDJ5 was in maintenance (iscsi_0). After domain activation, the inserted row got removed from luns table. Tested using: rhevm-4.1.3.1-0.1.el7.noarch postgresql-9.2.18-1.el7.x86_64 vdsm-4.19.17-1.el7ev.x86_64 * The row instereted to luns table:
insert INTO luns values ('pv_id','lun_id','8murUB-rAYZ-y63c-Oljm-bjy3-3Lwe-o7cDJ5','serial','3','vendor','product','11','233','t');
|