airavata-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus Christie (JIRA)" <>
Subject [jira] [Commented] (AIRAVATA-2787) GatewayGroups model for storing adminsGroupId, readOnlyAdminsGroupId and defaultGatewayUsersGroupId
Date Mon, 14 May 2018 18:00:01 GMT


Marcus Christie commented on AIRAVATA-2787:

I decided to put the GatewayGroups model in the Registry service instead of the GroupManagerService.
The main reason is that the GroupManagerService doesn't really need to know about these special
groups, but the Registry/API server does need to know about them in order to properly share
gateway resources with "Admins" and "Read Only Admins".

> GatewayGroups model for storing adminsGroupId, readOnlyAdminsGroupId and defaultGatewayUsersGroupId
> ---------------------------------------------------------------------------------------------------
>                 Key: AIRAVATA-2787
>                 URL:
>             Project: Airavata
>          Issue Type: New Feature
>            Reporter: Marcus Christie
>            Assignee: Marcus Christie
>            Priority: Major
> Create a GatewayGroups thrift model and backend to store the ids of the "Admins", "Read
Only Admins" and the default "Gateway Users" group.  The "Admins" and "Read Only Admins" group
will be used in the API server to automatically grant access to WRITE and READ to those groups,
respectively, for newly created entities.  The default "Gateway Users" group will be used
by migrations (to keep track of previously migrated "Gateway Users" group and to share resources
that are being migrated to group-based auth) and also to pre-populate the list of groups to
share a new Group Resource Profile or Application Deployment with in UIs (but can be changed
by the user).
> The AiravataDataMigrator should use the presence of this model to determine if the gateway
groups should be created or not.
> * [ ] add GatewayGroups model and entity to Registry
> * [ ] add create/read methods for the GatewayGroups to the Registry and API services
> * [ ] Create the GatewayGroups in the migration script by calling the Registry
> * [ ] add an API service DB event handler to create the GatewayGroups when a new gateway
is created
> Deferred
> * add feature to sharing registry to mark certain groups as being undelete-able
> * add feature to sharing registry to specify a certain group as one that should be added
as admin of all groups created (so gateway admins can edit all groups created in a gateway)

This message was sent by Atlassian JIRA

View raw message