> On Feb. 4, 2015, 2:29 a.m., Adam B wrote: > > src/tests/cram_md5_authentication_tests.cpp, line 277 > > <https://reviews.apache.org/r/27760/diff/12-13/?file=834182#file834182line277> > > > > Did you mean "cancel the authentication process"? How about > > "discard..."?
No I actually meant "process authentication" as that is exactly what the authenticator does, it authenticates a libprocess process via the Authenticatee interface. But discard sounds much better indeed. > On Feb. 4, 2015, 2:29 a.m., Adam B wrote: > > src/master/master.cpp, line 4319 > > <https://reviews.apache.org/r/27760/diff/12-13/?file=834181#file834181line4319> > > > > If we change `authenticator->terminate(pid)` to `future.discard()`, and > > the future has actually become Ready, will a call to future.discard() still > > call the onDiscard handler? Because what we really want is just to erase > > the session from the map so that the Owned pointer drops to 0 refs and the > > session self-destructs. Once the future becomes ready or discarded or failed, the session gets killed (onAny). > On Feb. 4, 2015, 2:29 a.m., Adam B wrote: > > src/master/master.cpp, lines 4319-4320 > > <https://reviews.apache.org/r/27760/diff/12-13/?file=834181#file834181line4319> > > > > Can we tie the authenticator's future to the master's `authenticating` > > future? Does that even make sense? Do they always have the same > > lifetime/effects? Yeah, that is what I did - I wrapped the authenticator (authenticate) future by another "authenticating" future to allow for the status merge (!authenticate.isReady || authenticate.get.isSome() => authenticating.fail()). - Till ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27760/#review70863 ----------------------------------------------------------- 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 > >
