On Thu, Jul 12, 2012 at 06:10:58PM -0400, J. Bruce Fields wrote: > On Wed, Jul 11, 2012 at 05:49:09PM +0000, Myklebust, Trond wrote: > > On Wed, 2012-07-11 at 13:27 -0400, J. Bruce Fields wrote: > > > So, if the issue is: you want to be able to choose, in individual > > > containers, which mechanism to use: whatever, we can probably make that > > > work. > > > > Please do then. > > > > > If you're instead saying: it's not acceptable to use the gssproxy > > > mechanism to authenticate v4.0 callbacks, the client must only ever use > > > the existing mechanism: then I'd rather drop this entirely. I don't > > > want to merge an rpc server authentication upcall that's not acceptable > > > for one of the rpc servers. > > > > If it goes in, I want it to be optional so that it doesn't break working > > setups. I also want upgrades/downgrades to be as painless as possible. > > > > See for instance the idmapper changes in 3.5 which are totally > > transparent to the user: if the admin sets up /etc/request-key.conf to > > use the new id_resolver, then that works, otherwise we just fall back to > > using the old rpc.idmapd method. There are no module parameters etc > > involved. > > There's a module parameter here, but it's meant to be set by gssproxy to > indicate it's listening for the new upcall. In theory that should make > the transition transparent. > > However, if we need to make the choice per-namespace then we need to > find some other mechanism (assuming there's no way to make module > parameters per-namespace.) So, perhaps something like: if the cache "channel" file for the namespace associated with the current request isn't opened, then try the new upcall. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
