[
https://issues.apache.org/jira/browse/CRAIL-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16786000#comment-16786000
]
David Crespi commented on CRAIL-93:
-----------------------------------
I understand your config. Were doing the same thing from different approaches.
I’m not saying the spec doesn’t require it, I was saying that crail seemed to
not connect when using my subsystem names and the allow all host option set.
As I stated in the last response, I may have gotten this wrong as it was late,
I just need to go back and verify that it does indeed work using my NQN’s (one
with my NQN and one with my NQNport#).
And I think I’m getting a much better understanding now of slide 9. So thanks
for the clarification.
I do have one additional question now. For slide 9 to work properly, it is
assumed that Crail and the Client(s) blocks are using a shared namespace… is
this correct? Is that why you created the hack with the subsystemNQN and
subsystemNQNport#?
FYI – my background is in Fibre Channel SANs and SCSI, so the NVMe stuff is a
bit new to me.
To summarize my “current” understanding of what you’ve so patiently stated in
your responses is:
Crail is attaching to the target, in my example this would be:
nqn.2018-12.com.StorEdgeSystems:cntlr94420
and crail would have a namespace attached to this subsystem as NVME_NAMESPACE:1
Which, just for clarity, could be identified in SPDK as say namespace name:
RAID1, which has namespace id: 1
The client, which for our example, is a spark node would be also attaching to
the target as:
nqn.2018-12.com.StorEdgeSystems:cntlr9
and spark would have a namespace attached to this subsystem as NAMESPACE:1
which ALSO would have that namespace attached to this subsystem as NAMESPACE:1
and this namespace name would also be: RAID1.
So Crail is setting up the infrastructure for Spark, and Spark is supplying the
data.
Is my current understanding correct?
Regards,
David
> Using Crail with NVMf, the Default NQN also attaches the port number to the
> name.
> ---------------------------------------------------------------------------------
>
> Key: CRAIL-93
> URL: https://issues.apache.org/jira/browse/CRAIL-93
> Project: Apache Crail
> Issue Type: Bug
> Affects Versions: 1.2
> Environment: I'm running crail nodes with docker containers, on a
> Ubuntu 18.04 base.
> Reporter: David Crespi
> Assignee: Jonas Pfefferle
> Priority: Critical
>
> This is the version I'm actually using: v1.1-2-gf0afadc
> I'm set up to use spdk on the backend to crail. When attempting to attach,
> it appears that crail needs two subsystems to achieve the connection. Instead
> of allowing the default name, I have the system variable set: -e
> NVMF_NQN="nqn.2017-06.io.crail:cnode"
> 1) subsystem NQN: nqn.2017-06.io.crail:cnode
> 2) subsystem NQN: nqn.2017-06.io.crail:cnode4420
> 19/03/01 17:46:45 INFO crail: CrailHadoopFileSystem fs initialization done..
> 19/03/01 17:46:45 INFO crail: Connecting to NVMf target at Transport address
> = /192.168.2.104:4420, subsystem NQN = nqn.2017-06.io.crail:cnode4420
> It appears that the initial connect/discovery of the subsystem uses #1, but
> using the
> crail commands (crail fs -mkdir /test) uses #2.
> Both have to have a valid namespace attached as well.
>
> It also appears that when using my own subsystem NQN (NVMF_NQN) name, crail
> wants to generate its own Host NQN. A new one every time. First, how do you
> learn of that
> NQN, and 2nd, it would be great to disable it if spdk has "allow any hosts"
> set. It refuses
> to connect to spdk.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
