Subject: [nfsv4] Server to server connectivity consistency?(Was: server-side copy offload I-D)

From: "Erasani, Pranoop" <[email-masked]>
Date: Sat, 4 Apr 2009 03:47:26 -0700

Sorry, decied to use separate threads for better tracking of individual
issues.
 
So, I see discussion around holes in connectivity between servers. Is
there a consensus to write a new COPY operation that essentially will
ping the destination to get the list of addresses that will be used by
source to authorize the I/O's against.
 
The spec sayd hostnames could be part of netloc4. However, even if we
have the client mediate the hostname/IP addresses between destination
and source, we cannot guarantee the authorization works fine. That's due
to the fact that the source and destination could be talking to
different name services. How do we ensure that? Do we want to call that
out explicitly? Do both servers need to be in the same name service
administrative domain?
 
- Pranoop

---

From: anshul <[email-masked]>
Date: Sat, 04 Apr 2009 17:08:15 +0530

On Sat, 2009-04-04 at 03:47 -0700, Erasani, Pranoop wrote:
> Sorry, decied to use separate threads for better tracking of
> individual issues.
>  
> and source, we cannot guarantee the authorization works fine. That's
> due to the fact that the source and destination could be talking to
> different name services. How do we ensure that? Do we want to call
> that out explicitly? Do both servers need to be in the same name
> service administrative domain?

Yes hostnames should work if both servers are in the same administrative
domain. I think we should try to clarify the related text.

Regards,
Anshul

>  
> - Pranoop
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "Erasani, Pranoop" <[email-masked]>
Date: Sat, 4 Apr 2009 10:44:51 -0700

> Yes hostnames should work if both servers are in the same 
> administrative domain. I think we should try to clarify the 
> related text.

What would be the answer/clarification? Both Servers MUST be in the same
administrative domain?

So, I guess what I'd like to know is how do you infer they have a common
administrative domain i.e how does a client ensure that the information
that it got from the destination works fine for the source. If the
client cannot ensure that, what is the point of client asking
destination the list of all server(s)/hostnames(s)?

I am particularly interested in how source and destination deal with
hostname aliases.

Bottomline, both the source and destination do not talk to each other
(for I/O) until COPY_NOTIFY and COPY are successful. And destination may
think it gave the right aliases to connect and source is expecting that
the client could connect with it's view of alias resolution. Don't we
need to have a handshake betweent the source and destination before we
can be sure of successful transfer? Meaning, client is moderating, but
both servers could be out of sync with their administrative data. Right?

- Pranoop

---

From: anshul <[email-masked]>
Date: Sun, 05 Apr 2009 13:27:12 +0530

> destination the list of all server(s)/hostnames(s)?

Right now the client cannot , but the system administrator can ensure
everything works fine.

> I am particularly interested in how source and destination deal with

When the client C queries destination D for its list of hostnames, does
the destination need to return the aliases, can't it just return the
official server name? See my answer below.

The official server names would be used in the COPY_NOTIFY. And when the
destination communicates with the source, the source would map the
incoming destination IP to the official server name anyway, the aliases
won't be considered.

> both servers could be out of sync with their administrative data. Right?

I guess we could, alternative would be that their administrative data is
synchronized by administrator, right?

Regards,
Anshul

---

From: "Erasani, Pranoop" <[email-masked]>
Date: Sun, 5 Apr 2009 03:21:34 -0700

> When the client C queries destination D for its list of 
> hostnames, does the destination need to return the aliases, 
> can't it just return the official server name? See my answer below.

What is official server name? I accept "alias" is a poor choice of word
on my part. What if my hostname is "X" (no FQDN). Call it official, or
call it an alias, the name is plain straight "X".

Let's say source and destination both are connected to name services
that have X, but pointing to different IP's. Wouldn't the source reject
the request based on the authoriazation data?

> The official server names would be used in the COPY_NOTIFY. 
> And when the destination communicates with the source, the 
> source would map the incoming destination IP to the official 
> server name anyway, the aliases won't be considered.

Why? It depends on the configuration. You cannot say that.

