Anna M, Steve W, Marc M, Robert I, Brandon W, Vladimir P. Yuyi G, Margherita VW.
- Roles in POMS (Steve/Yuyi)
- POMS v2_3_0 status
1) Roles in POMS (Steve/Yuyi)
Slides presentation on Roles we want to introduce in POMS.
We currently have: ROOT, (which is kind of fake role) and Production role,
kind of faked also, we all have that role.
WE want to introduce , besides ROOT, for each experiment these roles:
We want to get info from VOMS every 24 hours and want to update DB.
We need to make sure that what is in VOMS is correct but at times is quite not updated.
Get from VOMS the experiment the person belong to. By default people have role analysis.
Then we want experiment to tell us who should have a Production role and store that in DB.
FERRY in the future should be the single source of people info.
Yes, until when FERRY will be operative we need a solution.
DB schema will be changed to have a ROLES table with real ROLES info.
AS far as "HOLDS" information: add a "hold id" in campaign table to store the id
of the person who put the hold.
Show on screen current experiment and role: "Coordinator" can hold any.
"Analysis" role people can only hold their own campaigns.
A user can only have one role.
We could provide different views depending on the role.
Should people pick a role?
Analysis and Production roles would be disconnected.
First step, make schema changes to allow new roles and then we we worry about how to assign the roles.
If you have production role you can see everything; valid within the session, not stored in DB.
Yuyi mentioned that in DB we store only one role per person. What if I want to change role because
I need to submit different type of jobs, like going from production to analysis?
You can change dynamically if you have different sessions.
We might save in DB the experimenter and the role was selected.
We might need more roles..
We have the design laid out, the we can work on details..
Do we need different coordinators roles?
The Coordinator assigns the roles.
Maybe it could be advantageous to make the DB more complicated now for future situations.
2) POMS v2_3_0 status, reviewing tasks.
14835: about email reports. This is complicated. Issue between what already available with jobsub.
need to make sure people would not get the same email from both POMS and jobsub.
POMS could handle the e-mails report through jobsub or directly. I don't remember project.py has e-mail option.
We can do that at a wrapper level, we could pass options to project.py from POMS.
Yes! If project.py has not this option, we can use your wrapper.
Not ready to do anything yet(Steve).
We will not delay next release to include this.
We will define a future version and include that in it.
17741: about "tag" button. Talked with Vladimir.
Right now we can tag only AFTER the campaign is created.
We want ability to set the tag when we create it.
Also have, in the summary page, a tag/ untag button.
17774: about links:
STEVE: Resolved, open links in another tab.
However, we agreed we want an "External Links" menu option an put under the links to ECL, SNOW etc.
17779: about campaign_type. Having working version in devel; need to test cases with real submissions.
We have a list of possible types. 'Transfer' is an important type, we don't currently support but
needed in long term for DUNE which will need to use when transferring files between CERN and FNAL.
Could we treat the "pre-staging" as a transfer type?
Prestaging is now done in SAM...
Transfer doesn't generate new data, just moves files around. We need to have a flag in the workflow.
I have been implementing a new data transfer system.. could we force a "prestaging DCache"
and treat it as a "transfer" stage ?
It will become important for statistics regarding data transfers..
Last thing, done a little work on POMS client.Checked scripts that Felipe put together
and have a pre-release next week.
Define a date for next release:
- Have a date with what we have to implement now (except archiving)
- Delay and put some small bugs still there.