Should I go ahead and redeploy AWE in production?--ShaneOn Mar 7, 2014, at 7:59 AM, Jared Bischof <jbischof@gmail.com> 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 <wtang@anl.gov> wrote:
by default it is: KB_AUTH_TOKENOn Fri, Mar 7, 2014 at 9:51 AM, Shane Canon <scanon@lbl.gov> wrote:Awesome. What is the variable name?Shane
Sent from my iPhoneThe 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.
ThanksWeiOn Tue, Mar 4, 2014 at 5:17 PM, Shane Canon <scanon@lbl.gov> 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 sometime thinking about the best model for doing this.--ShaneOn Mar 4, 2014, at 2:49 PM, Wei Tang <wtang@anl.gov> 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.ThanksWei_______________________________________________On Tue, Mar 4, 2014 at 4:33 PM, Jared Bischof <jbischof@gmail.com> 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 <desai@mcs.anl.gov> 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 <wtang@mcs.anl.gov> 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 <desai@mcs.anl.gov> 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
Kbase-devel@lists.kbase.us
https://lists.kbase.us/mailman/listinfo/kbase-devel
_______________________________________________
Kbase-devel mailing list
Kbase-devel@lists.kbase.us
https://lists.kbase.us/mailman/listinfo/kbase-devel
Kbase-devel mailing list
Kbase-devel@lists.kbase.us
https://lists.kbase.us/mailman/listinfo/kbase-devel
_______________________________________________
Kbase-devel mailing list
Kbase-devel@lists.kbase.us
https://lists.kbase.us/mailman/listinfo/kbase-devel
Kbase-devel mailing list
Kbase-devel@lists.kbase.us
https://lists.kbase.us/mailman/listinfo/kbase-devel
_______________________________________________
Kbase-devel mailing list
Kbase-devel@lists.kbase.us
https://lists.kbase.us/mailman/listinfo/kbase-devel
_______________________________________________
Kbase-devel mailing list
Kbase-devel@lists.kbase.us
https://lists.kbase.us/mailman/listinfo/kbase-devel