No – I mean how do you get AWS to start rendering? I am assuming AWS runs a script file (the work file) which gives the commands to render each frame of the blendfile in the tarball
No, it works this way:
- Modify ~/.brenda.conf (on your computer) to point to the correct buckets and archive tarball.
- write a frame-template with the correct name of the blend file to render from inside the tarball (this is where the render command will be generated from)
- push the frame template to the queue with brenda-work
- brenda-run a couple of instances
awesome. Thanks for the explanation.
So another general question – AWS has blender installed apparently? Or was I supposed to include a blender executable in the tarball?
Hovercraft: You mentioned in a previous post about using Bittorrent sync which would require you to use a micro instance to run it. They’re only free for the first year though. I Just had a play with the trial of Cloudberry Desktop backup for S3($29.99) which can automatically check your S3 frame bucket every minute and download new frames to your computer. It’s working so far.
Thans for the info, rider_rebooted. That looks usefull. As I said, I have to get the frames ASAP, Full HD multilayer exrs can get quite big and if I only start downloading them after the queue is finished I’ll spend longer waiting for the DL than for the render 
Regarding my previous comments I realized maybe I am expecting a bit too much of brenda. It’s not a complete farm management system but just a part of it. It would need another component on top to manage multiple queues and allocating instances to them. It would have to watch the different jobs in queues and tear down and start instances accordingly.
Say you run 100 instances on job A, then you would like to start a second job, taking 75 instances from job A and returning them when done.
Does anybody know how billing works exactly? If I start 25 instances I have to pay an hour minimum, correct? If I stop and restart them, how does that work?
As far as I know (and others here know far more) you will be charged an hour minimum for each instance. If you terminate an instance and start another within the hour you will be charged for both hours as they are two separate instances.
Naive rant…
To me Brenda seems like the working foundation of something with a huge amount of potential. Think about this - Once Cycles is mature (feature complete, more efficient) and if it becomes a standalone piece of software (I remember hearing this on the Blender podcast). Then a “Brenda plug-in” would put it in quite a unique position. It’s a well maintained unbiased ray-tracer with unlimited render node licenses able to render on EC2 spot instances at a fraction of the price of regular render farms. Surely that would get the attention of freelancers and small studios everywhere!?
Looking very far into the future I know…
Hmm that’s a bummer about the pricing. So if I have a couple of idle instanced finished with their queue, is there a way to assign them new jobs without tearing them down and bringing up new ones?
And you are right, in the case of massively parallelized rendering Blenders/Cycles OSS nature are a real boon to be leveraged. The costs savings for a render farm are gigantic.
Hey I made some progress (by reading AND thinking about the --help output):
put DONE=poll in the conf and the instances keep polling
rendering to subfolders kinda works, but you have to create them yourself because they are not really subfolders but prefixes in S3, it’s not a real directory structure, so create that prefix and then put e.g. S3://bucket/prefix in the conf
when using “poll” the old conf file is always used, but there seems to be options in brenda-node and brenda-tool that it might be possible to upload a new conf and restart the node. That would be everything needed to completely steer queue management. Wrap it in a nice GUI if you like.
Edit: Ok, I got brenda-node to read a new conf instance side but you have to upload you AWS credentials inside the conf. brenda-node usually gets this from stdin which might also be doable. Still, this way you can completely reconfigure your instances.
“brenda-run” script generates the script for brenda-node to stdout, maybe this can be piped to brenda-tool ssh 'brenda-node < or something to restart the instance but my shell-fu is failing me. I hope somebody else might provide some insight.
This is how far I’ve got:
Kill idle brenda-node with DONE=exit or:
brenda-tool ssh ‘kill $(cat /root/brenda.pid)’
upload new conf with:
brenda-tool rsync new.conf HOST:
start new brende-node with new conf with:
brenda-tool ssh ‘brenda-node -D -c new.conf’
which throws an error:
IOError: [Errno 2] No such file or directory: ‘/root/.s3cfg’
on the supplied AMI, I’ve set up my own AMI with s3 credentials but this isn’t seen by brenda, probably because I didn’t start from scratch creating it, which I will try later.
@hoverkraft - re:multiple jobs: instances are launched with the specific queue to watch. I think if you fill up the queue with new frame tasks, they should keep working on the new frames. If you’ve updated the conf settings with a new bucket, you should be able to keep your instances working I believe.
I wouldn’t get to hung up about subfolders, it’s not really working very well. I think for my gui app, it’s going to create a new bucket for each new output job to keep the jobs separate. File types from the same job would just have to be separated by filename but all in same bucket for now.
Todd, that’s how I do it now, dump everything in one bucket and watch for filename collisions. I run a script that makes sure every file out node has a unique name and no subfolders (that’s why I asked about the $OUTPUT earlier).
Regarding parallel queues, I know that this works, what I would like to do is transfer instances to other queues, which I think should be possible by restarting their brenda-node deamon with a new conf.
This is what I tried but it didn’t work, I believe because the output bucket is read and supplied to brenda-node by brenda-run. Afterward you supply jobs to the queue with brena-work but this neither updates the output bucket nor the project file. Though you can have multiple blends in an project tarball and access those.
Also, thanks for replying, I felt like a crazy person rambling 
If anyone has time and the inclination, it would be helpful to duplicate James’ AMI with a newer version of Blender (2.7+). That way people could choose that AMI if their project is in 2.7. I haven’t had time to figure it out yet.
How does Amazon render the file? Do we have to include the blender executable in the tarball?
@daren No, the Blender is already installed on the Virtual Machine that is started by brenda. Just follow the tutorial on brendas github page, it’s pretty straightforward.
@Todd I’ll take a look at it, I’ve created two 2.70 AMIs which work but somehow brenda can initialize them and the rendering works but I can’t control them anymore afterwards, they dont show up in brenda-tool instances for example. Maybe a permissions problem.
So I have tried this about 6 times now and I always get to the same spot. I start a work project, and its like my instances hang:
brenda-tool ssh uptime
------- ec2-54-85-7-30.compute-1.amazonaws.com
------- ec2-54-86-146-240.compute-1.amazonaws.com
------- ec2-54-85-190-12.compute-1.amazonaws.com
------- ec2-54-86-156-64.compute-1.amazonaws.com
I have 4 active instances, but none of them appear to be doing anything. Any ideas?
@deron What does tail log say?
pretty much the same:
brenda-tool ssh tail log
------- ec2-54-86-81-151.compute-1.amazonaws.com
------- ec2-54-86-64-44.compute-1.amazonaws.com
------- ec2-54-86-55-96.compute-1.amazonaws.com
------- ec2-54-86-73-78.compute-1.amazonaws.com
Yep – 491 .
I’ll just need to start from the beginning once more later
If you’re using James’s original AMI make sure your file is 2.6x, don’t think it works with 2.7 files.