Dev, Suresh and I had a good discussion on Friday about how to handle sharing allocation and resources with different groups of gateway users and how to specify restrictions on how that shared allocation can be used by those groups. I’ll try here to summarize what we discussed, and I will also include some further thoughts I’ve had on implementation details. Feedback is appreciated.
At a high level the main idea is to create a new data model called GroupResourceProfile that would be very similar to the current GatewayResourceProfile in that it would define what resources are available to specific groups (whereas GatewayResourceProfile applies globally to all gateway users). One important difference though is that GroupResourceProfiles can also specify “resource policies” that define certain restrictions on how the shared resources can be used. Here’s a sketch of these new data models GroupResourceProfile * gatewayId * groupResourceProfileId * groupResourceProfileName * list<ComputeResourcePreference> computeResourcePreferences * list<ComputeResourcePolicy> computeResourcePolicies * list<BatchQueueResourcePolicy> batchQueueResourcePolicies ComputeResourcePolicy * resourcePolicyId * computeResourceId * list<string> allowedBatchQueues - to restrict the group allocation to only being allowed on the given queues BatchQueueResourcePolicy * resourcePolicyId * computeResourceId * queueName * maxAllowedNodes * maxAllowedCores * maxAllowedWalltime Each GroupResourceProfile is then shared with users/groups in the Sharing service. GroupResourceProfile would thus need to be a new EntityType and each GroupResourceProfile would be an entity in the Sharing service. The Sharing service can be queried to get all of the GroupResourceProfiles that a user has access to. One consequence of this is that the ExperimentModel will need to convey to the Orchestrator which GroupResourceProfile to use when launching the experiment. In the UI I envision that a user will need to select which group they want to use when submitting the job. Figuring out what applications a user can launch is a two part process in this new group-based authorization model because access to applications is granted separately from access to resources, but a user needs both (in the form of an ApplicationDeployment) in order to actually launch an application. Other things we discussed that I want to note down for future reference: * move toward automatically “approving” users so that new users can immediately do something. Users will need to be assigned to more privileged groups to have access to more resources but they can start off in a group where they can do some limited amount of things. * Suresh mentioned that we can keep the GatewayResourceProfile use it as the default settings for the GroupResourceProfiles so that not everything has to be specified again for each one. My opinion, just to keep things simple, would be that we use the GatewayRsourceProfile only as a way to specify some defaults and gateway wide settings but not for the purpose of launching jobs; a user needs to have access to a GroupResourceProfile in order to launch an application. * we have a need for somewhat more fine grained higher level API servers that will provide Airavata semantics on top of more generic/domain-agnostic services like the Sharing service. But Suresh indicated this will be fleshed out more in the spring. For now we discussed using the profile service as the higher level service on top of the Sharing service for some of the Airavata specific semantics around sharing. (For the most part it may just end up proxying requests to the Sharing service.) Thanks, Marcus
