I wonder if it wouldn't make sense to delay commits to stable branches
until the time to release comes ?

Would it make it easier or harder to review and apply changes only at
release time ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
--- Begin Message ---
On Fri, Sep 13, 2013 at 05:26:23PM +0200, Jakub Hrozek wrote:
> On Fri, Sep 13, 2013 at 02:31:50PM +0200, Michal Židek wrote:
> > On 09/12/2013 10:10 PM, Simo Sorce wrote:
> > >On Thu, 2013-09-12 at 20:06 +0200, Michal Židek wrote:
> > >>On 09/12/2013 05:48 PM, Simo Sorce wrote:
> > >>>On Thu, 2013-09-12 at 11:23 +0200, Jakub Hrozek wrote:
> > >>>>On Wed, Sep 11, 2013 at 05:54:01PM -0400, Simo Sorce wrote:
> > >>>>>On Wed, 2013-09-11 at 20:19 +0200, Michal Židek wrote:
> > >>>>>>Hello,
> > >>>>>>
> > >>>>>>I would like to have this option in SSSD for debugging purposes.
> > >>It is
> > >>>>>>not documented, so it should be invisible for users (but I can
> > >>add it to
> > >>>>>>man pages as well, if someone thinks it is useful to have it
> > >>there).
> > >>>>>
> > >>>>>This would cause you to have stale mmap cache files on the system,
> > >>>>>wouldn't it make more sense to have an environment variable for
> > >>the
> > >>>>>client libraries instead and have them ignore the mmap cache when
> > >>you
> > >>>>>want to test something ?
> > >>>>
> > >>>>This sounds like a good idea.
> > >>>>
> > >>>>>It could also be documented as it may be a useful workaround
> > >>should a
> > >>>>>user find a bug that hits the mmap_cache and wants a temporary way
> > >>to
> > >>>>>avoid it even if with performance penalty for a specific
> > >>application.
> > >>>>>
> > >>>>>Something like SSS_NSS_USE_MEMCACHE=yes/no
> > >>>>>
> > >>>>>defaulting to yes, if no env var is found.
> > >>
> > >>Just found out that we have a check for _SSS_MC_SPECIAL in function
> > >>sss_nss_mc_get_ctx. It makes the function fail returning the EPERM
> > >>errno. I do not know what was the purpose of this variable, but it is
> > >>exactly what we need.
> > >>
> > >>Maybe we should just rename this variable, because it is not cleat
> > >>from
> > >>first glance, what it really does (see attached patch).
> > >
> > >Uhmmm I forgot why I added it, I guess for testing :)
> > >
> > >>>>
> > >>>>If I can speak for Michal -- we discussed that it might be nice to
> > >>be able
> > >>>>to temporarily disable the memcache somehow, but if there was a
> > >>documented
> > >>>>way, hitting memcache problems would simply disable it and don't
> > >>even
> > >>>>report a bug. Kind of like users switching SELinux to Permissive.
> > >>>
> > >>>Their choice.
> > >>>I think it is more valuable to have the option than not for fear of
> > >>>people not reporting bugs.
> > >>>
> > >>
> > >>Ok. I added the man page change in the second patch.
> > >>
> > >>>Simo.
> > >>>
> > >>
> > >>Patches are attached.
> > >>
> > >>Thanks
> > >>Michal
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>differences
> > >>between files
> > >>attachment
> > >>(0001-Rename-_SSS_MC_SPECIAL.patch)
> > >>
> > >> From 595c9892ad2079276855519e1fac086b9d52f685 Mon Sep 17 00:00:00 2001
> > >>From: Michal Zidek <[email protected]>
> > >>Date: Thu, 12 Sep 2013 19:45:39 +0200
> > >>Subject: [PATCH 1/2] Rename _SSS_MC_SPECIAL
> > >>
> > >>If the environment variable _SSS_MC_SPECIAL is set to "NO", the
> > >>mmap cache is skipped in the client code. The name is not very
> > >>descriptive. This patch renames the variable to SSS_NSS_USE_MEMCACHE.
> > >>---
> > >>  src/sss_client/nss_mc_common.c | 4 ++--
> > >>  1 file changed, 2 insertions(+), 2 deletions(-)
> > >>
> > >>diff --git a/src/sss_client/nss_mc_common.c
> > >>b/src/sss_client/nss_mc_common.c
> > >>index 5d36c47..a0a70ab 100644
> > >>--- a/src/sss_client/nss_mc_common.c
> > >>+++ b/src/sss_client/nss_mc_common.c
> > >>@@ -108,8 +108,8 @@ errno_t sss_nss_mc_get_ctx(const char *name,
> > >>struct sss_cli_mc_ctx *ctx)
> > >>      char *envval;
> > >>      int ret;
> > >>
> > >>-    envval = getenv("_SSS_MC_SPECIAL");
> > >>-    if (envval && strcmp(envval, "NO") == 0) {
> > >>+    envval = getenv("SSS_NSS_USE_MEMCACHE");
> > >>+    if (envval && strcasecmp(envval, "NO") == 0) {
> > >>          return EPERM;
> > >>      }
> > >>
> > >>--
> > >>1.7.11.2
> > >
> > >ACK
> > >
> > >
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>differences
> > >>between files
> > >>attachment
> > >>(0002-man-sssd-Add-note-about-SSS_NSS_USE_MEMCACHE.patch)
> > >>
> > >> From f7d07757b00eec75716ae7b43403f206d81466b6 Mon Sep 17 00:00:00 2001
> > >>From: Michal Zidek <[email protected]>
> > >>Date: Thu, 12 Sep 2013 19:51:55 +0200
> > >>Subject: [PATCH 2/2] man sssd: Add note about SSS_NSS_USE_MEMCACHE
> > >>
> > >>---
> > >>  src/man/sssd.8.xml | 8 ++++++++
> > >>  1 file changed, 8 insertions(+)
> > >>
> > >>diff --git a/src/man/sssd.8.xml b/src/man/sssd.8.xml
> > >>index 0aba418..3a0fc01 100644
> > >>--- a/src/man/sssd.8.xml
> > >>+++ b/src/man/sssd.8.xml
> > >>@@ -187,6 +187,14 @@
> > >>          </variablelist>
> > >>      </refsect1>
> > >>
> > >>+    <refsect1 id='notes'>
> > >>+        <title>NOTES</title>
> > >>+        <para>
> > >>+            If the environment variable SSS_NSS_USE_MEMCACHE is set
> > >>to "NO",
> > >>+            the client applications will not use the fast in memory
> > >
> > >drop 'the' --^^^^ in front of client
> > >
> > >otherwise ACK
> > >
> > >>  cache.
> > >>+        </para>
> > >>+    </refsect1>
> > >>+
> > >>         <xi:include xmlns:xi="http://www.w3.org/2001/XInclude";
> > >>href="include/seealso.xml" />
> > >>
> > >>  </refentry>
> > >>--
> > >>1.7.11.2
> > 
> > Thank you. New patches are attached.
> > 
> > Michal
> 
> The language was fixed as Simo requested. ACK.
> 
> I think this would be nice to have even in stable branches.

Pushed to master, sssd-1-11, sssd-1-10 and sssd-1-9

I'm looking forward to releasing 1.10.2 to have one less branch to care
about :-)
_______________________________________________
sssd-devel mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel

--- End Message ---
_______________________________________________
sssd-devel mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel

Reply via email to