feat(storage): Add auto-installation support for iSCSI

[joseivanlopez]

Add auto-installation support for configuring iSCSI.

Main changes:

• Extend profile schema to include an iscsi section.
• Extend D-Bus API:
  • Export object /org.opensuse/Agama/Storage1/ISCSI.
  • Provide #SetConfig method.
• Extend HTTP API:
  • Add endpoint /iscsi/config (post)
  • Add endpoint /iscsi/issues (get)
  • Set iSCSI config before setting storage config (e.g., config load).

Out of scope:

• Export iSCSI config (#GetConfig).
• AutoYaST conversion (will be addressed in a separate card).
• UI migration to the new iSCSI API (has to be evaluated).

[mvidner]

FYI, the problem with returning the wrong type for the CurrentStep property and ruby-dbus correctly failing but not telling you which property is the problem: being addressed in mvidner/ruby-dbus#147

[ancorgs]

Added some inline comments for minor things.

Other than that, I have mixed feelings about the commit titled "Add iSCSI Adapter". It somehow looks like making the code less object oriented and encapsulated.

Just to clarify, "mixed feelings" doesn't mean I think it is wrong. I would go on and merge as it is (after processing the inline comments), because I think it has advantages and the drawbacks may only be my personal impression.

Having said that, let me elaborate.

Before that commit there is a mixin WithIscsiAuth that is in charge of building the authentication hash from the whole struct (ie. to know what are the fields that are relevant for authentication). After the commit, the mixin is gone and that filtering of relevant fields is repeated in a couple of places.

On the other hand, before the commit the classes Initiator and Manager act as some kind of model for the business logic, encapsulating the data and its manipulation. After that, all manipulation is extracted to Adapter, which is a good step regarding single responsibility but also feels like a class that simply holds a bunch of methods in a similar way than YaST modules used to do things.

[joseivanlopez]

Before that commit there is a mixin WithIscsiAuth that is in charge of building the authentication hash from the whole struct (ie. to know what are the fields that are relevant for authentication). After the commit, the mixin is gone and that filtering of relevant fields is repeated in a couple of places.

Yes, the credentials hash is built in 3 different places: Storage1.ISCSI.Node#Login, Storage1.ISCSI.Initiator#Dicover and Storage1.ISCSI#SetConfig. Only the first two are built exactly in the same way (using the very same D-Bus options). The last one is built by the config importer. I removed the mixin because the code for building the credentials is quite trivial and it is repeated only once (hopefully temporary if we finally refac ISCSI APIs). Should I bring a mixin back for building the hash?

On the other hand, before the commit the classes Initiator and Manager act as some kind of model for the business logic, encapsulating the data and its manipulation. After that, all manipulation is extracted to Adapter, which is a good step regarding single responsibility but also feels like a class that simply holds a bunch of methods in a similar way than YaST modules used to do things.

Yes, currently both Initiator and Node classes are there only for representing "probed devices". The adapter concept was added to follow the network approach.

[ancorgs]

LGTM