> So for #C is there a way to proxy the stream without changing the runtime > http api where binary is passed embedded in the json object on /init?
They would need to be modified. A less intrusive approach would have been to pass signed url and use client like wget to fetch the binary. But as David mentioned some setups may lock down access to external services. For such cases we would need to implement the support in client runtimes as part of init protocol Chetan Mehrotra On Wed, Mar 28, 2018 at 11:57 PM, Tyson Norris <[email protected]> wrote: > So for #C is there a way to proxy the stream without changing the runtime > http api where binary is passed embedded in the json object on /init? > It’s not obvious to me how this can be done without changing the runtimes > (and the invoker), since currently the whole entity is loaded to memory to > get the JSON sent to /init? > > >> On Mar 26, 2018, at 11:50 PM, Chetan Mehrotra <[email protected]> >> wrote: >> >>> That'd put the "burden" of downloading the action code into each and every >>> runtime, right? Do you think that is necessary? >> >> #C would need few prototypes to figure out the right approach. My >> current thinking was that each runtime can have at minimum wget like >> app embedded and then Invoker would just pass in the signed url which >> is then passed to wget to do actual streaming >> >> If each runtime webserver can efficiently stream the pushed stream >> without in memory buffering then that would indeed be much better >> approach to take. >> >> Chetan Mehrotra >> >> >> On Mon, Mar 26, 2018 at 4:42 PM, Markus Thoemmes >> <[email protected]> wrote: >>> Hi Chetan, >>> >>> thanks a lot for capturing this. It's about time we get streaming for the >>> action code! >>> >>> One comment to C: That'd put the "burden" of downloading the action code >>> into each and every runtime, right? Do you think that is necessary? We >>> could keep the notion of the ArtifactStore as of today and just proxy the >>> TCP stream through the invoker (which has credentials and everything) into >>> the runtime itself. >>> >>> Benefits from my PoV: >>> - No needed change to the runtimes at all. >>> - Credential handling doesn't need to rely on the ObjectStore provider's >>> featureset (as in: signed URLs) >>> - The invoker can potentially "deduplicate"/cache multiple calls. Under a >>> burst for example it'd be neat if we only needed to download the code once >>> per invoker >>> >>> What do you think? >>> >>> Other than that: Go for it! >>> >>> Cheers, >>> Markus >>> >>> >
