[
https://issues.apache.org/jira/browse/AURORA-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15061196#comment-15061196
]
R.B. Boyer edited comment on AURORA-687 at 12/17/15 12:18 AM:
--------------------------------------------------------------
There are several situations to consider:
# fresh installs that will not have authN/authZ
## may want to add authN/authZ later
# fresh installs that will begin life with authN/authZ (me)
## no problems in the future (unless the principal is changed)
# 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).
was (Author: naelyn):
There are several situations to consider:
# fresh installs that will not have authN/authZ
## may want to add authN/authZ later
# fresh installs that will begin live with authN/authZ (me)
## no problems in the future (unless the principal is changed)
# 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).
> Aurora should set FrameworkInfo.principal
> -----------------------------------------
>
> Key: AURORA-687
> URL: https://issues.apache.org/jira/browse/AURORA-687
> Project: Aurora
> Issue Type: Task
> Reporter: Zameer Manji
> Priority: Minor
>
> The principal field has been in FrameworkInfo since 0.19. In 0.20 it will be
> used for authorization and rate limiting. We should set this field so we can
> use those features.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
