fix: add network interface to htcondor execute point module + update … - #5225

Summary of Changes

Hello @Thibaut-Nurit, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the HTCondor execute point module by introducing the capability to configure multiple network interfaces for instances, providing greater flexibility in network setup and integration. Concurrently, it updates the version constraints for several core Terraform modules used across the HTCondor components (execute point, access point, and central manager) to allow for more recent module versions, improving maintainability and enabling access to new features or bug fixes from the underlying modules.

Highlights

• Multiple Network Interfaces: Added support for configuring multiple network interfaces for HTCondor execute point instances, enhancing network flexibility.
• Terraform Module Version Updates: Updated version constraints for several Terraform modules across HTCondor components (execute point, access point, central manager) from optimistic (~>) to minimum (>=), allowing for broader compatibility with newer module versions.
• Backward Compatibility: Ensured backward compatibility for existing network configurations within the HTCondor execute point module, allowing seamless transition to the new network interface configuration.

The purpose of this MR is to update the execute point module so it can have multiple network interfaces.
It's backwards compatible.

Also as the version needed for some cluster toolkit modules is hashicorp/google >= 7, I updated terraform-google-modules/vm/google//modules/mig version

The venv_python_path in install_ansible.sh was also changed so it would take the python exe that was installed.
The observed behavior was that a rocky linux 8 VM with python 3.6 was installing python3.12 but the command executed was python3 = python3.6, making the script fail.

/gcbrun

/gcbrun

Hello @arpit974
Would it be possible for you to review this PR, please?
We’d like to use this feature with our client.

/gcbrun

/gcbrun(d589eba)

/gcbrun

Could you run the pre commits again please with the latest version? There are some failures caused due to readme formatting.

Could you run the pre commits again please with the latest version? There are some failures caused due to readme formatting.

Hello, it should be good now

/gcbrun

Thank you for this contribution! I just have one suggestion:

In community/modules/compute/htcondor-execute-point/main.tf, inside the additional_networks block, the project for the subnetwork is hardcoded to the current project ID.

Setting subnetwork_project explicitly to var.project_id could break deployments using Shared VPCs, where the additional subnetwork actually resides in a separate host project.

To support Shared VPCs seamlessly, we can add subnetwork_project = optional(string) to the network_interfaces variable definition in variables.tf. Then, in main.tf, you can update the assignment to use the provided project or fall back to var.project_id:

In variables.tf:

type = list(object({
  network            = string
  subnetwork         = optional(string)
  subnetwork_project = optional(string) # <-- Add this field

In main.tf (lines ~195):

subnetwork_project = network_interface.subnetwork != null ? coalesce(network_interface.subnetwork_project, var.project_id) : null

This ensures that users can specify a host project if they are attaching an interface from a Shared VPC.

Everything else looks good to me! Will approve once the tests pass with the new commit.

Hello,
The variable is added

/gcbrun

Hello, The variable is added

Thanks! Approved.