[PATCH RFC] rm iscsi db
Mike Christie
The patch is no where near ready. It is buggy as heck, but I wanted to
get people's opinion on the file format and location of files and just
how people would like things to work.
I was pretty sleepy while I made this patch, so all I did was take the
code to parse /etc/iscsid.conf and make it work for writing config file.
This means the node config files have the same format as the iscsid.conf
file.
If I run
iscsiad -m discovery -t st -p mynetapp
In /etc/sysconfig/iscsi/ we have
[mnc@max iscsi]$ ls
initiatorname.iscsi nodes send_targets
initiatorname.iscsi is the file we all know and love but moved to the
sysconfig dir.
nodes is the dir of target nodes that were discovered or manually added
(you can manually add a target with iscsiadm or write it out by hand
with vi or emacs).
send_targets is the dir of discovery entities.
So looking around the FS we see:
[mnc@max iscsi]$ cd send_targets/
[mnc@max send_targets]$ ls
192.168.0.4,3260
192.168.0.4,3260 is a file for that entity/node. To see the value you
can just cat them out.
[mnc@max send_targets]$ cat 192.168.0.4,3260
discovery.startup = automatic
discovery.type = sendtargets
discovery.sendtargets.address = 192.168.0.4
discovery.sendtargets.port = 3260
discovery.sendtargets.continuous = 0
discovery.sendtargets.send_async_text = 0
discovery.sendtargets.auth.authmethod = None
discovery.sendtargets.auth.username = <empty>
discovery.sendtargets.auth.password = <empty>
discovery.sendtargets.auth.username_in = <empty>
discovery.sendtargets.auth.password_in = <empty>
discovery.sendtargets.timeo.login_timeout = 0
discovery.sendtargets.reopen_max = 0
discovery.sendtargets.timeo.auth_timeout = 0
discovery.sendtargets.timeo.active_timeout = 0
discovery.sendtargets.timeo.idle_timeout = 0
discovery.sendtargets.timeo.ping_timeout = 0
The nodes dir is what we know as the node records. In this example I
have one target with two portals.
[mnc@max iscsi]$ cd nodes/
[mnc@max nodes]$ ls
iqn.1992-08.com.netapp:sn.99920161
This is a dir that holds config files for each portal.
[mnc@max nodes]$ cd iqn.1992-08.com.netapp\:sn.99920161/
[mnc@max iqn.1992-08.com.netapp:sn.99920161]$ ls
192.168.0.100,3260 192.168.0.4,3260
192.168.0.100,3260 and 192.168.0.4,3260 are config files for each portal.
[mnc@max iqn.1992-08.com.netapp:sn.99920161]$ cat 192.168.0.100,3260
node.name = iqn.1992-08.com.netapp:sn.99920161
node.transport_name = tcp
node.tpgt = 1001
node.active_conn = 1
node.startup = manual
node.session.initial_cmdsn = 0
node.session.auth.authmethod = None
node.session.auth.username = <empty>
node.session.auth.password = <empty>
node.session.auth.username_in = <empty>
node.session.auth.password_in = <empty>
......
To login I would do:
iscsiadm -m node --targetname=iqn.1992-08.com.netapp:sn.99920161
--portal=192.168.0.100,3260 -l
to logout I would do
iscsiadm -m node --targetname=iqn.1992-08.com.netapp:sn.99920161
--portal=192.168.0.100,3260 -u
And for editing ops, you would use the same {targetname, portal} tuple
instead of the recid, or you can edit the config file with a editor.
You can also add a target manually using iscsiadm or you can add a
config file by hand.
So what do people think???
Michael Tokarev
> The attached patch removes the iscsi DB and replaces it with text files.
> The patch is no where near ready. It is buggy as heck, but I wanted to
> get people's opinion on the file format and location of files and just
> how people would like things to work.
>
> I was pretty sleepy while I made this patch, so all I did was take the
> code to parse /etc/iscsid.conf and make it work for writing config file.
> This means the node config files have the same format as the iscsid.conf
> file.
Ok, I'm also too sleepy now for useful comments.
But one note still.
Why /etc/sysconfig in the first place? As far as I remember, that
directory is a RedHat'ism of some sort. LSB does not mandate it,
and, for one, Debian does not have it at all. More, as it turns out,
there are (broken) tools out there wich tries to determine if we're
on redhat or not by checking if that directory is present.
BTW, Debian sure will patch out that /etc/sysconfig stuff when packaging
the tools, so we will have at least one incompatible distro.
I mean, why not /etc/iscsi for example ?
/mjt
[]
Robin H. Johnson
[snip]
> In /etc/sysconfig/iscsi/ we have
General question - why in /etc?
Given that /etc may be read-only at times, why not stick with
/var/db/iscsi/?
--
Robin Hugh Johnson
E-Mail : rob...@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Mike Christie
> On Tue, Jul 11, 2006 at 04:13:40PM -0500, Mike Christie wrote:
> [snip]
>> In /etc/sysconfig/iscsi/ we have
> General question - why in /etc?
> Given that /etc may be read-only at times, why not stick with
> /var/db/iscsi/?
>
See my comment to MichaelT.
Mike Christie
> Mike Christie wrote:
>> The attached patch removes the iscsi DB and replaces it with text files.
>> The patch is no where near ready. It is buggy as heck, but I wanted to
>> get people's opinion on the file format and location of files and just
>> how people would like things to work.
>>
>> I was pretty sleepy while I made this patch, so all I did was take the
>> code to parse /etc/iscsid.conf and make it work for writing config file.
>> This means the node config files have the same format as the iscsid.conf
>> file.
>
> Ok, I'm also too sleepy now for useful comments.
>
> But one note still.
>
> Why /etc/sysconfig in the first place? As far as I remember, that
> directory is a RedHat'ism of some sort. LSB does not mandate it,
I work at Red Hat and must have been drinking too much of the company's
Kool Aid ;)
I floated the idea around work first and so that is where the
/etc/sysconfig placement came from. I think I normally use Red Hat based
distros too and so it ended up that I did not know sysconfig was Red Hat
specific :) I personally do not care where we put it and it is not a
very big deal. It can be configurable if it needs to be.
Mika Bostrom
>
> iscsiadm -m node --targetname=iqn.1992-08.com.netapp:sn.99920161
> --portal=192.168.0.100,3260 -l
>
> to logout I would do
> iscsiadm -m node --targetname=iqn.1992-08.com.netapp:sn.99920161
> --portal=192.168.0.100,3260 -u
>
> And for editing ops, you would use the same {targetname, portal} tuple
> instead of the recid, or you can edit the config file with a editor.
I like this, and the reason is two-fold:
1. Adding new nodes or targets gets somewhat simpler, at least for
automation purposes
2. The tuple is the identifying data that the target operator can
provide their users with. Again, this helps scripting.
Getting the record id from discovery and storing that for further use
seemed somewhat difficult, and for no real reason from a user's point
of view.
So on my part this is a welcome change.
--
Mika Boström +358-40-525-7347 \-/ The flogging will
Bostik%iki.fi www.iki.fi/bostik X continue until
Security freak, and proud of it. /-\ morale improves
Hannes Reinecke
the db is a mess.
But I would indeed stick it into /etc/iscsi (or maybe /etc/open-iscsi to
not confuse nab) as /etc/sysconfig is used by distros for their own
configuration stuff. And I wouldn't wonder if some tools get confused if
there are unexpected things in it.
But in general a good idea. Having text files is much easier to maintain
and / or upgrade. But to be cautious: stick a version number in.
Otherwise we'll have a helluva time to figure out the upgrade mechanism.
Maybe we should just put a 'version' file in there; this can just hold
the current svn number or something.
And to not run into any future development trap:
If we ever were to do MC/S, is it possible / allowed to have different
settings per session?
If so, shouldn't we put a
node.session[0]
in the file?
Cheers,
Hannes
--
Dr. Hannes Reinecke ha...@suse.de
SuSE Linux Products GmbH S390 & zSeries
Maxfeldstraße 5 +49 911 74053 688
90409 Nürnberg http://www.suse.de
Dan Bar Dov
> -----Original Message-----
> From: open-...@googlegroups.com
> [mailto:open-...@googlegroups.com] On Behalf Of Mike Christie
> Sent: Wednesday, July 12, 2006 12:14 AM
> To: open-...@googlegroups.com
> Subject: [PATCH RFC] rm iscsi db
>
> The attached patch removes the iscsi DB and replaces it with
> text files.
> The patch is no where near ready. It is buggy as heck, but I wanted to
> get people's opinion on the file format and location of files and just
> how people would like things to work.
>
> I was pretty sleepy while I made this patch, so all I did was take the
> code to parse /etc/iscsid.conf and make it work for writing
> config file.
> This means the node config files have the same format as the
> iscsid.conf
> file.
>
> If I run
> iscsiad -m discovery -t st -p mynetapp
>
> In /etc/sysconfig/iscsi/ we have
I agree with the previous comments, and vote for /etc/iscsi,
I think the fact that /etc may be read-only at times is not important since this
is a location for configuration, and while /etc is read only, you're not likely
to do any configuration work anyway. I think the root fs is read only only in
single mode during boots. I think that during initrd, it is mounted rw making it
possible to run a discovery and then a login.
>
> [mnc@max iscsi]$ ls
> initiatorname.iscsi nodes send_targets
>
> initiatorname.iscsi is the file we all know and love but moved to the
> sysconfig dir.
>
> nodes is the dir of target nodes that were discovered or
> manually added
> (you can manually add a target with iscsiadm or write it out by hand
> with vi or emacs).
>
> send_targets is the dir of discovery entities.
Is it only for send_targets discovery records?
With a text configuration (which I like a lot), it would be simple to support
slp discovery and iSNS discovery. Do you envision a separate directory for
each discovery type?
I'm only raising the question, thinking about it I actually think it might be a
good idea since the discovery entities may have different naming schemes
and different contents.
I think these should also have the portal group tag like:
192.168.0.100,3260,1 and 192.168.0.4,3260,1
because a portal includes the tpgt. If you do stich the tpgt only inside the file
then you cannot have to different portals that differ only by the ptgt, and this is
allowed by the iscsi spec, and may also be usefull for HA configurations.
We "could" simplify that by stating that a portal without a ptgt in the name
defaults to 1.
>
>
> [mnc@max iqn.1992-08.com.netapp:sn.99920161]$ cat 192.168.0.100,3260
> node.name = iqn.1992-08.com.netapp:sn.99920161
> node.transport_name = tcp
> node.tpgt = 1001
> node.active_conn = 1
> node.startup = manual
> node.session.initial_cmdsn = 0
> node.session.auth.authmethod = None
> node.session.auth.username = <empty>
> node.session.auth.password = <empty>
> node.session.auth.username_in = <empty>
> node.session.auth.password_in = <empty>
>
> ......
>
>
> To login I would do:
>
> iscsiadm -m node --targetname=iqn.1992-08.com.netapp:sn.99920161
> --portal=192.168.0.100,3260 -l
>
> to logout I would do
> iscsiadm -m node --targetname=iqn.1992-08.com.netapp:sn.99920161
> --portal=192.168.0.100,3260 -u
>
> And for editing ops, you would use the same {targetname, portal} tuple
> instead of the recid, or you can edit the config file with a editor.
>
> You can also add a target manually using iscsiadm or you can add a
> config file by hand.
Great, and also by an SLP and iSNS tools.
>
>
> So what do people think???
We think you're doing a great job!
Dan
Mike Christie
There are a couple of other read only root situations. Someone may setup
root as read only if they are sharing the partition with many clients at
the same time like is done with NFS.
Red Hat has a stateless linux effort, SUSE probably does too, and some
vendors are also looking into something similar. These setups throw some
kinks into this, but I thinik they assume that discovering new targets
or nfs servers is rare and will be done before hand. How they plan to
allow you do update some of this stuff will be interesting.
>
>> [mnc@max iscsi]$ ls
>> initiatorname.iscsi nodes send_targets
>>
>> initiatorname.iscsi is the file we all know and love but moved to the
>> sysconfig dir.
>>
>> nodes is the dir of target nodes that were discovered or
>> manually added
>> (you can manually add a target with iscsiadm or write it out by hand
>> with vi or emacs).
>>
>> send_targets is the dir of discovery entities.
>
> Is it only for send_targets discovery records?
That dir yes.
> With a text configuration (which I like a lot), it would be simple to support
> slp discovery and iSNS discovery. Do you envision a separate directory for
> each discovery type?
I was thinking that SLP and iSNS will have different dirs.
Mostly this was done out of laziness. If I had a general discovery dir
then to find the send targets ons I would have to either open each file
and check the discovery type or name the file with some pre/post fix
indicating what type it was.
Really, I think we need to think this from user perspective. Do users
want to edit files by hand and if so does the format I propose make any
sense? Right now, the format of the dirs and config file was due to
programming ease.
Are you sure about this bit? In the RFC it says the portal is the ip and
port (def of a network portal in the RFC).
> then you cannot have to different portals that differ only by the ptgt, and this is
> allowed by the iscsi spec, and may also be usefull for HA configurations.
Are you sure about this bit? I think I am not understanding what you
wrote. The portals there are defined under a target node so if I have
192.168.0.100,3260,1,tgpt=2
192.168.0.100,3260,1,tpgt=1
This would be the same portal but under different portal groups but on
the same node. In the RFC under the definition of the Portal Group there
is this bit:
Each Network Portal, as utilized by a given iSCSI Node, belongs to
exactly one portal group within that node.
So from that and my understnding of the portal definition, the
192.168.0.100,3260,1,tgpt=2
192.168.0.100,3260,1,tpgt=1
would not be valid and either the ip or port would have to be different.