On 11/12/2012 12:19 PM, Andy Grover wrote: > On 11/08/2012 07:22 PM, Mike Christie wrote: >> On 11/08/2012 05:32 PM, Andy Grover wrote: >>> 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. > > Hi Mike, > > I familiarized myself with the code a little, but before diving in was > hoping to get guidance from you, which you've certainly provided. > >> 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. > > OK how is this object tree in representing what we want? > > a system has 1+ Nodes (iqns) > Nodes have 1+ Portals (IP addresses) > Portals have 1+ Sessions
I think I would add the iscsi connection in here too. Did LIO's MC/s feature get merged? > > ? We also want the hosts/ifaces/hw-ports. With that object or objects: - We need something to represent the iSCSI HBA, and its physical ports. We need to be able to set/get iscsi/net settings for these. - We need something to represent the iscsi initiator ports (depends on the representation of the node above). With the iface feature we can create multiple initiator names and control which sessions use which one. We also need the ability to control the iSID to fix the clustering issue where our iSID is not persistent. - We need to be able to be able to bind software iscsi sessions to specific netdevs (it could be a alias or vlan). - We need to be able to bind be able to bind iscsi normal sesisons to and do discovery through specific iscsi hba ports. Today, all this is mashed into the iscsi iface structs (there is a kernel one and userspace one). It represents virtual and physical iscsi/hw ports. > >> 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 agree that would be ideal eventually. I would think we can work on > libiscsiadm and then switch the tools to use the lib after that. As long as we know that libiscsi provides almost (there is probably some low level OS stuff that is not needed in a lib and is specific to iscsiadm) everything that the the iscsi tools needs, and we are not left in a situation like I described above where the lib uses some open-iscsi/usr and util code and we are stuck trying to update 2 code bases (the core open iscsi code and the lib) for a long time, then that is fine with me. > >> I think you also need to update the libiscsi_network_config struct or > [SNIP specific things needing fixing] > > OK will take a look at fixing. > >> 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 :) > > The on-disk format for idbm looks ok, I'm sure it won't be that bad :) Format might be sane. I am saying the code is crusty. Every release I say I am going to write a lib and update the tools, so I add a little bit more crust or let others add some junk thinking it does not matter since we are going to fix it in the end. That was 3 years ago :) -- 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.
