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 <chetan.mehro...@gmail.com> > 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 > <markus.thoem...@de.ibm.com> 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 >> >>
