Open StevenCTimm opened 3 years ago
@StevenCTimm This changed w/ provides/consumes decorators. I think it has been simplified but the need for the change is still there. Am I correct? Is the syntax different now?
No this has nothing to do with provides/consumes decorators. This has to do with the flags that are set in the Decision engine above and passed to the publishers. Right now there is only one binary flag, either publish all or none of the AWS classads, all or none of the GCE classads, all or none of the LCF classads. We need to be able to control that on a VO by VO basis.
This issue now urgent because for the first time we have two different FIFE VO's running on NERSC simultaneously, would like to make sure in the channel redesign this feature takes priority.
Currently the logic engine in gpde01 channel gp_resource_request is configured to do the following:
The publishers glideclient_manifests /glideclientglobal_manifests are called based on the expression _publishrequests which works out to be always true.
There are four other Facts that are set and stored in a data block by the Logic Engine, namely allow_grid_requests, allow_aws_requests, allow_gce_requests, and allow_lcf_requests.
The Publisher is called to Consume two datablocks, the glideclientglobal_manifests and the glideclient_manifests, both of which already include fully formed classads containing all resource types
If the allow_lcf_requests flag is true then all requests for LCF (which in current configuration is only NERSC) are published unconditionally. If false, then they are all dropped unconditionally.
This whole section of resource requests and the transform that makes the classads are supposed to be totally rewritten anyway, but when they are, then we need to have the capacity to selectively publish some NERSC request classads and not others, based on which VO is authorized to use NERSC at any given time and has allocation to do so. For instance we should be able to publish classads for GM2 and not for DUNE if GM2 still has allocation and DUNE does not.
This could be accomplished on a group by group basis for instance, if we continue having the analog of frontend groups such as dune_nersc_passthrough, gm2_nersc_passthrough, nova_nersc_passthrough. You could send only those glideclient classads for those that have the quota as determined by the logic engine.