Simulated Execution Mode For Murano Engine
User story:
As an Application Developer I'd like to execute my workflows without actual deployment and interaction with Murano Dashboard in order to verify my workflow before actual test deployment by those increasing my application development speed.
=======
Typical debugging of a complex murano scenario includes patching engine code to support loading object model from a file, automatic generation of tokens, and so on. These 'hacks' speed up debugging a lot, however you should remove them when debugging is done.
Another 'hack' useful for debugging is to comment out MuranoPL code that sends data to agent, in order to skip real deployment step(s).
It would be very helpful to have some kind of simulator integrated into murano engine, for example, a set of command-line keys that could switch engine's behavior into 'simulation mode', or a separate config file.
Blueprint information
- Status:
- Complete
- Approver:
- Serg Melikyan
- Priority:
- Medium
- Drafter:
- Dmitry Teselkin
- Direction:
- Approved
- Assignee:
- Ekaterina Chernova
- Definition:
- Approved
- Series goal:
- Accepted for future
- Implementation:
-
Implemented
- Milestone target:
-
next
- Started by
- Ekaterina Chernova
- Completed by
- Kirill Zaitsev
Related branches
Related bugs
Sprints
Whiteboard
1. Implement base class for tests. It should have load function, that will be able to load object model. At this momemt full object model should be palced in test itself. Also it should have all necessary asserts 2-3 days
2. Implement test-runner
All tests from all classes of a provided packages are executed by default. User can specify class or test to execute. Murano config may be specified, so token can be generated and passed to OM. If config is not provided, stub will be used instead of real token. 1 day
3. Implement monkey patching.
Create function, called 'patch', that will replace implementation of provided function to other function. - 1 week
This funtion should be able replace to replace methods from 2 kind of objects:
a) python classes
b) yaml classes
c) dependent applications
4. Implement mocks for base classes. So default mocks will be used and user will not have to write mocks in he's tests. But he will be able to replace mock with written by his own. 1,5 week
5.Implement analog of MagicMock in python, but to be implemented in MuranoPL.
We can't write mocks for all classes, so magic mock is needed to be able to replave any called method with mocked one, so fake oject will be crated automatically. 1 week
Gerrit topic: https:/
Addressed by: https:/
Introduce test-runner for MuranoPL test packages
Addressed by: https:/
Migration to yaql 1.0
Addressed by: https:/
Implement base io.murano.
Addressed by: https:/
[docs] Add murano test runner information
Addressed by: https:/
Fix test class property access in mocks
Work Items
Dependency tree
* Blueprints in grey have been implemented.
