[riot-devel] Mailserver issues
michael at steelcode.com
Mon Aug 14 18:36:40 CEST 2017
Lambda is actually pretty flexible.
You can do anything that takes less that 300 seconds, so that is ok. The
biggest thing that I like is that you pay only for the time spent servicing
requests, but the lambda actually persists between requests (for free) so
you can store data on the hard drive (up to 500MB) and you can keep data in
memory. The only caveat is that AWS can remove that whenever they want, but
in my experiments it lasts several hours. So for the CI use case I would
basically configure the lambda image to contain a recent-ish workdir, then
update it in the invocation (so if it being reused the update will be a
So yeah, totally agree that you need caching, but actually it does that,
they just don't advertise it much.
On Mon, Aug 14, 2017 at 5:26 AM, Kaspar Schleiser <kaspar at schleiser.de>
> Hi Michael,
> On 08/11/2017 08:26 PM, Michael Andersen wrote:
> > Having just done something similar for something else, you should really
> > look at doing CI in AWS lambda. It is remarkably cheap and (more
> > importantly for my case) requires nearly zero devops once set up. If you
> > suddenly have 10x the CI runs, they can all run in parallel for the same
> > cost. No queues.
> I'm not sure the current RIOT build system requirements match AWS lambda
> in order to properly make use of it.
> For every build, the current CI sends "build application X for board Y"
> as job to a CI queue. With git workdir caching and most of the build
> already in ccache, such a job takes between .5 and 2 seconds. Without
> those caches, more like 10 to 20 seconds, depending on the time needed
> to check out RIOT and to a cold-ccache build. If I understand AWS lambda
> correctly, it is not really suitable if that much context information is
> I was looking into using AWS and the google container engine, but
> without the caches (e.g., on freshly booted containers/VMs/instances),
> they're not very attractive performance wise. Long-running (keeping the
> caches in memory, or even using the persistent storage options), they're
> not attractive price-wise.
> I'd love to be proven wrong! ;)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel