@James Crowther @zocker1600
I'll get my helm charts cleaned up and posted! I did a lot of modifications within my Rancher web interface, so the yaml files I started with aren't up-to-date! They should be ready in at most a week or so! :)
The update to the docker repo no longer allows me to directly connect to my nodes by adding them manually and entering their IP addresses, but when I log in to Crowdrender it populates the list properly and shows them connected but displays my public IP, which does not have ports forwarded to the nodes.
I entered in the right IP addresses and told it to connect. It attempted to repopulate with my public IP, but they did connect and all three are showing sync'd and do participate in the render, now.
I did notice a lot of interface delay. I'm not certain of if it's a problem on my end or with the software, but hitting 'connect' has a long pause before it pops open its box to enter in values.
I have a few thoughts that you are absolutely free to cherry-pick from.
1. Handling of private and public IP addresses. Tracking them both via the cloud and allow users to click a "use LAN IP" or "Use custom IP" box in Blender.
2. Allow manual entry of port ranges per-node in Blender to allow for NAT. I.E. my network is on 192.168.1.0/24 but my render nodes are on 172.24.0.0/16 behind a router at 192.168.50.10. Being able to set "node1"@192.168.50.222:9000-9025 "node2"@192.168.50.222:9026-9050 within the interface would be greatly beneficial.
3. Host name resolution could help with suggestion 1, since, say, my node mirth(dot)wolvenmoon(dot)net resolves to 172.24.15.3 on the 172.24.0.0/16, but it resolves to 192.168.50.222 on the 192.168.1.0/24 network and, if I ever were to open it up to the Internet, would resolve to my public IP, there.