This is an automatically generated e-mail. To reply, visit:

(Updated Dec. 17, 2015, 3:48 p.m.)

Review request for Aurora, Joshua Cohen and Bill Farner.


Strike type witnesses.

Bugs: AURORA-687

Repository: aurora


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

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 (updated)

  NEWS 7a80f32465736de4fbdc7d2c7a3dbf790be31e16 

Diff: https://reviews.apache.org/r/41525/diff/


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.


R.B. Boyer

Reply via email to