[ https://issues.apache.org/jira/browse/STORM-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14992352#comment-14992352 ]
Boyang Jerry Peng commented on STORM-898: ----------------------------------------- [~revans2] thanks for your comments. I think a strategy that implements IStrategy should return null if it compute a valid scheduling for a topology. When can also add another API that allows the user to set a error message when an error occurs in the strategy and RAS will display that message on the UI if the strategy returns a null scheduling > Add priorities and per user resource guarantees to Resource Aware Scheduler > --------------------------------------------------------------------------- > > Key: STORM-898 > URL: https://issues.apache.org/jira/browse/STORM-898 > Project: Apache Storm > Issue Type: New Feature > Components: storm-core > Reporter: Robert Joseph Evans > Assignee: Boyang Jerry Peng > Attachments: Resource Aware Scheduler for Storm.pdf > > > In a multi-tenant environment we would like to be able to give individual > users a guarantee of how much CPU/Memory/Network they will be able to use in > a cluster. We would also like to know which topologies a user feels are the > most important to keep running if there are not enough resources to run all > of their topologies. > Each user should be able to specify if their topology is production, staging, > or development. Within each of those categories a user should be able to give > a topology a priority, 0 to 10 with 10 being the highest priority (or > something like this). > If there are not enough resources on a cluster to run a topology assume this > topology is running using resources and find the user that is most over their > guaranteed resources. Shoot the lowest priority topology for that user, and > repeat until, this topology is able to run, or this topology would be the one > shot. Ideally we don't actually shoot anything until we know that we would > have made enough room. > If the cluster is over-subscribed and everyone is under their guarantee, and > this topology would not put the user over their guarantee. Shoot the lowest > priority topology in this workers resource pool until there is enough room to > run the topology or this topology is the one that would be shot. We might > also want to think about what to do if we are going to shoot a production > topology in an oversubscribed case, and perhaps we can shoot a non-production > topology instead even if the other user is not over their guarantee. -- This message was sent by Atlassian JIRA (v6.3.4#6332)