RichardScottOZ

This run it has got to building an image, taking a while to do, but that is a bit further. Don't know what was difference, possibly badly flaky vpn and...

```python 2024-11-23 12:01:09,849 [DEBUG] aws_ec2.py:696 -- VM Image is being created. Current status: pending 2024-11-23 12:01:31,280 [DEBUG] aws_ec2.py:696 -- VM Image is being created. Current status: available 2024-11-23 12:01:31,280 [DEBUG]...

but trying that ami- in target_ami, back to solving this problem: ```python 2024-11-23 12:28:29,116 [DEBUG] monitor.py:429 -- ExecutorID 017dd6-0 - Starting Storage job monitor 2024-11-23 12:28:29,116 [INFO] executors.py:494 -- ExecutorID...

I let it run for an hour then ctrl-C'ed it. ```python 2024-11-23 13:30:40,473 [DEBUG] ssh_client.py:65 -- 10.0.0.0 ssh client created 2024-11-23 13:30:40,683 [DEBUG] monitor.py:457 -- ExecutorID 017dd6-0 - Storage job...

job payload has this at the start ```json JOB PAYLOAD: {'config': {'lithops': {'backend': 'aws_ec2', 'log_level': 'DEBUG', 'mode': 'standalone', 'chunksize': 0, 'storage': 'aws_s3', 'monitoring': 'storage', 'monitoring_interval': 2, 'execution_timeout': 1800, 'backend_type': 'batch'},...

Experiments are here: https://github.com/RichardScottOZ/lithops/tree/private_ip

These exist - and are using BatchInvoker ```python FUTURES: [, , ] ```

Will simplify very slightly and just use this https://github.com/lithops-cloud/lithops/blob/master/examples/call_async.py - so one not 3 things.

The latest test of that, the worker-service-log ```bash cat /tmp/lithops-root/worker-service.log 2024-11-23 23:19:26,575 [ERROR] lithops.standalone.worker:107 -- Timeout connecting to server 2024-11-23 23:19:27,361 [DEBUG] lithops.standalone.backends.aws_ec2.aws_ec2:60 -- Creating AWS EC2 client 2024-11-23 23:19:29,680...

So does that mean that is the problem, workers can't get to master, or is that just first try and then they do? /tmp/lithops-root/jobs and /logs are empty anyway