search

enarx-archive / rfcs

Holds RFCS (“Request for Comments”), proposals to improve Enarx
Apache License 2.0
2 stars 9 forks source link

Wasm rfc 0001 #2

Open MikeCamel opened 4 years ago

MikeCamel commented 4 years ago

Initial draft of workload loading RFC. Created two new issues based on the work: #227, #228.

Added line breaks: what are the kids using as default line length these days?

Addresses issue #140.

axelsimon commented 4 years ago

Quick note, as per the RFC process (which is now live), this RFC should use the number of its PR, so it should be RFC 00002 :)

MikeCamel commented 4 years ago

I wonder if the Enarx Client Agent needs to be broken up into separate entities. In my mind, the ECA is fulfilling a number of functions and it is hard to keep track of how it is accomplishing all of this. It seems to be the frontend utility for an end-user looking to deploy a workload but it also seems to forward itself to the host machine to negotiate the construction of a Keep (or many keeps). However, the way it is written now implies that the Keeps are already present on the target machine and therefore are waiting on a socket for the client to tell it what to do. It is not clear what the workflow is if there is a new user with a new target machine to deploy on that has no keeps at all.

I'm wondering if we should decompose it into:

The client: a tool that someone can use on their local machine to manage their Enarx keeps + workloads.

The daemon/agent (daemon sounds cooler): a long-running process on a target machine that will host Enarx keeps.

The user can use the client to dispatch commands to well-known hosts that are running the Enarx daemon. The Enarx daemon carries out the commands received from the client. This includes the construction and teardown of Enarx keeps.

With a separation of roles like this it is more clear how a binary makes its way into an Enarx keep regardless of where the Keep is in its life cycle and we can do away with the chicken-egg issue of assuming a Keep is already present and waiting on a socket on a target host.

@connorkuehl - what you describe is the Enarx Host Agent.

connorkuehl commented 4 years ago

what you describe is the Enarx Host Agent.

@MikeCamel Indeed! That entity only appears under the rejected alternatives section and its function doesn't appear to have an explicit appearance in the proposed RFC :-)

MikeCamel commented 4 years ago

I'll have a look. I think you may be conflating some very different steps - which are described in detail in the latest pull request - but if it's not clear, then I need to elucidate.

npmccallum commented 4 years ago

@MikeCamel Although there have been numerous comments since, I haven't seen any updates to this RFC since Mar 16. Could you please update this RFC to address the comments so that we can do another round of review?

MikeCamel commented 4 years ago

Could you please update this RFC to address the comments so that we can do another round of review?

Done.