From: Alice Mitchell <ajmitchell@redhat.com>
To: Steve Dickson <steved@redhat.com>,
Linux NFS Mailing list <linux-nfs@vger.kernel.org>
Subject: Re: [RFC PATCH 0/1] Enable config.d directory to be processed.
Date: Mon, 02 Nov 2020 13:03:23 +0000 [thread overview]
Message-ID: <338aeb795a31c2233016d225dc114e33d02eb0cb.camel@redhat.com> (raw)
In-Reply-To: <20201029210401.446244-1-steved@redhat.com>
On Thu, 2020-10-29 at 17:04 -0400, Steve Dickson wrote:
> The following patch looks for config.d directories
> and configuration file in those directories will
> be loaded.
>
> For example if /etc/nfs.conf.d or /etc/nfsmount.conf.d
> exists and there are config files in those directories
> will be loaded, but not the actual /etc/nfs.conf or
> the /etc/nfsmount.conf files will not be.
>
> I do have a couple questions/concerns
>
> 1) Is calling conf_load_file() more than once
> kosher... It appears variable will just be
> over written. That does appear to happen
> with my testing.
>
> 2) If conf.d file(s) do exist, should the give
> flat conf file also be loaded. At this point if
> the conf.d file(s) do exist, then the given
> flat config file is not loaded.
>
> 3) How to document this new feature.
>
> Steve Dickson (1):
> conffile: process config.d directory config files.
>
> support/nfs/conffile.c | 78
> +++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 77 insertions(+), 1 deletion(-)
NAK.
Each call to conf_load_file() erases all existing config values from
memory via a call to conf_free_bindings() so this wont work as you
expect.
You would need to write an equivalent of conf_load_file() that created
a new transaction id and read in all the files before committing them
to do it this way.
I can't help but wonder if this would be better handled as an
improvement to the 'include' directive to support file globbing, we
could then retain the functionality of the master nfs.conf file but
tack on an 'include nfs.conf.d/*.conf' at the end which would go off
and load any files dropped in there by package management.
-Alice
next prev parent reply other threads:[~2020-11-02 13:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-29 21:04 [RFC PATCH 0/1] Enable config.d directory to be processed Steve Dickson
2020-10-29 21:04 ` [PATCH 1/1] conffile: process config.d directory config files Steve Dickson
2020-11-02 13:03 ` Alice Mitchell [this message]
2020-11-02 13:24 ` [RFC PATCH 0/1] Enable config.d directory to be processed Steve Dickson
2020-11-02 14:23 ` Steve Dickson
2020-11-02 15:05 ` Alice Mitchell
2020-11-02 15:16 ` Chuck Lever
2020-11-02 16:37 ` Steve Dickson
2020-11-02 16:42 ` Steve Dickson
2020-11-02 15:57 ` Alice Mitchell
2020-11-02 19:42 ` Steve Dickson
2020-11-02 22:01 ` McIntyre, Vincent (CASS, Marsfield)
2020-11-03 10:14 ` Alice Mitchell
2020-11-03 17:16 ` Steve Dickson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=338aeb795a31c2233016d225dc114e33d02eb0cb.camel@redhat.com \
--to=ajmitchell@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--cc=steved@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox