You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bigtop.apache.org by "jay vyas (JIRA)" <ji...@apache.org> on 2013/11/01 14:08:22 UTC
[jira] [Updated] (BIGTOP-1136) Testing Multitenancy and Multiuser
applications
[ https://issues.apache.org/jira/browse/BIGTOP-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
jay vyas updated BIGTOP-1136:
-----------------------------
Description:
One of the items which is important for emerging, more flexible hadoop deployments is multitenancy.
JIRA's such as this one: https://issues.apache.org/jira/browse/MAPREDUCE-5571
Are very hard to test, and it would be extremely useful to many people deploying non standard hadoop environments , if they could test that multitenant and multiuser support was functional on their cluster.
This is sort of related to the stress tests jira https://issues.apache.org/jira/browse/BIGTOP-1065, also recently created.
I'm not really even sure this is possible in a fully automated / iTest sort of fashion... so to start, any thoughts on how bigtop should test multi user, multi tenant workloads? One simple way to do it would be to launch 4 or 5 "calculate pi" jobs at one time, maybe from different users? But how could we "predict" off hand the usernames which will be available and appropriate to submit jobs on a cluster, without the user specifying them?
In any case, bigtop smokes is ideal for this kind of testing, because this kind of testing is really only applicable to a cluster which is being used by for a real deployment. Other tests (i.e. pig smoke tests) are well handled and covered by the individual ecosystem projects.
was:
One of the items which is important for emerging, more flexible hadoop deployments is multitenancy.
JIRA's such as this one: https://issues.apache.org/jira/browse/MAPREDUCE-5571
Are very hard to test, and it would be extremely useful to many people deploying non standard hadoop environments , if they could test that multitenant and multiuser support was functional on their cluster.
This is sort of related to the stress tests jira https://issues.apache.org/jira/browse/BIGTOP-1065, also recently created.
I'm not really even sure this is possible in a fully automated / iTest sort of fashion... so to start, any thoughts on how bigtop should test multi user, multi tenant workloads? One simple way to do it would be to launch 4 or 5 "calculate pi" jobs at one time, maybe from different users? But how could we "predict" off hand the usernames which will be available and appropriate to submit jobs on a cluster, without the user specifying them.
> Testing Multitenancy and Multiuser applications
> -----------------------------------------------
>
> Key: BIGTOP-1136
> URL: https://issues.apache.org/jira/browse/BIGTOP-1136
> Project: Bigtop
> Issue Type: New Feature
> Components: Tests
> Reporter: jay vyas
> Priority: Minor
>
> One of the items which is important for emerging, more flexible hadoop deployments is multitenancy.
> JIRA's such as this one: https://issues.apache.org/jira/browse/MAPREDUCE-5571
> Are very hard to test, and it would be extremely useful to many people deploying non standard hadoop environments , if they could test that multitenant and multiuser support was functional on their cluster.
> This is sort of related to the stress tests jira https://issues.apache.org/jira/browse/BIGTOP-1065, also recently created.
> I'm not really even sure this is possible in a fully automated / iTest sort of fashion... so to start, any thoughts on how bigtop should test multi user, multi tenant workloads? One simple way to do it would be to launch 4 or 5 "calculate pi" jobs at one time, maybe from different users? But how could we "predict" off hand the usernames which will be available and appropriate to submit jobs on a cluster, without the user specifying them?
> In any case, bigtop smokes is ideal for this kind of testing, because this kind of testing is really only applicable to a cluster which is being used by for a real deployment. Other tests (i.e. pig smoke tests) are well handled and covered by the individual ecosystem projects.
--
This message was sent by Atlassian JIRA
(v6.1#6144)