Hi! Accidentially yesterday I was thinking that some graphical frontend (like "hawk for clusters) would be nice for iSCSI.
If I'd design a interface library, I'd use a two-level approach: The higher level would provide interfaces at an abstract level (like: start_discovery, login_target, delete_target, ...) while the lower level would interface directly to open-iscsi. They mabe if the open-iscsi interfaces change som time, the higher level interfaces wouldn't be affected (in theory). I haven't looked into the code, but occasionally it's worth to start freshly rather than to adapt some old code in the long run. MHO. Ulrich >>> Mike Christie <[email protected]> schrieb am 09.11.2012 um 04:22 in Nachricht <[email protected]>: > On 11/08/2012 05:32 PM, Andy Grover wrote: > > Hi Mike and everybody, > > > > The Red Hat packaging of open-iscsi (iscsi-initiator-utils) has > > contained C and Python libraries for open-iscsi since 2009. These have > > been used only by the Anaconda installer, and haven't been pushed upstream. > > > > > Have you reviewed the lib yourself and what do you think it needs? Not > putting you on the spot. Just want to know where we are starting from. I > just briefly looked at the code and was not sure what has changed since > I last worked on it. > > > My issue was that it was nice for what we used it for in RHEL/fedora, > but it needs some updating. It is based on a confusing open-iscsi'ism > where the node is actually a portal. And actually it represents more. It > is more like a set of objects (target, portal, initiator/initiator-port) > to create N sessions with. > > We should define a lib that is more based on the iscsi RFC and how it is > implemented in linux and the iscsi ima lib (at least make it so vendors > using IMA can use our lib so they do not have to call iscsiadm or modify > iscsiadm in weird ways). Fix the definition of a node/target, portal, > etc so it is not defined as a result of the crustiness of the tools and > how they grew over time. > > > I would like the iscsi tools to be able to use the iscsi lib's exported > API. Almost everything iscsiadm wants to do, other tools wants to do > too. I am not sure if this a hard requirement though. However, the > current way that the tools and lib are built is not nice. It is too > fragile to changes in the code that is shared. > > > I think you also need to update the libiscsi_network_config struct or > redfine it so it handles vlans, ipv6 settings and the tcp/net options > qlogic has been posting about, and whatever else is missing or define > the interface in a way that we can easily update it while maintaining > compat. > > I think libiscsi_set_netconfig is the wrong. It assumes that the net > config is done in the kernel. It can be done in kernel for > qla4xxx/be2iscsi, but is done by a combo of iscsiuio/kernel in bnx2i and > for cxgb*i it is iscsid/kernel. We could have a call that passes data > directly to the kernel for testing or other developer reasons, but it > should not be named something generic like libiscsi_set_netconfig. We > should have a generic call to config networking for the cards, so apps > do not have to know the implementation details. > > > libiscsi_get_firmware_initiator_name is based on the assumption that > there is only 1 ibft initiator. We can do boot through multiple > cards/ports and they can have different initiator names. > > > libiscsi_discover_sendtargets_by_hwaddr and > libiscsi_discover_sendtargets is sort of weird. The former only supports > be2iscsi/qla4xx and the latter only supports software iscsi. We are > missing bnx2i/cxgb*i/iser. I also do not think the caller should have to > know the implementation details for what function to call. For software > iscsi we would also want to handle when they user wants to do iface binding. > > When I was working on the lib I wanted to rewrite the tools. They have > got really crusty due to trying to maintain compat (the sysfs and idbm > code are crazy). They were also written when we did not know how all > iscsi hw would work and we were basically wrong at every point :) > > I think maybe starting by specifying the objects we want to manage and > get info about and what we want to do with those objects would be best??? -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
