#112 closed defect (fixed)
irods path not correct in production JS for new projects
Reported by: | johren@bbn.com | Owned by: | johren@bbn.com |
---|---|---|---|
Priority: | major | Milestone: | GEC21 |
Component: | JobService | Version: | Sprint4 |
Keywords: | Cc: | divyashri.bhat@gmail.com | |
Dependencies: |
Description
I did some testing with a new project today and noticed that the irods path used when I dumped data to iRODS is incorrect. It does not include the project in the path.
Divya helped me dig into a little more and we saw that the irods_path is not correct in Job Service. It should be geni-joTestNew/new01
johren-joTest081101-2014-08-11T21-22-13: uuid: d71444c5-a763-41f3-8123-62dc41d8d33b href: http://gimi4.casa.umass.edu:8002/jobs/d71444c5-a763-41f3-8123-62dc41d8d33b name: johren-joTest081101-2014-08-11T21-22-13 type: job status: finished oml_db: postgres://oml2:omlisgoodforyou@128.119.44.12/johren-joTest081101-2014-08-11T21-22-13 irods_path: new01 username: johren log_file: http://gimi4.casa.umass.edu:8002/logs/d71444c5-a763-41f3-8123-62dc41d8d33b.log
GES seems to have the correct path:
{ type: "project", uuid: "812aeaf1-8676-4c2c-8226-5dedc8cee997", href: "/projects/812aeaf1-8676-4c2c-8226-5dedc8cee997", name: "joTestNew", path: "geni-joTestNew/", irods_user: "geni-johren1", users: [ ], experiments: [ { uuid: "2c67ef56-773b-4bff-8222-fc30d4e19c99", href: "/experiments/2c67ef56-773b-4bff-8222-fc30d4e19c99", name: "new01", type: "experiment", path: "geni-joTestNew/new01/" }, { uuid: "4dd03846-7f85-4751-9d86-8e57e715e2ce", href: "/experiments/4dd03846-7f85-4751-9d86-8e57e715e2ce", name: "newABC", type: "experiment", path: "geni-joTestNew/newABC/" } ] }
Change History (3)
comment:1 Changed 10 years ago by
Owner: | changed from jack.hong@nicta.com.au to johren@bbn.com |
---|---|
Status: | new → assigned |
comment:2 Changed 10 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I tried reproducing this with two more new projects, new contexts, and new slices. I was not able to reproduce. I will close this as worksforme and reopen if I see it again.
comment:3 Changed 10 years ago by
The problem should only occur when communication to GES takes a bit longer than normal. I updated the repo to handle that situation.
Refs LW Commit #96fb80b
Okay, I just ran another experiment with a new context on the same project and it is working now. I need to do some further isolation of this problem. Assigning to myself to do this.