[
https://issues.apache.org/jira/browse/AIRAVATA-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Christie updated AIRAVATA-2806:
--------------------------------------
Description:
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
> 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)
