Re: Review Request 41525: Add flag to set FrameworkInfo.principal
> On Dec. 17, 2015, 2:53 p.m., Bill Farner wrote: > > Thanks, overall this looks great! > > > > Can you also add a line in the NEWS file to call out the new flag? Doesn't > > need formal documentation, just a brief blurb is fine. Under 0.11.0 or in an unspecified area above that? - R.B. --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/41525/#review111043 --- On Dec. 17, 2015, 12:39 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, 12:39 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 > - > > > 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 > >
Re: Review Request 41525: Add flag to set FrameworkInfo.principal
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/41525/ --- (Updated Dec. 17, 2015, 3:24 p.m.) Review request for Aurora, Joshua Cohen and Bill Farner. Changes --- Switching to Optional for the principal 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 (updated) - 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
Re: Review Request 41525: Add flag to set FrameworkInfo.principal
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/41525/ --- (Updated Dec. 17, 2015, 3:26 p.m.) Review request for Aurora, Joshua Cohen and Bill Farner. Changes --- Amend NEWS 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 (updated) - 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
