Should I go ahead and redeploy AWE in production? --Shane On Mar 7, 2014, at 7:59 AM, Jared Bischof <[email protected]> wrote:

Wei's going to send an example. Since AWE has many more features now than the last time it was presented, it's probably a good time to go over the status of AWE on a conference call.

-Jared

On Fri, Mar 7, 2014 at 9:54 AM, Wei Tang <[email protected]> wrote: by default it is: KB_AUTH_TOKEN

On Fri, Mar 7, 2014 at 9:51 AM, Shane Canon <[email protected]> wrote:

Awesome. What is the variable name?

Shane

Sent from my iPhone

On Mar 7, 2014, at 7:43 AM, Wei Tang <[email protected]> wrote:

...

The feature that awe client sets kbase token as env variable before dispatching the actual script has been implemented and committed, which means AWE tasks can now access other kbase services using tokens previously set at job submission.

Thanks Wei

On Tue, Mar 4, 2014 at 5:17 PM, Shane Canon <[email protected]> wrote:

These sounds like good suggestions. I think it is important that AWE tasks should be able to easily interact with KBase services, especially workspace. But we should spend some time thinking about the best model for doing this.

--Shane

On Mar 4, 2014, at 2:49 PM, Wei Tang <[email protected]> wrote:

...

Putting aside the security issue, AWE can be enhanced to support following:

In the task description section of the workflow document, we add a field as ENV_VARS (along the cmd name/arg list), and let awe-client to set environmental variables based on that field before dispatch the actual script. In this way, we can pass needed token for certain tasks to access other kbase services (other than shock). This works for some scripts that retrieves token from environmental variables instead of command line args. The job submitter will need to define the needed token for each task in workflow template.

Pls let me know if this feature is useful. We can add it to the feature list.

Thanks Wei

On Tue, Mar 4, 2014 at 4:33 PM, Jared Bischof <[email protected]> wrote: You could pass the KBase token as a command line argument for a given task or we could even create another option for setting an environment variable for a task. This isn't a secure way of handling things but I haven't seen a better solution for this yet in the KBase infrastructure. Suggestions are welcome.

-Jared

On Tue, Mar 4, 2014 at 4:26 PM, Desai, Narayan <[email protected]> wrote: The task isn't exposed to the runtime environment for tasks, it is only used for data movement. We do all of this with restricted use tokens that are only good for a single shock object, so it wouldn't be useful for the workspace, etc. -nld

On Mar 4, 2014, at 3:56 PM, Shane Canon wrote:

...

Wei,

If a worker task needed to use the token to access another KBase service (i.e. the workspace), how could the task access the token? Or is this allowed?

--Shane

On Feb 28, 2014, at 1:56 PM, Wei Tang <[email protected]> wrote:

...

Yes, AWE can pass tokens to use authenticated shock, following is the how it currently working.

When a AWE job is submitted and it need to use private shock data, one need to specify the shock token for that data in the header of the POST call for job submission. And the token (associated with the job) will be stored in mongodb at awe server.

When a awe-client checks out a workunit from AWE, the workunit description tells whether this workunit needs token to get input data. if yes, the awe-client will issue another GET request to get the token from the AWE server, and continue to use that token to talk to shock, either for file downloading and uploading.

Thanks Wei

On Fri, Feb 28, 2014 at 3:40 PM, Narayan Desai <[email protected]> wrote: Wei has done this for AWE. Wei? -nld

On Feb 28, 2014, at 2:47 PM, Olson, Robert D. wrote:

...

Does anyone have a service backend working that accesses authenticated Shock based on the credentials coming in from an authenticated service call? I seem to recall that when Tom and I tried this during our last bootcamp we had a lot of trouble with it.

thanks, --bob _______________________________________________ Kbase-devel mailing list [email protected] https://lists.kbase.us/mailman/listinfo/kbase-devel

_______________________________________________ Kbase-devel mailing list [email protected] https://lists.kbase.us/mailman/listinfo/kbase-devel

_______________________________________________ Kbase-devel mailing list [email protected] https://lists.kbase.us/mailman/listinfo/kbase-devel

_______________________________________________ Kbase-devel mailing list [email protected] https://lists.kbase.us/mailman/listinfo/kbase-devel

_______________________________________________ Kbase-devel mailing list [email protected] https://lists.kbase.us/mailman/listinfo/kbase-devel

_______________________________________________ Kbase-devel mailing list [email protected] https://lists.kbase.us/mailman/listinfo/kbase-devel

_______________________________________________ Kbase-devel mailing list [email protected] https://lists.kbase.us/mailman/listinfo/kbase-devel