CMCDragonkai
commented
6 years ago Example of passing addresses:
// A
const http = require('http');
// this is not the way we should be doing this
// const matrix = require('matrix');
const server = http.createServer((req, res) => {
if (req.... === 'blah') {
// this is ok if it can be done as easily as as effiicnetly
const result = http.get('dogs.com');
// as this
const result = http.get(env.BADDRESS);
const result2 = ftp.get(env.CADDRESS);
const result3 = unixdomain(env.DADDRESS);
console.log(env.BADDRESS);
res.write(result);
}
res.end();
});
server.on('clientError', (err, socket) => {
socket.end('HTTP/1.1 400 Bad Request\r\n\r\n');
});
server.listen(env.APP_PORT);This is the architect expression that somebody might write.
AutomatonA:
... ASD*(@#RJ#EOI$R)
... I expect BADDRESS that speaks RAML(HTTP): E*FDS(&(#*$U*$))
... I expect CADDRESS that speaks FTP
... I expect dogs.com to resolve tCAE(*UF(*SF&(S*DF)))
... I expose my service on port APP_PORT
AutomatonB:
... E*FDS(&(#*$U*$))
httpCombinator(
AutomatonA,
AutomatonB
)
// 'BADDRESS' = 'https://dsfosdifj9832134454-43'
// 'CADDRESS' = 'ftp://ofdgud98g9847edftgdg'
// DNS 8.8.8.8So we have enumerated 3 ways of passing "content addresses" into the automaton. Using a custom matrix library is not a good way. Environment variables is possible is a good way IMO.
The content address is the address of the interface.
The best way to think about this is like OOP.
ghost
ramwan
The key concerns of Relay and Orchestrator are in providing a network and deployment service at the level of automatons (where an automaton can be thought of as a container + associated container environment if any).
This involves implementing some of the mechanisms in the literature on P2P Networks and service based networks, such as service and peer discovery, establishing seperate control and data planes between nodes in the network, and ensuring that network communication between two automatons is transparent to each service running inside the automatons.
We also introduce a content addressing system for containers and container environments, processes, network environments, and hardware that our automatons may run on. The idea here is that we can use content-based addresses to precisely indicate to the orchestrator what container should be deployed on what machine, as well as also the required environment for the container to run.
Optimistically, already existing p2p frameworks such as LibP2P will allow us to avoid reimplementing the necessary discovery mechanisms and transports for our automaton network.
So the (draft) roadmap looks like this:
Define a minimal API that Relay exposes to the other Matrix subsystems. It should allow us to query for nodes and their associated content addresses, and containers that are running on the nodes, as well as associated network configuration. Perhaps relay will also expose a control surface that allows us to manipulate the configuration of each node. Furthermore, we should have some notion of installing a container on a node, or a network that allows us to deploy specific configurations (assuming that NixOS is the target OS). 1.1 Start off with integrating with either LibP2P or doing a small peer discovery module over the regular transport.
Investigate the need for a service abstraction layer to facilitate migration of flows between front facing automatons as well as automatons that are internal to the network.
Write a mini orchestrator that either is part of Relay, or interfaces with relay to deploy a small container application to multiple node based on the content address of the node; if necessary, it may spin up a NixOS image and bring it to the necessary environmental configuration to install the container.
Determine how network communication inside the Matrix network occurs. When we want to implement automaton dependencies, we may want to specify exactly how two automatons communicate (this is selection of transport between two automatons).
Produce a small example of all the main features we want to support:
Integration with other subsystems so that we can automatically deploy a container and environment configuration through the API (so that the Architect interpreter can determine where to deploy such container based on the QOS constraints).
Most of the work here seems to be in implementing the discovery module, and ensuring that we have a way to bring up the necessary environmental configuration for the container automatically using NixOS. Most of what features we'll need will probably come out of how this interacts with the other subsystems. I'll probably flesh out this roadmap a bit more as I work on these areas.