twosigma
One-to-one mapping between cook user and posix user on mesos-slaves
Is there a reason Cook assumes that end users have an accompanying posix user which are used on the slaves?
For me this requirement renders Cook unusable.
The historical reason is for automatic Kerberos ticket distribution, which requires paid add-ons.
It would not be hard to add a "run-as" field to the database, and add an
extra field in the JSON for this. By doing so, you could have many user or
group queues in your company, but they'll all run as the prod user on
your cluster.
On Tue, Feb 9, 2016 at 12:01 PM Li Jin [email protected] wrote:
Hi Hans,
Can you explain a bit what issues did you see?
— Reply to this email directly or view it on GitHub https://github.com/twosigma/Cook/issues/95#issuecomment-181957694.
Thank you both for picking this up so swiftly.
I think @dgrnbrg understands my problem. So for example, I would like to have two Spark frameworks, one with user "user1" and the other with "user2". However even when using "one user" or "http-basic" auth, with current code, "user1" and "user2" would be used as user accounts for running the tasks on the mesos slaves. Indeed I would like to use only one account (which is given to me by the local cluster administrator ) for running the tasks.
On a sidenote, before either you or me invest a lot of time in this, can I expect Cook to provide fairness in case of long running spark frameworks? In our environment we use two to three SparkContexts as the equivalents of the classical JobTracker in a Hadoop environment, i.e. they are long-lived and we feed them SparkSQL queries as jobs. Or does Cook implicitly assume end-user jobs start their own SparkContext? I expect this is the case, as Mesos resources are immediately accepted as soon as the SparkContext starts, even if it does not have outstanding stages/jobs.
What I ultimately hope to do is keep the setup I have now which is using 2-3 long-lived SparkContexts. For each of these I would like to give hem a weight, which would be used as the ratio of resources given to the SparkContexts in times of high utilization of all three SparkContexts/Frameworks.
At the moment, each SparkContext will get a fraction of the total resources available to Cook based on the provided weights. That is, currently, we can only balance the number of executors per context by their weight, and scale up or down as users come and go or executors sit idle or not.
Bump on this issue. I use a web interface on top of that so it'd be nice if it was possible to preempt based on an arbitrary job label. Fairness based on POSIX user not only doesn't make any sense but also adds a significant overhead of adding a POSIX user for every web user on every slave node. I didn't try Kerberos for that matter but that doesn't sounds like a good idea to me...
