comparison gcp_batch_netcat.xml @ 7:fcfb703748b1 draft

planemo upload for repository https://github.com/afgane/gcp_batch_netcat commit ece227052d14d755b0d0b07a827152b2e98fb94b-dirty

6:d25792770df8

--project '$project'
--region '$region'
--service_account_key '$service_account_key'
--network '$network'
--subnet '$subnet'
#if $nfs_address
    --nfs_address '$nfs_address'
#end if
    ]]></command>
    <inputs>
        <param name="region" type="text" label="GCP Batch Region" optional="false" help="Region where the Batch job will run (e.g., us-central1)"/>
        <param name="network" type="text" label="GCP Network name" optional="false" help="VPC network name where Galaxy is deployed"/>
        <param name="subnet" type="text" label="GCP Subnet name" optional="false" help="Subnet name where Galaxy is deployed"/>
        <param name="service_account_key" type="data" format="json" label="GCP Service Account Key File" help="JSON key file for GCP service account with Batch API permissions"/>
        <param name="project" type="text" label="GCP Project ID" help="The ID of the GCP project to use. If not provided, will be extracted from the service account key." optional="true"/>
        <param name="nfs_address" type="text" label="NFS Server Address" help="The LoadBalancer external IP address of the NFS server (e.g., 10.150.0.17). If not provided, the tool will attempt to auto-discover it via Kubernetes API." optional="true"/>
    </inputs>
    <outputs>
        <data name="output" format="txt"/>
    </outputs>
    <help><![CDATA[
**What it does**

This tool submits a job to GCP Batch to test network connectivity between Batch workers and your NFS server. It provides network debugging to help identify connectivity issues in Galaxy deployments on Google Kubernetes Engine (GKE).

**NFS Address Auto-Discovery**

If you don't provide an NFS server address, the tool will attempt to auto-discover it by:
- Using Kubernetes API to find NFS LoadBalancer services and their external IPs
- Looking for services with names containing 'nfs', 'nfs-server', 'nfs-provisioner', or 'nfs-ganesha'

**Important: LoadBalancer Configuration**

For NFS connectivity from GCP Batch jobs, your NFS server must be exposed via a LoadBalancer service with an external IP. Internal ClusterIP services are not accessible from external Batch workers.

**Troubleshooting Network Issues**

The tool helps identify the root cause of connectivity issues:
- **Connection timeouts**: Usually indicates firewall rules blocking traffic or NFS service not accessible externally
- **DNS resolution failures**: May indicate DNS configuration issues
- **Auto-discovery fails**: NFS service may only be exposed as ClusterIP (internal only)

**Best Practices**

1. For most reliable results, provide the LoadBalancer external IP explicitly in the "NFS Server Address" field
2. If auto-discovery fails, check that your NFS service is properly exposed with a LoadBalancer type
3. Ensure GCP firewall rules allow traffic from Batch subnet to NFS LoadBalancer IP on port 2049
    ]]></help>
</tool>

7:fcfb703748b1

--project '$project'
--region '$region'
--service_account_key '$service_account_key'
--network '$network'
--subnet '$subnet'
--nfs_address '$nfs_address'
    ]]></command>
    <inputs>
        <param name="region" type="text" label="GCP Batch Region" optional="false" help="Region where the Batch job will run (e.g., us-central1)"/>
        <param name="network" type="text" label="GCP Network name" optional="false" help="VPC network name where Galaxy is deployed"/>
        <param name="subnet" type="text" label="GCP Subnet name" optional="false" help="Subnet name where Galaxy is deployed"/>
        <param name="service_account_key" type="data" format="json" label="GCP Service Account Key File" help="JSON key file for GCP service account with Batch API permissions"/>
        <param name="project" type="text" label="GCP Project ID" help="The ID of the GCP project to use. If not provided, will be extracted from the service account key." optional="true"/>
        <param name="nfs_address" type="text" label="NFS Server Address" help="The LoadBalancer external IP address of the NFS server (e.g., 10.150.0.17). This must be the external IP, not the internal ClusterIP." optional="false"/>
    </inputs>
    <outputs>
        <data name="output" format="txt"/>
    </outputs>
    <help><![CDATA[
**What it does**

This tool submits a job to GCP Batch to test network connectivity between Batch workers and your NFS server. It provides network debugging to help identify connectivity issues in Galaxy deployments on Google Kubernetes Engine (GKE).

**Required: NFS LoadBalancer External IP**

You must provide the external IP address of your NFS server's LoadBalancer service. This is crucial because:
- Galaxy sees the NFS server via its internal ClusterIP (e.g., 10.96.0.1)
- GCP Batch jobs run outside the cluster and need the LoadBalancer external IP (e.g., 10.150.0.17)

**Finding Your NFS LoadBalancer IP**

To find the correct IP address, run:
```
kubectl get svc | grep nfs
kubectl get svc <nfs-service-name> -o wide
```

Look for the "EXTERNAL-IP" column for LoadBalancer type services.

**Important: LoadBalancer Configuration**

For NFS connectivity from GCP Batch jobs, your NFS server must be exposed via a LoadBalancer service with an external IP. Internal ClusterIP services are not accessible from external Batch workers.

**Troubleshooting Network Issues**

The tool helps identify the root cause of connectivity issues:
- **Connection timeouts**: Usually indicates firewall rules blocking traffic or NFS service not accessible externally
- **DNS resolution failures**: May indicate DNS configuration issues
- **Wrong IP address**: Ensure you're using the LoadBalancer external IP, not the ClusterIP

**Best Practices**

1. Ensure your NFS service is exposed as type LoadBalancer with an external IP
2. Verify GCP firewall rules allow traffic from Batch subnet to NFS LoadBalancer IP on port 2049
3. Test the connection manually: `telnet <EXTERNAL-IP> 2049`
    ]]></help>
</tool>