Development musing

[sophiemiddleton]

During a conversation with @dnbrow01 we thought of an idea for testing code or mid-development running. That is to have a musing MDC2020... where ... is to be decided. This would always be a testing musing useful only to ensure everything is working. This avoid need to modify script paths or issues when changing primary fcl files.

[rlcee]

Currently the process of building and deploying musings in the official musing location requires tags, but it would be straightforward to include an option to build the head and call it "dev" or something like that.

But there is already something like this now. At every merge of Offline, we build the head of Production and Offline (i.e. make SimJob out of the head), and put that on the development cvmfs. We currently keep the last ~10 of these and purge older ones. You can setup the latest:
muse setup HEAD
or chose a specific build for more stability:
muse setup main/412ec771
where "main" is the branch and the hash is the git hash of the head commit at the time. See
ls -lt /cvmfs/mu2e-development.opensciencegrid.org/museCIBuild/main

[kutschke]

Do you always want both the head of Offline and the head of Production in this? Or will you sometimes want an older Offline with the head of Production?

[dnbrow01]

This was likely a conversation with Dave from LBL, who I copy here. I'm on the road, otherwise I would use his GitHub tag to include him - sorry. Best Regards, Dave (KY) Brown

…

On May 19, 2023, at 7:46 AM, Sophie Middleton ***@***.***> wrote: CAUTION: This email originated from outside of our organization. Do not click links, open attachments, or respond unless you recognize the sender's email address and know the contents are safe. During a conversation with @dnbrow01 we thought of an idea for testing code or mid-development running. That is to have a musing MDC2020... where ... is to be decided. This would always be a testing musing useful only to ensure everything is working. This avoid need to modify script paths or issues when changing primary fcl files. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[brownd1978]

my github id is brownd1978 Dave

…

On Fri, May 19, 2023 at 5:46 AM Sophie Middleton ***@***.***> wrote: During a conversation with @dnbrow01 <https://github.com/dnbrow01> we thought of an idea for testing code or mid-development running. That is to have a musing MDC2020... where ... is to be decided. This would always be a testing musing useful only to ensure everything is working. This avoid need to modify script paths or issues when changing primary fcl files. — Reply to this email directly, view it on GitHub <#256>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABAH5763GHOKJBNYXUXS3H3XG5TRDANCNFSM6AAAAAAYHXUJTM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- David Brown ***@***.*** Office Phone (510) 486-7261 Lawrence Berkeley National Lab M/S 50R5008 (50-6026C) Berkeley, CA 94720

[sophiemiddleton]

I think it would be HEAD of Production, the Offline version could be the last official release though or HEAD, its mostly for Production development

[sophiemiddleton]

@rlcee can you make one of these development SimJobs for the current HEAD of production? And let me if I can also do that

[rlcee]

I think the process of building Musings on Jenkins, based on a record in MuseConfig, is all about having a specific audit trail of what was build. In this case I'm assuming there is no need for a permanent audit trail, so the Jenkins build isn't really necessary. If you agree, then it is pretty simple. You can create you own build area, checkout Production and set backing to the Offline you want. Make your mods then build and run "muse tarball". The only trick it is use "-r " here. That forces the tarball to be in release format, which is ready to install in Musings. I think using your own build area will speed up your development cycle. I'd suggesting thinking about how to indicate to users, who will see these releases at the top of their list, that this is not permanent. Maybe naming verisons like "MDC2020ydev" or temp, dev, scratch something so it is clear. I'd also like to ask you to clean these up when you are done.
If you want even faster development, once you have your dev release on cvmfs, you can start a cvmfs transaction and just edit the files there, and publish, so for tweaks you don't even need the build step.

[kutschke]

For a name, how about rc0, rc1 etc for release candidate? From: Ray Culbertson ***@***.***> Reply-To: Mu2e/Production ***@***.***> Date: Monday, May 22, 2023 at 9:15 AM To: Mu2e/Production ***@***.***> Cc: Rob Kutschke ***@***.***>, Comment ***@***.***> Subject: Re: [Mu2e/Production] Development musing (Issue #256) I think the process of building Musings on Jenkins, based on a record in MuseConfig, is all about having a specific audit trail of what was build. In this case I'm assuming there is no need for a permanent audit trail, so the Jenkins build isn't really necessary. If you agree, then it is pretty simple. You can create you own build area, checkout Production and set backing to the Offline you want. Make your mods then build and run "muse tarball". The only trick it is use "-r " here. That forces the tarball to be in release format, which is ready to install in Musings. I think using your own build area will speed up your development cycle. I'd suggesting thinking about how to indicate to users, who will see these releases at the top of their list, that this is not permanent. Maybe naming verisons like "MDC2020ydev" or temp, dev, scratch something so it is clear. I'd also like to ask you to clean these up when you are done. If you want even faster development, once you have your dev release on cvmfs, you can start a cvmfs transaction and just edit the files there, and publish, so for tweaks you don't even need the build step. — Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Mu2e_Production_issues_256-23issuecomment-2D1557301647&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=Zi5IH-k2_JiK_Wipiv3pwwSXO9UNaHiLP8sisfPz__k&m=iZba_-2265Ic1pVwfcj2-BJJoSKWbfhhDnYahI0z0Nq6PsAzW6uId-4eY9QMlC6p&s=omsCY3ORVP80lFEGijxwte3xQ8wK4YS8TEMllHft5EI&e=>, or unsubscribe<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ABHY5ZSC4HYPPVOIPZAL7WLXHNYITANCNFSM6AAAAAAYHXUJTM&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=Zi5IH-k2_JiK_Wipiv3pwwSXO9UNaHiLP8sisfPz__k&m=iZba_-2265Ic1pVwfcj2-BJJoSKWbfhhDnYahI0z0Nq6PsAzW6uId-4eY9QMlC6p&s=7_FTmVyXw-6xfT7y7d_FBedF-CzhoDj0Dc4QHbdMv4Y&e=>. You are receiving this because you commented.Message ID: ***@***.***>

[kutschke]

I would go through the extra step of always doing the work in the working clone rather than editing cvmfs in place. It does add a little overhead but it removes one possibility to forget to add something back to the working clone.

[brownd1978]

I agree that having everything in cvmfs is a better test. Since Offline is backing it should be fast to create these with just a new production.

On Mon, May 22, 2023 at 07:41 Rob Kutschke ***@***.***> wrote: I would go through the extra step of always doing the work in the working clone rather than editing cvmfs in place. It does add a little overhead but it removes one possibility to forget to add something back to the working clone. — Reply to this email directly, view it on GitHub <#256 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABAH575JRX4DLDDICFHXW7LXHN3IJANCNFSM6AAAAAAYHXUJTM> . You are receiving this because you commented.Message ID: ***@***.***>

-- David Brown ***@***.*** Office Phone (510) 486-7261 Lawrence Berkeley National Lab M/S 50R5008 (50-6026C) Berkeley, CA 94720

[kutschke]

Clarifying me earlier content. If you are working towards MDC2020y, then the name of the first release candidate would be MDC2020y_rc0.

[kutschke]

A common progression is that MDC2020y would be a tag on the same commit as the final rc.

[brownd1978]

Can we implement this so that the cfg can refer to MDC2020y, not MDC2020y_rc0? Otherwise we’ll always need a final name change commit and tag before starting the official production.

On Mon, May 22, 2023 at 07:52 Rob Kutschke ***@***.***> wrote: A common progression is that MDC2020y would be a tag on the same commit as the final rc. — Reply to this email directly, view it on GitHub <#256 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABAH576NNVECMSPOBIAQNTDXHN4TRANCNFSM6AAAAAAYHXUJTM> . You are receiving this because you commented.Message ID: ***@***.***>

-- David Brown ***@***.*** Office Phone (510) 486-7261 Lawrence Berkeley National Lab M/S 50R5008 (50-6026C) Berkeley, CA 94720

[kutschke]

Can we implement this so that the cfg can refer to MDC2020y, not MDC2020y_rc0? Otherwise we’ll always need a final name change commit and tag before starting the official production.

Offhand, I see two ways to do this. One is that, during development, we maintain MDC2020y as a link to the most recent rc.

Another is to embed logic in the POMS scripts that says: if MDC2020 exists use it; if it does not use the highest numbered rc; if there are no rc's, fail.

Does anyone see a way to automate the former? Other ideas?

[rlcee]

There are no if's in cfg. The cfg now has the SimJob version separate from the config field of the dataset names, so that could help (depending). Then you can play games with POMS production versus test submits, combined with variable precedence rules and include files, resulting in overrides or redirection. I am using some of this in pass1. I was eventually going to apply some of this to sim recommendations. If you want to hurry up and do that now, I'd probably want to take a day or so this develop the ideas into a plan. Another approach is to wrench the action out of the cfg and into bash scripts. But really I'm not sure of the exact problem we're solving - it might actually be fairly easy.
One thing I think is wrong is to present MDC2020y in the published location, but not in the final form.