A fast, easy-to-use, production-ready inference server for computer vision supporting deployment of many popular model architectures and fine-tuned models.
Each block now may optionally define compatibility with Execution Engine (if not defined - step will attempt to run with any without guarantees)
Workflow definition specifies version of EE to run with
This is recognised by EE, proper variant of engine is loaded (from registered, if definition specifies version 1.3.5, we find compliant EE in version >=1.3.5,<2.0.0 - such that we only need to maintain single major version for EE)
Blocks may now be organised in families (by name metadata property) and we will keep appending versions for the same families to ensure stability of already created workflows over time. This is totally optional - but we will do it for core blocks - @hansent this must be reflected on UI side (as now all blocks are gray, due to changes in type aliases)
reflected changes in semantics into packages structures - please review carefully to avoid breaking changes in the future
got rid of asyncio in workflows 😄 - still needs to be tested, but looks good
fixed background tasks in active learning for inference pipeline - after getting rid of asyncio we can normally use threading inside steps - I used background thread pool to run AL data collection
updated docs generation (example steps with 2 versions):
Type of change
Please delete options that are not relevant.
[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] This change requires a documentation update
How has this change been tested, please provide a testcase or example of how you tested the change?
Description
Changes:
version
of EE to run with1.3.5
, we find compliant EE in version>=1.3.5,<2.0.0
- such that we only need to maintain single major version for EE)name
metadata property) and we will keep appending versions for the same families to ensure stability of already created workflows over time. This is totally optional - but we will do it for core blocks - @hansent this must be reflected on UI side (as now all blocks are gray, due to changes intype
aliases)Type of change
Please delete options that are not relevant.
How has this change been tested, please provide a testcase or example of how you tested the change?
YOUR_ANSWER
Any specific deployment considerations
Docs