airavata-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AIRAVATA-2806) Decide what to do with GatewayResourceProfile and its ComputeResourcePreferences
Date Fri, 03 Aug 2018 20:08:00 GMT

    [ https://issues.apache.org/jira/browse/AIRAVATA-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16568699#comment-16568699
] 

ASF subversion and git services commented on AIRAVATA-2806:
-----------------------------------------------------------

Commit 825218d752e85b9b9d5756ab7da632a4f9abefce in airavata's branch refs/heads/develop from
[~marcuschristie]
[ https://gitbox.apache.org/repos/asf?p=airavata.git;h=825218d ]

AIRAVATA-2806 Removing duplicate methods


> Decide what to do with GatewayResourceProfile and its ComputeResourcePreferences
> --------------------------------------------------------------------------------
>
>                 Key: AIRAVATA-2806
>                 URL: https://issues.apache.org/jira/browse/AIRAVATA-2806
>             Project: Airavata
>          Issue Type: Story
>            Reporter: Marcus Christie
>            Priority: Major
>
> I think we have a couple of different options. First, we can just drop ComputeResourcePreferences
from GatewayResourceProfile. Second, we can use it as a source of default values for the GroupComputeResourcePreferences.
 The main advantage of using it as a source of default values it the use case of a gateway
admin using a community account and setting up the loginUserName, scratchLocation etc. and
then another user can create a GroupResourceProfile that uses a different allocation but authenticates
using the default values in the ComputeResourcePreferences.
> Here's some analysis of which of the various fields of the ComputeResourcePreferences
can be used as defaults:
> * overridebyAiravata - not sure what this means, but doesn't seem a good candidate
> * *loginUserName* - could use as a default
> * *preferredJobSubmissionProtocol* - could use as a default
> * *preferredDataMovementProtocol* - could use as a default
> * *preferredBatchQueue* - could use as a default.
> * *scratchLocation* - could use as a default. This goes hand in hand with loginUserName,
that is, this scratchLocation must be writeable by that user. So we need to guard against
the edge case that someone uses the default scratchLocation but a different loginUserName
(or vice versa).
> * allocationProjectNumber - never makes sense to use this as a default, the GroupComputeResourcePreference
should specify its own allocation
> * resourceSpecificCredentialStoreToken - likewise, the GroupComputeResourcePreference
should specify its own credentials store token. A credential store token that the gateway
admin has created for authenticating with the ComputeResourcePreferences loginUserName can
be shared with user of the GroupResourceProfile so that they can select it (see AIRAVATA-2840).
> * usageReportingGatewayId (?) - Do we even want to have this field in GroupComputeResourcePreference
> * qualityOfService - doesn't seem to make sense to use this as a default
> * reservation fields - doesn't make sense to use these as defaults since reservations
are tied to the allocation
> * sshAccountProvisioner fields - I think these really only make sense on the ComputeResourcePreferences



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message