Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Completion Service file spec interface should be more robust #394

Open
d1donlydfink opened this issue Feb 21, 2020 · 1 comment
Open

Completion Service file spec interface should be more robust #394

d1donlydfink opened this issue Feb 21, 2020 · 1 comment

Comments

@d1donlydfink
Copy link

d1donlydfink commented Feb 21, 2020

Currently, CompletionService.submitTaskWithFiles() allows for a file dictionary of the format:

{
    "my_key": "my_file_reference"
}

This is fine for simple default behavior without access control, but it would be much more robust if the value for any key could also support a dictionary. Perhaps a straw-man like this:

{
    "my_key": {
        # Allow the file reference from before, but this time as a key within the sub-dict
        "file_reference": "my_file_reference",

        # Allow a username for accessing the specific file reference.
        # This would allow for multiple files from multiple S3 accounts (say)
        # to be accessed by a single Completion Service Worker.
        "access_user": "my_access_user_name",

        # Allow password for accessing the specific file reference (see above)
        "access_password": "my_access_password",

        # Specify whether the worker requires this file to be present before execution.
        # This is intended to expose the equivalent of the 'immutable' flag to
        # CompletionService clients
        "present_before_execution": True
    }
}

It would be important to also support the original simple key/string-value for backwards compatibility.

@d1donlydfink
Copy link
Author

potentially public

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant