era as attribute of campaign

[franzoni]

With reference to the decisions agreed here :

https://indico.cern.ch/event/336527/ https://indico.cern.ch/event/336527/material/minutes/minutes.html

An mcm campaign needs be specified of an 'era parameter' to be used to set AcquisitionEra (which currently is always set to the campaign name) in the requests. For any new campaign, setting the 'era parameter' is mandatory: either to the name of the current campaign or to the name of an already existitg campaign. A non valid value is set as defailt for the 'era parameter' in the process of campaign creation => assure the prod manager sets it.

All the already existing campaigns won't have the 'era parameter' specified; only in that sopecific case foresse that mcm sets the 'era parameter' to the campaign name.

Consider https://github.com/cms-PdmV/wmcontrol/pull/3 in wmcontrol as part of the process.

[srimanob]

Do this mean updating the database (adding new information box)? If it's the case, I think we can somehow define "Era" for current campaigns/requests.

[vlimant]

If I may. The mapping Campaign 2 Era is purely a computing issue and IMO does not have to be specified from McM, but rather at the "interface", or even in Ops side. I explain : the requests are injected with (modulo the PRs) "Campaign" and "ProcessingString" specified, but not "AcquisitionEra" which is over-written by Ops (they chose the convention era=campaign) which therefore is fully in their hands. There are several options in making this change without having to add a member to campaign&request, like :

• having Ops take care of what lfn to use (i.e acquistion era is explicitely a directory on the storage elements) depending on the campaign (and advertise it back)
• adding a mapping in wmcontrol, wish fails injection if the mapping is missing
• adding a settings in McM with the mapping and use it in https://github.com/cms-PdmV/cmsPdmV/blob/master/mcm/tools/request_to_wma.py (somehow equivalent to the previous solution) and add an --era option to wmcontrol
• add era to campaign/request, operate a migration to all existing request (tricky part), pass it to the request_to_wma and --era option to wmcontrol

[franzoni]

Hi Jr, thanks for the comments.

" Campaign 2 Era is purely a computing issue" , is the easiest of the scenarios: the dataops fellows handle the AcquisitionEra parameter and we don't provide anthing for it.

Looking back at the minutes https://indico.cern.ch/event/336527/material/minutes/minutes.html, there's no specific reference to: 1) "we dataops will handle the AcquisitionEra != campaign_name" vs 2) "we dataops expect mccm to send us a value for AcquisitionEra" We'll clarify with the computing people, and dis-entangle.

If 2) was the outcome, usign a mapping AcquisitionEra<->campaign_name can do as well, and I do see the ease of implementing that db solution (Antanas already knew :-P ). Provided the choice of AcquisitionEra is part of the normal operations of creating a campaign (solution: include an AcquisitionEra field in the pop up which appears from clicking on "Create new Campaign" ).

[vlimant]

On second thinking to this, era could be a member of campaign that does not get passed on to the requests object (no large migration needed). Instead it would get used at injection time (since we can fetch it from the campaign object) with --era option of wmcontrol. The "major" issue is at getting an AcquisitionEra parameter that OPS should decide on in the first place, unless McM is left with the responsibility of tape family management.

The natural thing to do, would be to leave things as they are. When Ops assigns a request from a new campaign, they figure out which tape familly (=acqera) they want to use to optimize resources, update their mapping, and move on. Does not sound over-complicated.

[srimanob]

Just read this thread. Do we have final decision, or plan for postMccM?

[vlimant]

Cross referencing #717 explicitely