You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@airavata.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2018/08/03 20:08:00 UTC

[jira] [Commented] (AIRAVATA-2806) Decide what to do with GatewayResourceProfile and its ComputeResourcePreferences

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

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

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

AIRAVATA-2806 ComputeResourcePreference default values

Fixing up which fields are used from ComputeResourcePreferences for
defualt values.


> 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)