Conversation
fa373b7 to
b7d4937
Compare
Pull Request Test Coverage Report for Build 5245607799
💛 - Coveralls |
452e063 to
cd4d8dd
Compare
This comment was marked as resolved.
This comment was marked as resolved.
mvidner
left a comment
There was a problem hiding this comment.
This part is about the specific info that I miss in the API docs.
BTW, writing it in the ruby code where I commented it will unfortunately not make it visible at https://opensuse.github.io/agama/dbus/ , maybe I should add some dbus_annotation DSL to ruby-dbus (or even YARDoc comment conversion?)
d658a37 to
717906f
Compare
Yes, ideally I would like to write the documentation directly in the ruby code. Right now there is some duplication because I write some doc in ruby code and also in *.doc.xml. And sometimes I am not sure what to write in one place and the other. |
Problem
The storage service already provides a D-Bus API for managing iSCSI and DASD devices, but zFCP is not supported yet.
Solution
Add D-Bus API for managing zFCP devices (requires yast/yast-s390#105).
Show API
Follow-up:
zFCP controller deactivation
Directly deactivating a zFCP controller (e.g. chzdev -d 0.0.fa00) does not deactive its LUNs immediately. It takes some time (minutes) until its LUNs are deactivated (independently on the auto-lun-scan option).
That behaviour has some impact in YaST and Agama. For example:
The YaST module for managing zFCP devices does not offer an option for deactivating a zFCP controller. For now, the Agama D-Bus API will not offer it neither. Lacking of a deativate option has some implications if auto-lun-scan is active. With auto-lun-scan, the zFCP disks cannot be deactivated. So, after activating a controller, there is no way of undoing the disks activation.
Testing