mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Till Toenshoff" <toensh...@me.com>
Subject Re: Review Request 27760: Revised authenticator interface to allow for two fold implementations.
Date Fri, 13 Feb 2015 15:24:45 GMT


> On Feb. 3, 2015, 8:56 p.m., Vinod Kone wrote:
> > src/authentication/cram_md5/authenticator.hpp, lines 517-526
> > <https://reviews.apache.org/r/27760/diff/12-13/?file=834177#file834177line517>
> >
> >     Instead of terminate() (or making it public) why not have an onDiscard handler
on the future returned at #508 that erases the pid?

We were not holding on onto the inner future (authenticate) and hence I had no way to do that.
Now I have solved this by wrapping the authenticate future with another one that becomes ready
only if we had a completely succefull authentication (that is both, future is ready __AND__
Option<string> contains a principal).


> On Feb. 3, 2015, 8:56 p.m., Vinod Kone wrote:
> > src/authentication/authenticator.hpp, lines 76-77
> > <https://reviews.apache.org/r/27760/diff/12-13/?file=834176#file834176line76>
> >
> >     Not looking at the implementation, this seems to be a weird interface method.
if authenticate() returns a future why do the caller need an explicit terminate() to terminate
the authentication? would be easy if he can just 'discard' the future which will cause termination.

You are completely right. It makes much more sense that way.


- Till


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/27760/#review70822
-----------------------------------------------------------


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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message