On Mon, Jul 28, 2014 at 12:31:57PM +0200, u-codalist-z149_at_aetey.se wrote:
> 1. realm => volume location service
...
> Currently step 1 is implemented via DNS but it does not seem to
> provide for any data expiration/renewal (?) besides by manually
> running cfs check<something> on a client (?)

We iterate through the servers and redo the SRV lookup when we fail to
connect to all of them.

> DNS provides sufficient means to handle the task.
> I suggest moving the step 2.3 to the client, to address the limitation
> of the current design. The mapping in this step is not security-critical
> and hence can be delegated to DNS.
> 
> Jan's intention was to split 2.3 into
> 
>        2.3.1 server-numeric-id => (f.q.d.n,numeric-port)
>              inside the VLS
> 
>        2.3.2 f.q.d.n => numeric-ip
>              on the clent, via DNS

That is deceptive because currently all of step 2 is a single
GetVolumeInfo RPC2 call. So you cannot really split out just 2.3, and
then make my approach look more complicated by splitting your step
2.3 into 2 additional steps. Both approaches are really pretty similar
in what is looked up.

I only added a pair of (per-replica) lookups to the normal
ViceGetVolumeInfo call, one of which is already implemented.

    - volume name -> replica volume ids (implemented, ViceGetVolumeInfo)
    - replica volume id -> FQDN:port    (implemented, ViceGetVolumeLocation)
    - FQDN -> one or more valid IP addresses, on the client using DNS
                                        (not yet implemented)

> Which for my eyes keeps a burden on VLS which can/should be delegated to
> DNS as well, for reduced complexity and better clarity.

The volume location service has to track which replicas belong to a
volume anyway, and the server has to know where replicas are located.

> ========================================
> 
> The issues to address:
> 
> - is it actually correct to let server-id be public information?

Not really an issue, it is more, is the namespace you want to use to
talk about servers based on numbers that have somewhat odd properties
like be 8-bit and avoid 0,127 and 255. Or use regular old DNS name
resolution which can handle ipv4/ipv6, multi-homed hosts, internal vs.
public addresses etc.

> Is there a better approach?

Devils advocate here, get rid of the volume location service completly
and put everything into DNS with volumename.<realm> DNS records.

Jan