Work in progress, not ready for general use
Floria
A dual-paradigm data system for cloud orchestration.
It consists of a data model (the declarative paradigm) integrated with an event-driven plugin execution mechanism (the imperative paradigm), with first-class support for Wasm plugins.
This project comprises:
- Storage backends for graph, relational, and “no-SQL” databases
- CLI tools
- A rich terminal UI
- A rich web UI with graphical visualization of topologies
- A library for working with Floria data and plugins
- An SDK for building Wasm plugins for Floria
For a Floria-based orchestrator, see Khutulun.
For a TOSCA frontend for Floria, see Puccini.
Data
Floria is a graph database. We start with the assumption that clouds are quintessentially about relationships between entities, from dependencies between infrastructure components, through network connections and secure routes, to the composition of complex multi-sited workloads.
In Floria, graph vertexes and edges are both first-class citizens with custom data and metadata. If vertexes are the bones and muscles, then edges are the connective tissue.
Vertexes can represent software or hardware components at any level from infrastructure to application, as well as logical configurations that exist purely as data (and metadata). Vertexes can be nested within other vertexes recursively.
Edges can represent actual connections, such as network routes, ports, and secure channels, as well as logical dependencies.
Both vertexes and edges can be assigned to any number of “classes”, which can be organized hierarchically. Classes can be used to associate metadata, run operations, and apply policies to any number of entities at once.
Additionally, Floria can represent templates for these topologies. Though you can design templates directly in Floria, higher levels of abstraction are possible and useful. For example, you can compile TOSCA to Floria with Puccini.
All the above entities live in nested directories that can be used to organize them hierarchically. Directories function as namespaces and are gated with role-based permissions, which allows a single Floria service to support multiple tenants. Note that edges can connect vertexes between different directories should the permissions allow it.
Floria data is designed to be portable and communicable. Entities can be dumped into and imported from CBOR, MessagePack, JSON, and YAML formats.
Code
Floria is not just a data model. It also defines interfaces for interaction with plugins. Plugins are used for event handling, data retrieval and validation, and for template instantiation.
That last feature allows templates to be “self-adaptive” to their target clouds, e.g. you can create an optimized instance for constrained edge sites, choose components per licensed hardware vendor, inject different credentials for staging vs. production environments, etc. The feature is inspired by the Nephio project.
Though Wasm Component Model plugins get preferential support in Floria, Wasm is not a requirement. Plugins can be implemented in anything that can be executed on your cloud computers.
Both!
Floria property values use an expression language that allows you to embed function calls. Thus, every time you access a property you could be running custom code. This powerful feature elegantly epitomizes Floria’s dual-paradigm design.
The expression language is stored in an efficient binary format. Furthermore, it is extensible using custom types to allow special handling in code without resorting to cumbersome pre-processing.
FAQ
Why is it called “Floria”?
Named after Floria Tosca, the protagonist of Victorien Sardou’s play, La Tosca. She was written for and first portrayed by actor Sarah Bernhardt.
License
Like much of the Rust ecosystem, licensed under your choice of either of
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.