[
https://issues.apache.org/jira/browse/MESOS-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14172253#comment-14172253
]
Till Toenshoff commented on MESOS-1905:
---------------------------------------
Turns out I can get around without this feature by a minor change in the
flags-validation within mesos-master. So my specific use-case becomes invalid
for now.
Given that the basic idea might still be useful when properly being expanded
(versioning on the information channel), I will not close this unless
instructed otherwise.
> Enable module metadata to be accessed by the user
> -------------------------------------------------
>
> Key: MESOS-1905
> URL: https://issues.apache.org/jira/browse/MESOS-1905
> Project: Mesos
> Issue Type: Improvement
> Components: modules
> Reporter: Till Toenshoff
> Priority: Blocker
>
> h4. Motivation
> I would love to be able to get custom, meta-data information from a module
> without needing to create a kind instance.
> h4. Use Case
> When slave authentication is activated on the master, the user has to supply
> credentials (as our current implementation demands them). Given that
> alternative authentications will not rely on such credentials, we need a way
> to make sure that only Authenticator's that need this information will demand
> them from the user. I would like to prevent instantiating a kind for that
> module as I will not make further use of that instance at that (early) point
> - let me call this the "capabilities instance".
> Options are; (a) delete it right away or (b) hold on to it.
> a: definitely is possible but does not seem elegant to me right now.
> b: holding on onto that instance and reusing it later is not really a good
> fit as the master will instantiate new Authenticator's per connected slave.
> So for the first slave, I would have to use that capabilities instance and
> for all further slave connections I would have to create new Authenticators
> (possible but ugly as hell).
> So by extending the Module structure specialization with a {{bool
> needsCredentials()}}, I could solve this rather neatly:
> {noformat}
> template <>
> struct Module<Authenticator> : ModuleBase
> {
> Module(
> const char* _moduleApiVersion,
> const char* _mesosVersion,
> const char* _authorName,
> const char* _authorEmail,
> const char* _description,
> bool (*_compatible)(),
> bool (*_needsCredentials)(),
> Authenticator* (*_create)())
> : ModuleBase(
> _moduleApiVersion,
> _mesosVersion,
> "Authenticator",
> _authorName,
> _authorEmail,
> _description,
> _compatible),
> needsCredentials(_needsCredentials),
> create(_create)
> { }
> bool (*needsCredentials)();
> Authenticator* (*create)();
> };
> {noformat}
> Within the implementation I would simply use that function just like we are
> using {{compatible()}} already.
> h4. Status Quo
> ModuleManager does not support returning the {{ModuleBase*}} to the user. The
> only way for such information to be returned by a module is to instantiate it
> and ask its implementation for it - that is, the module interface needs to
> include a method returning such info.
> h4. Idea
> For being able to get information on a module without an instance kind, a
> method within the ModuleManager that looks something like this would help:
> {noformat}
> static Try<ModuleBase*> peek(const std::string& moduleName)
> {noformat}
> h4. Discussion
> Am I possibly attempting something too hacky here - are there better
> alternatives I missed?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
