Move node configuration to runtime

[tiziano88]

Currently, an Oak Application specifies a list of node "templates" that the application itself may use to create nodes at runtime. Some of the configuration details are embedded in such templates, e.g.:

oak/examples/chat/config/config.textproto

Lines 1 to 13 in c4865b2

	node_configs {
	name: "app"
	wasm_config {
	module_bytes: "<bytes>"
	}
	}
	node_configs {
	name: "log"
	log_config {}
	}
	grpc_port: 8080
	initial_node_config_name: "app"
	initial_entrypoint_name: "oak_main"

I think it would be simpler and more flexible to instead reduce the application configuration to just a list of wasm modules (we may use the current format for now, and later on consider a more lightweight option, if desired), and the initial entry point fully qualified name, which would cause the Oak Runtime to instantiate that entry point at application startup.

The main node can then create any subsequent node (including logging and gRPC, if necessary) by invoking the node_create ABI function, which would be changed to accept a serialized node config (in protobuf format), instead of the current configuration name. This way the caller node may configure part or all of the configuration for the newly created node (e.g. by choosing a different gRPC port, or passing dynamically generated configuration details).

This should also allow us to support per-instance application configuration files, in which the same "application" would be parametrized with additional values, similar to how non-oak applications are executed by passing flags and / or environment variables. (cc @ipetr0v who is going to create a separate issue to track that).

@daviddrysdale WDYT?

[tiziano88]

For instance, consider the following code:

oak/sdk/rust/oak/src/logger/mod.rs

Lines 99 to 110 in c4865b2

	pub fn init(level: Level, config: &str) -> Result<(), SetLoggerError> {
	// Create a channel and pass the read half to a fresh logging Node.
	let (write_handle, read_handle) = crate::channel_create().expect("could not create channel");
	crate::node_create(config, "oak_main", read_handle).expect("could not create node");
	crate::channel_close(read_handle.handle).expect("could not close channel");
	log::set_boxed_logger(Box::new(OakChannelLogger {
	channel: crate::io::Sender::new(write_handle),
	}))?;
	log::set_max_level(level.to_level_filter());
	Ok(())
	}

which would become something like:

let config = NodeConfiguration {
  config_type: ConfigType::LogConfiguration(...),
};
crate::node_create(&config, "oak_main", read_handle).expect("could not create node"); 

i.e. instead of passing a String, it would pass the actual serialized configuration.

Note that wasm modules would still be referenced by name, but at that point the application configuration becomes much more similar to a plain archive (and maybe we could even consider actually ar for that in the future, but that's another discussion).

[tiziano88]

Also vaguely related to #568, in which we are moving towards a more structured input to the logging pseudo-node, whose schema is defined via protobuf.

[daviddrysdale]

It feels a bit like this might be multiplying entities without necessity; if there's a way of passing a blob of configuration data to a new Node at startup, then there are now two different mechanisms by which information can flow (the config blob and the normal messages-on-channels).

It's also possible (although rather inconvenient) to do Node/Application configuration without any changes to the ABI, e.g. by having a convention that the Application's gRPC service definition include a Configure method that's expected to be the first method invoked after startup.

[daviddrysdale]

This is done now, yesno?

[tiziano88]

Yes, thanks