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.) --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
