Through the GUI, a Cosmos user must be able to request a temporal access to the shared Hadoop cluster (computing), in order to submit a MapReduce job into one of the available queues the CapacityScheduler manages.
From the queues management point of view, this feature implies:
The GUI is able to remotely connect to the shared Hadoop cluster, edit $HADOOP_CONF_DIR/capacity-scheduler.xml in order to allow the user to use one of the queues and refresh them, as stated here.
The GUI must be able to control the status/occuancy/usage of each queue, in order to allocate the job to most apropriate queue. There exists the possibility to handle high priority queues for special users, and low priority queues for normal users, etc.
Regarding the temporal access to the computing cluster:
It must be controlled the time passed from the access request to the job submission. In this sense, the temporal accesses may work as web sessions that can expire if no action is taken.
Depending on the number of job submissions and usage of the queues, the access request may be delayed --> in this sense, requesting this kind of accesses and requesting a Sahara's private cluster is quite similar, and the concept of scheduling calendar may be used.
Through the GUI, a Cosmos user must be able to request a temporal access to the shared Hadoop cluster (computing), in order to submit a MapReduce job into one of the available queues the CapacityScheduler manages.
From the queues management point of view, this feature implies:
$HADOOP_CONF_DIR/capacity-scheduler.xml
in order to allow the user to use one of the queues and refresh them, as stated here.Regarding the temporal access to the computing cluster: