[ https://issues.apache.org/jira/browse/MESOS-1966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Till Toenshoff updated MESOS-1966: ---------------------------------- Description: There are some options we quickly need to decide upon: 1. Keep the currently existing authenticator {{sasl/authenticator.hpp}} within {{libmesos}} as a default implementation. Add the {{--authenticators}} flag to the master and if the user selects {{crammd5}}, use the linked in, default implementation. If the user selects a different name e.g. {{org_apache_mesos_authenticator_pam}}, the master will try to load a module with that name and use its implementation. This is somewhat similar to what Kapil has done with the Isolator module integration. 2. Make the currently existing authenticator become a module and thereby remove it from libmesos. Add the {{--authenticators}} flag to the master and ask the user to supply a module as well ( {{--modules}} ). 3. Mixture of 1. and 2. Difference to 2. would be that we load the authenticator module implicitly (without the user supplying the {{--modules}} flag) as soon as he has enabled any kind of authentication ( {{--authenticate_slaves}} / {{--authenticate_frameworks}} ). was: There are some options we quickly need to decide upon: 1. Keep the currently existing authenticator (sasl/authenticator.hpp) within libmesos as a default implementation. Add the --authenticators flag to the master and if the user selects "crammd5", use the linked in, default implementation. If the user selects a different name e.g. "org_apache_mesos_authenticator_pam", the master will try to load a module with that name and use its implemenation. This is somewhat similar to what Kapil has done with the Isolator module integration. 2. Make the currently existing authenticator become a module and thereby remove it from libmesos. Add the --authenticators flag to the master and ask the user to supply a module as well (--modules). 3. Mixture of 1. and 2. Difference to 2. would be that we load the authenticator module implicitly (without the user supplying the --modules flag) as soon as he has enabled any kind of authentication (--authenticate_slaves / --authenticate_frameworks). > Integrate the Authenticator module > ---------------------------------- > > Key: MESOS-1966 > URL: https://issues.apache.org/jira/browse/MESOS-1966 > Project: Mesos > Issue Type: Improvement > Components: modules > Reporter: Till Toenshoff > Assignee: Till Toenshoff > > There are some options we quickly need to decide upon: > 1. Keep the currently existing authenticator {{sasl/authenticator.hpp}} > within {{libmesos}} as a default implementation. Add the {{--authenticators}} > flag to the master and if the user selects {{crammd5}}, use the linked in, > default implementation. If the user selects a different name e.g. > {{org_apache_mesos_authenticator_pam}}, the master will try to load a module > with that name and use its implementation. This is somewhat similar to what > Kapil has done with the Isolator module integration. > 2. Make the currently existing authenticator become a module and thereby > remove it from libmesos. Add the {{--authenticators}} flag to the master and > ask the user to supply a module as well ( {{--modules}} ). > 3. Mixture of 1. and 2. Difference to 2. would be that we load the > authenticator module implicitly (without the user supplying the {{--modules}} > flag) as soon as he has enabled any kind of authentication ( > {{--authenticate_slaves}} / {{--authenticate_frameworks}} ). -- This message was sent by Atlassian JIRA (v6.3.4#6332)