3 ms·
The biggest differences that I can think of right now are - Its not using the whole orchestrator...thing. That was some complex code and we made a Practical Ch
by emccue 3y ago
The biggest differences that I can think of right now are
- Its not using the whole orchestrator...thing. That was some complex code and we made a Practical Choice.
- No equivalents for a lot of the rust tools. Choices aren't as straightforward as for the cargo/rust world. I do intend to at least add JUnit testing as an option though.
- Its not building things from source, which means I need to manually update download urls every now and then.
- Might not be running on a big enough machine. Lets see if HN hugs it to death.
- shepmaster 3y ago> Its not using the whole orchestrator...thing For further context, the "orchestrator" is a reimplementation of some of the backend. The original version of the playground basically took the user input, dumped it into a file, then mounted that file into a Docker container and waited for it to be complete — a traditional batch process. This works great, but doesn't allow fun things like streaming input / output from the process, or having temporary files that persist over a short time period. The new code has a shim program that lives inside the container and we can communicate with it via messages passed on stdin/stdout. Things are a lot more asynchronous and a bit more complicated. I think it's a reasonable thing to avoid for now, but note that my plan is to eventually remove the current synchronous code eventually. > I need to manually update download urls every now and then I do much the same, roughly every 6 weeks or so. > a big enough machine The primary instance is a single c5a.large in EC2. I also run my own instance on a single t2.micro.