> On Jan. 28, 2015, 8:33 p.m., Vinod Kone wrote: > > Can you expand description on why you designed the authenticator inteface > > this way? Particularly, expand on "The initial design and implementation of > > the authenticator module interface caused issues and was not optimal for > > heavy lifting setup of external dependencies" and "The new design also gets > > us back on track to the goal of makeing SASL a soft dependency of mesos". > > > > An issue with the new design is that now users have to implement an > > Authenticator and an AuthenticatorSession to implement a new type of > > authenticator. Also, we lost the symmetry between authenticatee and > > authenticator. An Authenticatee now communicates with AuthenticatorSession > > instead of Authenticator, which is confusing. Is the plan to refactor the > > Authenticatee similarly? > > Adam B wrote: > We need to load/initialize the auxprop plugin at most once per linux > process, so we need the authenticator to live for the lifetime of the master, > but we need the sasl connection to be created/disposed with the lifetime of a > per-authenticatee auth session. We could probably get away with hiding the > Session variable underneath the Authenticator interface, and just call > Authenticator::authenticate(pid) which will spin up a new session/connection > and Authenticator::cancel/complete(pid) which erases/disposes the > session/connection. The sasl-based authenticators will then manage the > pid->session map internally, and other non-sasl authenticators don't have to > know about that implementation detail. (I think I mentioned this before, but > Till will have to remind me why we decided against it.)
*The initial design and implementation of the authenticator module interface caused issues and was not optimal for heavy lifting setup of external dependencies* The credentials loading was moved away from `Master::initialize` into the `Master::authenticate` phase. That however caused havoc due to the fact that concurrent read- and write access to the credentials storage (`InMemoryAuxiliaryPropertyPlugin`) now became possible. So we want the credential loading to happen as early as possible and not per authentication request. When looking at possible authenticator implementations, I also realized that some may actually have rather costly initializing to do - e.g. setup a secure connection to a database. *The new design also gets us back on track to the goal of makeing SASL a soft dependency of mesos.* In the end, CyrysSASL2 does not have to be a hard dependency of Mesos given that we can wrap its access under a single module library (which then has that dependency). The use of CRAM-MD5 within mesos has a hard dependency against CyrusSASL2 due to fact that the master.cpp is depending on having direct access to `InMemoryAuxiliaryPropertyPlugin`. My goal was to wrap all of that with the modules. - Till ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27760/#review70051 ----------------------------------------------------------- On Feb. 13, 2015, 3:20 p.m., Till Toenshoff wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/27760/ > ----------------------------------------------------------- > > (Updated Feb. 13, 2015, 3:20 p.m.) > > > Review request for mesos, Adam B, Kapil Arya, Niklas Nielsen, and Vinod Kone. > > > Bugs: MESOS-2050 > https://issues.apache.org/jira/browse/MESOS-2050 > > > Repository: mesos > > > Description > ------- > > The initial design and implementation of the authenticator module interface > caused issues and was not optimal for heavy lifting setup of external > dependencies. By introducing a two fold design, this has been decoupled from > the authentication message processing. The new design also gets us back on > track to the goal of makeing SASL a soft dependency of mesos. > > > Diffs > ----- > > include/mesos/authentication/authenticator.hpp f66217a > src/authentication/cram_md5/authenticator.hpp 7578ea1 > src/authentication/cram_md5/auxprop.hpp d036b11 > src/authentication/cram_md5/auxprop.cpp 5ff9755 > src/master/master.hpp 6a39df0 > src/master/master.cpp f10a3cf > src/tests/cram_md5_authentication_tests.cpp dd102dc > > Diff: https://reviews.apache.org/r/27760/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Till Toenshoff > >
