Clone New Windows Build Agent of openPASS to Existing Windows Build Agent of openPASS

We currently operate two Windows build agents within openPASS. We would like to clone the new Windows build agent (9pfnn-win10) to the older one (b9qls-windows-10). The primary objective is to replicate installed packages, and dependencies from the new Windows build agent to the older one. This ensures that both agents are aligned in terms of software versions and configurations, streamlining our development and build processes.

Before proceeding with the actual implementation, we have a couple of questions.

1. We would want to know the possible methods for cloning the new Windows build agent to the old one.
2. We would also like to know if there is a process to ensure that future updates and modifications are applied consistently across both build agents.

Note: Please do not proceed with the update right away. We would at first want to know the possible ways for above mentioned questions

added IT-prioritylow IT-severitylow labels

marked this issue as related to #4168 (closed)

added Enhancement label

1. We would want to know the possible methods for cloning the new Windows build agent to the old one.

In general, it seems to be possible to clone a Windows VM (see https://dev.to/icebeam7/cloning-azure-vms-1889 for example).

2. We would also like to know if there is a process to ensure that future updates and modifications are applied consistently across both build agents.

So far, I have not found an established process to handle continuous synchronization without the help of Infrastructure-as-Code tools like Ansible or Terraform.

added team:releng label

added statetodo label

added service:CI label

removed service:CI label

In general, it seems to be possible to clone a Windows VM (see https://dev.to/icebeam7/cloning-azure-vms-1889 for example).

I posted an announcement on the mailing list. Assuming no developers raise any concerns, we'd like to proceed with the update of the old agent by cloning the new one on March 22. This will also make #4364 (closed) obsolete.

So far, I have not found an established process to handle continuous synchronization without the help of Infrastructure-as-Code tools like Ansible or Terraform.

With respect to the latest CI updates here for the opGui build, I wonder if it would be ok if we use pip install and pacman inside of our build jobs to manage the environments. I remember being asked not to do that, but some years have passed in the meantime.

mentioned in issue #4364 (closed)

assigned to @fgurr

I posted an announcement on the mailing list. Assuming no developers raise any concerns, we'd like to proceed with the update of the old agent by cloning the new one on March 22. This will also make #4364 (closed) obsolete.

As noted above, this would be a one-time thing, since there is no process for continuous synchronization. For future events, we appreciated coordinating dates with us in advance before communicating them publicly.

With respect to the latest CI updates here for the opGui build, I wonder if it would be ok if we use pip install and pacman inside of our build jobs to manage the environments. I remember being asked not to do that, but some years have passed in the meantime.

You might be able to use virtual Python environments for that: https://docs.python.org/3/library/venv.html

For future events, we appreciated coordinating dates with us in advance before communicating them publicly.

I have to apologize: this date wasn't meant for you, but just as a deadline for objections from other developers. If there will be a gap between this date and the actual cloning process, this is perfectly fine for us. Please take your time.

You might be able to use virtual Python environments

Yes, that would of course be our approach. I just had the assumption that we shall not install packages on our own during a build. If this assumption is not true anymore, we could reduce the required management overhead a lot. E.g. we could maintain the required MSYS environment directly via our build jobs. I could imagine having something like python venv also on MSYS level with pacman.

@fgurr @heurtemattes As mentioned in the above comments, if there exists no objection before 22.03.2022 from other developer, we wanted to inform you to proceed with the clone.

However, a minor change needs to be done in couple of repos before proceeding with the clone so that these repos will not fail after clone.

We are hoping the change might get done at latest by early next week. Therefore, we request you to not clone until further confirmation from our end.

Thank you for your understanding.

Ok. We are planning to schedule the cloning for Tuesday or Wednesday next week pending confirmation from your end.

@fgurr Thank you for waiting for our response. We now have a green signal to proceed with the clone. Therefore, could you please proceed with the cloning. Also, once you have time/date planned for the cloning, please do inform us, so that we can plan further work from our side after cloning. Thank you very much

I am planning to do the cloning on Wednesday, April 3.

added Awaiting Feedback label

removed Awaiting Feedback label

added statewip label and removed statetodo label

To avoid destructive actions, Agent 9pfnn-win10 has been cloned to a new agent called 9pfnn-win10-clone. It's connected to the OpenPASS Jenkins instance.

Please confirm that it works as expected. Once it's confirmed, we will decommission the old agent b9qls-windows-10.

added Awaiting Feedback label

Thank you for the help. We are currently testing the cloned agent. We will let you know soon.

Hi @fgurr . The cloned windows build agent works as expected. Thank you for your help. However, we noticed "Could not find a suitable ssh-agent provider" error when running a deployment stage on Windows. The screenshot below is the error and the complete log can be found here: Below is the Windows deployment stage in Jenkinsfile

Could you please help us with the necessary changes on both 9pfnn-win10 and 9pfnn-win10-clone if needed

I'm on it, so far no luck.

Side note: AFAICT, this has never worked for 9pfnn-win10 or 9pfnn-win10-clone. This build ran only successfully with build agent b9qls-windows-10.

This has been fixed on 9pfnn-win10 or 9pfnn-win10-clone by uninstalling OpenSSH for Windows and adding C:\op\msys64\usr\bin to PATH.

The non-standard installation directory for msys64 made debugging this issue harder.

Side note: I noticed several directories in the root dir of the c:\ drive on all Windows10 machines.

E.g.:

s1l4.6
s53c.6
s65o.6
s68s.6
s6e8.6
s6sc.6
s734.6
s7qk.6
s80c.6
s81g.6
s8ig.6
s8ko.6
s8sc.6
sadg.6
sb58.6
svs.6

These directories seem to be created during builds. Please clean them up after builds, or even better, only create them in the build workspace directory to avoid accumulating build debris.

Nice, thanks for your support. I started a build on opSimulation to verify.

These directories seem to be created during builds. Please clean them up after builds, or even better, only create them in the build workspace directory to avoid accumulating build debris.

That's a known bug that should be fixed soon. We'll cleanup afterwards.

AFAICT, the build ran successfully. Therefore, I'm closing this issue. Please re-open it if something is still missing.

closed

removed Awaiting Feedback label

removed statewip label

mentioned in issue #5147 (closed)

added wg:OpenPASS label

mentioned in issue #5183 (closed)

mentioned in issue eclipse/openpass/opSimulation#276 (closed)