Crates.io | tosca-solver |
lib.rs | tosca-solver |
version | 0.1.1 |
source | src |
created_at | 2024-11-22 22:52:25.355776 |
updated_at | 2024-11-23 10:38:05.388476 |
description | Build a TOSCA topology from a set of TOSCA types and requirements. |
homepage | https://github.com/onecommons/unfurl/tree/main/rust |
repository | https://github.com/onecommons/unfurl |
max_upload_size | |
id | 1457910 |
size | 49,743 |
This crate infers the relationships between TOSCA node templates when given a set of node templates and their requirements.
Each TOSCA requirement is encoded as a set of constraints including:
solve()
will return the nodes that match the requirements associated with a given set of nodes.
By default this crate is exposed as a Python extension module and is used by Unfurl, but it could be used by any TOSCA 1.3 processor.
By default, this crate is built as a Python extension, to disable this feature, set default-features = false
. The solve
function is its main entry point and can invoked from the Rust or Python. Your TOSCA topology will have to be encoded as a HashMap of Nodes -- see https://github.com/onecommons/unfurl/blob/main/unfurl/solver.py for an example.
Finding the match for a TOSCA requirement with a node_filter can't be determined with a simple algorithm. For example, a requirement node_filter's match can depend on a property value that is itself computed from a requirement (e.g. via TOSCA's get_property
function). So finding a node filter match might change a property's value, which in turn could affect the node_filter match.
In addition to this basic functionality, this solver will use type inference to resolve requirements that haven't defined explicit node targets and supports Unfurl's node_filter extensions for applying constraints and graph querying.
Luckily, by eschewing negation and quantification we can avoid the need for a full SAT solver and instead encode the inference rules as Datalog-like query rules using Ascent -- a simpler and more scalable approach.
One of Unfurl's goal is to enable adaptable blueprints that can easily compose independent, open-source components -- imagine something like a package manager for the cloud. This crate allows blueprints to express their requirements in a loosely-coupled, generic manner.
You can use the standard cargo commands for development if you use its --no-default-features
flag to skip compiling with the "pyo3/extension-module" feature.
To compile the Python extension, in the parent of this directory, run:
python setup.py build_rust --debug --inplace
Run pip install setuptools-rust>=1.7.0 pbr
to install setup.py
's requirements.
Cargo tests should be invoked with cargo test --no-default-features
because the "pyo3/extension-module" feature doesn't work with cargo test.
Unfurl's Python unit tests have more extensive tests in https://github.com/onecommons/unfurl/blob/main/tests/test_solver.py. See Unfurl's main README for instructions on running its unit tests.