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


Sorry for the hassle - we had a few patches just land that caused a merge 
conflict on NEWS.  I tried to step in post the rebased patch.  Despite the fact 
that i can post a patch, ReviewBoard doesn't give me the UI to hit publish.  
Can you check that you're okay with the latest draft and hit publish?

- Bill Farner


On Dec. 17, 2015, 1:48 p.m., R.B. Boyer wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41525/
> -----------------------------------------------------------
> 
> (Updated Dec. 17, 2015, 1:48 p.m.)
> 
> 
> Review request for Aurora, Joshua Cohen and Bill Farner.
> 
> 
> Bugs: AURORA-687
>     https://issues.apache.org/jira/browse/AURORA-687
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> Bugs closed: AURORA-687
> 
> Copying the intent from one of the trailing comments:
> 
> """
> There are several situations to consider:
> 
> 1. fresh installs that will not have authN/authZ (may want to add authN/authZ 
> later)
> 2. fresh installs that will begin life with authN/authZ (no problems in the 
> future unless the principal is changed)
> 3. existing installs that have authN (may want to add authZ later)
> 
> The current defaults are friendly for (1) above, where the typical 
> test-driver won't be turning any flavor of Auth on in their mesos cluster. 
> These defaults are good.
> 
> If someone elects to go down (2) above, the defaults you get from 
> -framework_authentication_file are not awesome, as this is where the misstep 
> lies.
> 
> If someone went down (3) above already, and used the 
> -framework_authentication_file non-awesome setting, you also don't want 
> _them_ to break their cluster.
> 
> The bare minimum change to be the least breaking would be to introduce a new 
> setting like -framework_announce_principal or something so that (2) can be 
> happy without breaking (3).
> 
> Similarly to the mesos checkpoint breaking change, you could roll this out as 
> opt-in and then in a future release make it opt-out when setting 
> -framework_authentication_file and announce it as a breaking change in the 
> changelogs for the poor folks in group (3).
> """
> 
> 
> Diffs
> -----
> 
>   NEWS 7a80f32465736de4fbdc7d2c7a3dbf790be31e16 
>   
> src/main/java/org/apache/aurora/scheduler/mesos/CommandLineDriverSettingsModule.java
>  68aeda1692271841d10e5f29d439806576bd691c 
>   
> src/test/java/org/apache/aurora/scheduler/mesos/CommandLineDriverSettingsModuleTest.java
>  513391ff82c3e985bf9f673d35414e9245807b4a 
> 
> Diff: https://reviews.apache.org/r/41525/diff/
> 
> 
> Testing
> -------
> 
> Ran normal unit tests.
> 
> Built the patched scheduler and deployed it in an authN+authZ mesos cluster 
> (3 control plane boxes, 2 execution plane boxes) and the framework could 
> actually register with mesos.
> 
> 
> Thanks,
> 
> R.B. Boyer
> 
>

Reply via email to