Our Community is getting an upgrade! To get everything ready for the relaunch, we’ll be placing the site in read-only mode starting September 21st.
We really appreciate your understanding while we get things set up behind the scenes. Catch up on all the exciting details about the move here.
Need help or have questions? Drop us a line at [email protected]
Created 02-17-2016 02:47 PM
is that possible? I need the following scenario
AdminA can only see/modify yarn queue A
AdminB can only see/modify yarn queue B
Created 02-17-2016 03:23 PM
So you definitely have the possibility to restrict control over a subset of queues. ( We had problems getting it to run in a non-kerberized cluster but in a kerberized cluster they work fine. ) Let me see if I find a way to restrict seeing applications as well.
| yarn.scheduler.capacity.root.<queue-path>.acl_submit_applications | The ACL which controls who can submit applications to the given queue. If the given user/group has necessary ACLs on the given queue or one of the parent queues in the hierarchy they can submit applications. ACLs for this property are inherited from the parent queue if not specified. |
| yarn.scheduler.capacity.root.<queue-path>.acl_administer_queue | The ACL which controls who can administer applications on the given queue. If the given user/group has necessary ACLs on the given queue or one of the parent queues in the hierarchy they can administer applications. ACLs for this property are inherited from the parent queue if not specified. |
Created 02-17-2016 02:48 PM
Can a single cluster have different Admins who don’t see each other’s services and processes while still allowing control over their subset?
Created 02-17-2016 03:23 PM
So you definitely have the possibility to restrict control over a subset of queues. ( We had problems getting it to run in a non-kerberized cluster but in a kerberized cluster they work fine. ) Let me see if I find a way to restrict seeing applications as well.
| yarn.scheduler.capacity.root.<queue-path>.acl_submit_applications | The ACL which controls who can submit applications to the given queue. If the given user/group has necessary ACLs on the given queue or one of the parent queues in the hierarchy they can submit applications. ACLs for this property are inherited from the parent queue if not specified. |
| yarn.scheduler.capacity.root.<queue-path>.acl_administer_queue | The ACL which controls who can administer applications on the given queue. If the given user/group has necessary ACLs on the given queue or one of the parent queues in the hierarchy they can administer applications. ACLs for this property are inherited from the parent queue if not specified. |
Created 02-17-2016 03:26 PM
@Benjamin Leonhardi Will it restrict the view of queues? The above settings helps to implement the control/authority but admins can still see everything...
Created 02-17-2016 03:30 PM
Good question the yarn documentation says:
"Also, there are safe-guards to ensure that users cannot view and/or modify applications from other users."
However we have setup the administer settings in our cluster and I can still see all applications. So there must be some other setting to enable these "safeguards".
Created 02-17-2016 03:39 PM
@Benjamin Leonhardi It would be interesting to see Ambari with Multiple clusters
Created 02-17-2016 03:59 PM
Multicluster mode in Ambari is perhaps one of the most requested features. However its a BIG implementation effort.
Created 02-17-2016 03:25 PM
Good question and I thought about using different installs of ambari views but instances will be reading the same configurations.
As we cannot manage multiple clusters from ambari so multiple admins with segregation of different view of cluster is not possible.
Admin can see everything so it's not possible. As mentioned above, It would be interesting to see when ambari manages multiple clusters.