Remove mentions of TCP-based protocol communication about deploykit HOT 5 CLOSED

This is interesting because as I have started conceptualizing what infrakit is, I started to think that it is essentially a daemon / service to communicate with other daemons / services, so why not have infrakit be able to reach out to services over network instead of just via domain sockets. I thought this to be an even more powerful paradigm then just domain socket communication, but maybe I am missing what the architecture of infrakit is desired to be.

I get what you are saying about ACLs and such, but I would suggest not to throw out TCP communication just because there is more complexity with regard to ACLs. I wonder if docker engine's authz plugin mechanism could be used in infrakit as well?

from deploykit.

@hekaldama thanks for chiming in! I'm just realizing this issue should be closed (as the relevant PR was already merged). I'm closing it, but please don't assume that to mean i'm closed to discussion :-)

Right now, we're thinking about plugins as language-agnostic DLLs rather than possibly-remote services.
As you point out, TCP-based plugin communication enables another way of thinking about plugins. However, my concern was that we didn't have any real use cases for it, and it introduced a dubious security story. I'd like for us to build good plugin discovery and inter-plugin communication abstractions, though, so that we can quickly add good support for things like remote plugins when use cases arise.

I'm intrigued - are there any use cases you had in mind that would be shut out with the removal of TCP support?

from deploykit.

This may reveal some of the lack of understanding around infrakit's use case(s), but I was imagining if I wanted to hook this up to my proprietary VM manager as an instance plugin, I would have to write a daemon on the infrakit "manager" to interact with this said VM manager.

I thought, "You know what, I would rather just expose a HTTP API in VM manager that conforms to the instance plugin spec and point infrakit at that." The idea is that I centralize the interface to the system of record (VM manager), and rely on its currently redundant, OPS supported, etc. setup to allow it as an instance plugin.

I then began to imagine what if all the plugin types were able to be declared and setup on their own, would that make it so that infrakit itself could be more easily decentralized as well? What about a world where I could run infrakit -H infrakit-server-vip:8000 instance --name instance-service describe on my localhost, what would that take? It started to bleed into my thoughts around architecture for a multi-manager setup for the infrakit servers.

So mostly just thoughts and questions as I am conceptualizing what infrakit can do for me. Thanks for your time.

from deploykit.

Thanks again for the useful feedback, @hekaldama! I've filed #248 to explore that use case specifically.

from deploykit.

Thanks for collaborating :).

from deploykit.