> > (for I/O) until COPY_NOTIFY and COPY are successful. And 
> destination 
> > may think it gave the right aliases to connect and source 
> is expecting 
> > that the client could connect with it's view of alias resolution. 
> > Don't we need to have a handshake betweent the source and 
> destination 
> > before we can be sure of successful transfer? Meaning, client is 
> > moderating, but both servers could be out of sync with 
> their administrative data. Right?
> 
> I guess we could, alternative would be that their 
> administrative data is synchronized by administrator, right?

You bet we could. Ok. The complexity is pushed to the administrator to
maintain the information. Spell it out please.

Either spec has to make it clear that both source and destination have
to be in the same administrative domain OR you have to spell MUST
against the fact that the admin data needs to be synchronized by the
administrator. I'm interested in what kind of qualifier you are gonna
use to describe this in the specification. I do believe the spec should
encourage the usage of IP's more than the hostnames/alias in general.

BTW, Where is the error code to describe the fact that source could not
be connected to by destination for succesfull initiation of transfer?
The only errors I see are:

   The CB_COPY operation may fail for the following reasons:

   NFS4ERR_NOSUPP:  The copy offload operation is not supported by the
      NFS client receiving this request.

Thanks,
- Pranoop

---

From: anshul <[email-masked]>
Date: Mon, 06 Apr 2009 16:46:40 +0530

> call it an alias, the name is plain straight "X".

See my reply below.

> the request based on the authoriazation data?

Yes if X is an valid hostname corresponding to the destination and if
the configuration is not appropriate.

> Why? It depends on the configuration. You cannot say that.

Yes it depends on configuration. But if configuration is the same, then
I can say that.

For setting up reverse name lookup in DNS, we require a PTR record, that
maps the IP to one hostname. And for setting up aliases, we need to use
CNAME records, that define aliases for a particular hostname.

And aliases are setup on /etc/hosts as follows -
172.234.23.1   hostname.domainname    alias1 alias2

By official server name(which may not have been the right word to use on
my part), I was referring to the hostname that the IP maps to in the PTR
record (or in case of /etc/hosts - hostname.domainname). I'm still using
the term official server name below.

So when the client queries the destination for its list of hostnames,
the destination can return the official server names(corresponding to
each of its IP addresses). So the official server name is unique, even
when aliases have been setup in the name servers.

> administrator. 

Yes Agreed, We will clarify the text.

> I'm interested in what kind of qualifier you are gonna

If the scenario you describe were to occur, then the COPY would fail,
not the CB_COPY.

Regards,
Anshul

---

From: "Erasani, Pranoop" <[email-masked]>
Date: Mon, 6 Apr 2009 12:46:15 -0700

> > > And when the destination communicates with the source, the source 
> > > would map the incoming destination IP to the official server name 
> > > anyway, the aliases won't be considered.
> > 
> Yes it depends on configuration. But if configuration is the 
> same, then I can say that.

But, I'm not asking you about that. Also, I'm not looking forward to a
primer on DNS.

All I'm asking is how does this reconcile to such an admin-driven
environment. Meaning, you require certain set of configuration to
facilitate a COPY and that should be made explicit.

> Yes Agreed, We will clarify the text.

Thanks. I will wait for the next version of it.

> > 
> > BTW, Where is the error code to describe the fact that source could 
> > not be connected to by destination for succesfull 
> initiation of transfer?
> If the scenario you describe were to occur, then the COPY 
> would fail, not the CB_COPY.

Wait a minute. Isn't COPY an asynchronous operation. Meaning COPY would
return immediately. Or you expect the destination to communicate with
source before COPY is replied to?

- Pranoop

---

From: anshul <[email-masked]>
Date: Tue, 07 Apr 2009 12:49:40 +0530

> source before COPY is replied to?

When the COPY is asynchronous, the COPY reply contains a copy stateid - used by client in subsequent COPY_STATUS and COPY_ABORT operations. 
Thus the destination needs to start the copy offload before replying and thus 
it would have to communicate with source before COPY is replied to.

Regards,
Anshul