[Gluster-devel] volume stanzas for non-existent directories in server volume specification

[Brandon Lamb]

On Thu, May 1, 2008 at 2:22 PM, John Marshall <John.Marshall at ec.gc.ca> wrote:
> Brandon Lamb wrote:
> >
> > On Thu, May 1, 2008 at 1:49 PM, John Marshall <John.Marshall at ec.gc.ca>
> wrote:
> >
> >
> >
> > > My question comes from wanting to export multiple, differently named,
> > > directories from different hosts (assume 1 dir/host). Must I create a
> > > separate server volume spec for each host, or can I simply put all the
> > > information into one spec file and ignore the errors?
> > >
> > >
> > >
> > > Thanks,
> > > John
> > >
> > >
> >
> > If the directory names are different on all of your servers, then yes
> > they will all have different spec files. Using a single spec file that
> > is identical on all servers would assume that the volume you are
> > exporting has the same exact directory name on all servers.
> >
> > So in your case, your server spec files will be *mostly* identical
> > except for the "option directory <DIRECTORY>" line which will point to
> > the volume directory for the given server.
> >
> >
>
> Are separate spec files a _must_? Now and in the future? I'd prefer to
> manage a single file (even if there are non-fatal errors) than many. Of
> course, the examples allow for a brick and brick-ns in the specification,
> which makes them simple.
>
> Might there be any interest in supporting an option which allows for a
> single server volume spec file to be used but to not cause errors? E.g.,
>
> -----
> volume a
>   ...
>   option directory /data/a
>   option hosts host-a1, host-a2
> end-volume
>
> volume b
>   ...
>   option directory /data/b
>   option hosts host-b1, host-b2
> end-volume
>
> ...
> -----
>
> The default for such stanzas would be: "option hosts *".
>
>
>
> Thanks,
> John

I think you are wanting something like OCFS, at least I *think* that
was the one that had the "smart" config file.

Basically when glusterfs parses the spec file there would have to be a
way for it to know that a volume specification was for *itself* and if
not (ie it was defining a volume for another server) it would ignore
the volume.

Pros and cons to this I guess, a pro is definately a single config to
edit and copy for all servers. Howerver, I believe this would lead to
a possibly huge and confusing (hence more room for error)
configuration file as you would have ALL definitions for all servers
in the file rather than *only* what it needs.

In keeping with the K.I.S.S. method of glusterfs, the devs probably
intentionally made it this way? Maybe they can comment more on that.

But yes at this point it would be neccessary to have individual spec
files unless there is some trick that im not aware of (VERY quite
possible).

=)