Mu2e / Production

Scripts and fcl for collaboration production procedures
Apache License 2.0
0 stars 33 forks source link

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

Open sophiemiddleton opened 1 year ago

sophiemiddleton commented 1 year ago

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.

When tests are done,

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 commented 1 year ago

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 GitHubhttps://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 unsubscribehttps://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 commented 1 year ago

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.