Fix LFN naming

[sfoulkes]

The output files don't follow the CMS naming convention at https://twiki.cern.ch/twiki/bin/view/CMS/DMWMPG_Namespace . The data tier is being put before the Acquisition Era, the primary dataset is missing, etc. This needs to be fixed asap

[DMWMBot]

mnorman: Will that do?

[drsm79]

metson: The LFN's should be checked against a regexp in Lexicon to make sure that there's nothing funny happening in the substitution and that the various strings conform to the expected standards (e.g. no extra / etc.), see also #943.

[sfoulkes]

sfoulkes: Norman is working on 943 and will fold the lfn checks into that ticket.

[drsm79]

metson: Sweet.

[DMWMBot]

mnorman: Added name change to keep Steve from getting the vapors (he's got a problem with remembering names).

[sfoulkes]

sfoulkes: (In 7808797) Fix LFN naming. Fixes #1156.

From: Matt Norman mnorman@fnal.gov
Signed-off-by: Steve Foulkes sfoulkes@fnal.gov

[sfoulkes]

sfoulkes: (In 11653) Fix LFN naming. Fixes #1156.

From: Matt Norman mnorman@fnal.gov
Signed-off-by: Steve Foulkes sfoulkes@fnal.gov

[drsm79]

metson: The substitutions should be replaced by a call to Lexicon - we need to have one place where LFN's are generated and that should be Lexicon.

[DMWMBot]

mnorman: Why?

I could understand that if there was actually some mechanics involved in creating the LFN, but what we're doing here is joining N strings together into one string. That's not so complicated an idea that it requires a separate function, especially since it still leaves the developer in charge of figuring out which item goes where. Is there a point to us writing our own implementation of "%s/%s"?

[drsm79]

metson: The point is to have the substitution in one place, not in N. We have had requests to slightly tweak the LFN (including block ID in it some how), that's made significantly simpler if there's only one place we need to make that change.

Also, WMAgent isn't the only tool that uses LFN's. Things like DBS should be using the same code as the stage out etc.

[DMWMBot]

mnorman: What are the prospects of actually having to make a series of changes to the LFN format?

And I think the difference in what it will make us do is minimal. If you're going to add information, you have to re-write the code that would call it anyway - all you're doing is just rearranging the rewrites.

Also, a different question here, is LFN naming guaranteed to be universal? Is AnalysisOps guaranteeing that all user analysis datasets will also comply with the LFN schema we've set out?

[drsm79]

metson: Replying to [comment:12 mnorman]:

Also, a different question here, is LFN naming guaranteed to be universal? Is AnalysisOps guaranteeing that all user analysis datasets will also comply with the LFN schema we've set out?

Yes. It's a universal naming convention. The problems in the past have been that the convention hasn't been consistently applied by our applications, hence wanting this in one place...