Project

General

Profile

January 23th

Date:

01/24/2018 Note: the meeting has been moved to January 24th.

Attendees:

Anna M, Steve W, Margaret V, Marc M, Robert I, Brandon W, Vladimir P, Yuyi G, Margherita VW.

Agenda:

Updates on status for release v2.3.0

Discussion:

1) Updates on status for release v2.3.0

STEVE:
New code for Roles and change of root as flag is working; still need to update some html files.

ANNA:
What about check boxes needed because of the different permission actions for different roles?

STEVE:
On going.

MARC:
Showing page for campaign stages: showing how it is reorganized, where Status and Actions are split.
Showing tags with dependencies and submissions.
We have hold and release buttons for the campaign.

ANNA:
In this way we will have the big picture and see from the web page which stage we are on.
In the campaign dependencies we can see the experiment, who is logged in and the role.

MARC:
We also show the split data set in the campaign page.

ANNA:
If submission fails, we don’t have a reset to start from beginning..

MARC:
We can have more parameters definitions.

ANNA:
Please open a task for this work.

MARC:
Recent launch Outputs: name is encoded in the output.

ANNA:
So we can track who is launching the submission. This is very important for tracking the person who is submitting the jobs.

MARC:
Adding a POMS “launcher” tag; still testing. If we go to schedule future jobs, the current crontab shows the id of the launcher. Each user has an exp id when job is launched.

ANNA:
Any conflict in the database?

MARC:
The ony database change was for queued launches.

ANNA:
We need to know who is holding the job. We needed to understand who could do what, that’s why we needed this extra info.
Question: We attach a user to an experiment using information from VOMS. How about the roles?

STEVE:
The only info VOMS is returning to us is who has a Production role.

ANNA:
We saw in the past the VOMS is not always updated and user doesn’t have role production and we saw many times that people who are “doing production” work are not in VOMS with production role..

MARC:
We could fix the script. For now, the script only checks if people exist but not the role.
Some more work will be done with FERRY.

ANNA:
FERRY will pull the info into VOMS. We need VOMS to be reliable and updated.
Another problem is when a person wants to use POMS but s/he doesn’t exist yet in VOMS.

MARGARET:
Why couldn’t people wait for a little time?

ANNA:
They can, but we need to make sure that VOMS is updated when a new person make the request.

MARC:
Problem is that last minute they show to be on shift and need to use POMS and don’t exist in VOMS yet…

ANNA:
We don’t need to add anything by hand. But we need to rely in other services.

STEVE:
As far as security, all is in place.

MARC:
The new user might run into the problem that cannot do certain operations in the new release.

ANNA:
We need to advise the users about the role changes.
As said, NOVA might have problems because they are not consistent with the role they are using for production and the role they have in their campaigns.

STEVE:
They can use devel version and have a look.

MARC:
We need to have an integration version.

ANNA:
We have already discuss that. We need an integration instance for two reasons. To integrate all changes from the development branches and to to give users the
possibility to test a new release.
Question: for confirmation, can a user with role production who is not the creator of a production campaign do anything?

MARC:
with the actual production release, they can pick any campaign and do anything.
In the new release, there will be no job with role production that is not tagged as production.
You can have a POMS production campaign that is run with role analysis.

ANNA:
Uhm... NOVA is running production jobs with role analysis in POMS. We need to check those campaigns. I imagine that in their submission script they put role
production.
This way people login with their own credentials but then they are mapped to novapro by the jobsub server if they use the role production.
When POMS role and VO role are the same, I mean POMS campaign will reflect the role used for the submission, then if a POMS production campaign has role
analysis, then they need to know they could run into problems.

YUYI:
Showing campaign stage page. Need to add a check box and make a new column so you can select the campaign you want to work on.

ANNA:
How about having a “all” check box to see all the statistics.

STEVE:
We will add the check box column.

MARGARET:
Question: where do we stand with being able to release jobs with more memory?

MARC:
We have parameters from Parag but need to do more testing.
We could add the parameters already with the current release if we need.

ANNA:
This is high priority. Ivan saw that problem last time, he had all the jobs with memory issues in the DC1.5 campaigns.
Tanya is in contact with Icarus and I am in contact with SBND.
They want to use POMS. That’s why we want to push this new release so we don’t have
to do training twice. They are not planning to use project.py.

MARGARET:
What is the model for testing?

MARC:
We have regression tests suite and then we are doing testing running small campaigns
and going through all the pages in POMS and see that nothing is broken.