Backing up CFG and INI: Working area needs to be changed to mu2epro

[sophiemiddleton]

Currently when testing there is no record of the CFG and INI used for a specific test. It is possible to find out the parameters via reverse engineering but it takes time.

We should make sure tests are backed up. To do this we could use the mu2epro account. I suggested this to Ray, hear are his thoughts:

" It is hard to imagine all the details at once, but here
is the direction I would try. Note that the mu2epro
home area is backed up every night.

• in the mu2epro home area create your
  working dir, something like "prodTest"
• checkout Production repo there
• rework the cfg so it has a switch, something like
  codesource=/mu2e/app/home/mu2epro/prodTest
  codesource=/cvmfs/.../MDC2020u
  so you can easily switch back and forth
• make changes in the local Production repo, commit
  as they are finalized
• while you are at it add a switch like
  outputDir=/pnfs/mu2e/tape/...
  outputDir=/pnfs/mu2e/persistent/...
  so you can switch that back and forth.
  you might be able to make both into one switch
• I'd make POMS changes in the GUI
  and run off that for tests. you might need a switch there too.

When tests are done,

• set switches to production mode
• extract POMS GUI to an ini, add that
  to the local repo
• update cvmfs codeSource to point to next tag
• commit all, tag, publish
• run production

This a bit messy. The main thing is to summarize
test mode vs production mode with a few switches,
so there is minimal to remember when you make the switch.
It is also less likely to create a bug.

I think everything intended for production should be done in
the mu2epro account."

There are two things to do here:

1. Set up the mu2epro home area
2. Add these new switches

[kutschke]

Hi Sophie, Overall I like to spirit of this. A few comments. This does not capture the test as it was run – it requires changing things after you do that test. Depending what you are looking for that could be OK. Since there are several steps following a successful test, I suggest you make a checklist and follow the checklist every time. If you can script the changes, that’s even better. If you need to capture the actual “as run” test, you need a new branch in the repo. One nice feature of this is that you can diff commits on the test branch with the matching one on the main branch to have a second check that you did the handwork correctly. Rob From: Sophie Middleton ***@***.***> Reply-To: Mu2e/Production ***@***.***> Date: Thursday, November 10, 2022 at 9:11 AM To: Mu2e/Production ***@***.***> Cc: Subscribed ***@***.***> Subject: [Mu2e/Production] Backing up CFG and INI (Issue #214) Currently when testing there is no record of the CFG and INI used for a specific test. It is possible to find out the parameters via reverse engineering but it takes time. We should make sure tests are backed up. To do this we could use the mu2epro account. I suggested this to Ray, hear are his thoughts: " It is hard to imagine all the details at once, but here is the direction I would try. Note that the mu2epro home area is backed up every night. · in the mu2epro home area create your working dir, something like "prodTest" · checkout Production repo there · rework the cfg so it has a switch, something like codesource=/mu2e/app/home/mu2epro/prodTest codesource=/cvmfs/.../MDC2020u so you can easily switch back and forth · make changes in the local Production repo, commit as they are finalized · while you are at it add a switch like outputDir=/pnfs/mu2e/tape/... outputDir=/pnfs/mu2e/persistent/... so you can switch that back and forth. you might be able to make both into one switch · I'd make POMS changes in the GUI and run off that for tests. you might need a switch there too. When tests are done, · set switches to production mode · extract POMS GUI to an ini, add that to the local repo · update cvmfs codeSource to point to next tag · commit all, tag, publish · run production This a bit messy. The main thing is to summarize test mode vs production mode with a few switches, so there is minimal to remember when you make the switch. It is also less likely to create a bug. I think everything intended for production should be done in the mu2epro account." There are two things to do here: 1. Set up the mu2epro home area 2. Add these new switches — Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Mu2e_Production_issues_214&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=Zi5IH-k2_JiK_Wipiv3pwwSXO9UNaHiLP8sisfPz__k&m=PQDF78xKy0np0iraQG1BsAP28q2Dso-KO9Xk4jK6-vMopsCpeTM66HydCsV9bShX&s=ytdyu-CQxUGVhNIntveZ4nqS3P4bNUFSNlwywX-A9GY&e=>, or unsubscribe<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ABHY5ZQREDQU56OUO4D3Y5TWHUGDPANCNFSM6AAAAAAR4VEVWE&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=Zi5IH-k2_JiK_Wipiv3pwwSXO9UNaHiLP8sisfPz__k&m=PQDF78xKy0np0iraQG1BsAP28q2Dso-KO9Xk4jK6-vMopsCpeTM66HydCsV9bShX&s=zc8rR1k0XY76qa4Rlp_v540Rp35FjiRbksFj_JTqLyE&e=>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[kutschke]

We we discuss #216 and #216, we should think about this too. I suspect that finding a good solution for those will make it easier to solve this problem.