[
https://issues.apache.org/jira/browse/AIRAVATA-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16637030#comment-16637030
]
ASF subversion and git services commented on AIRAVATA-2806:
-----------------------------------------------------------
Commit 3bd208b2443597f25b4266b10227ef0693b99e9a in airavata's branch
refs/heads/develop from [~marcuschristie]
[ https://gitbox.apache.org/repos/asf?p=airavata.git;h=3bd208b ]
AIRAVATA-2806 AIRAVATA-2865 Replace CompResPreference in orch, helix
> 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
> Assignee: 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)
