Does “optional” in a resource in the provisioning stage make sense for attributes that the end user does not choose? The provision step in the workflow is used to create the ID and call whatever management system to provision the actual product. Does "optional" just mean that in the final subscription the parameter can be left empty by the user?
Does “optional” in a resource in the provisioning stage make sense for attributes that the end user does not choose? The provision step in the workflow is used to create the ID and call whatever management system to provision the actual product. Does "optional" just mean that in the final subscription the parameter can be left empty by the user?
**Optional means that the user is allowed to submit the process/subscription with the resource left empty.**
**Optional means that the user is allowed to submit the process/subscription with the resource left empty.**
How to enforce that each TrunkConfig has exactly 2 TrunkConfigSide? n the workflow, in the selector of the parent product block, in Choice you can specify min_items and max_items. But in my case hierarchy is in the opposite direction (I can select multiple trunk_config from trunk_config_side but not the other way around). So it seems this can't be enforced by WFO?
How to enforce that each TrunkConfig has exactly 2 TrunkConfigSide? n the workflow, in the selector of the parent product block, in Choice you can specify min_items and max_items. But in my case hierarchy is in the opposite direction (I can select multiple trunk_config from trunk_config_side but not the other way around). So it seems this can't be enforced by WFO?
**You can create two TrunkConfigSide's that refer to the same TrunkConfig block (but this is not enforced, you can have 0, 1, or 3+, like with other products)**
**You can create two TrunkConfigSide's that refer to the same TrunkConfig block (but this is not enforced, you can have 0, 1, or 3+, like with other products)**
How hierarchy should be (TrunkConfig contains product block reference to Trunk like it is now, or the opposite)? As it’s now, you make a Trunk first, and in TrunkConfig input you select a Trunk. Then in TrunkConfigCommon and TrunkConfigSide input you select a TrunkConfig.
How hierarchy should be (TrunkConfig contains product block reference to Trunk like it is now, or the opposite)? As it’s now, you make a Trunk first, and in TrunkConfig input you select a Trunk. Then in TrunkConfigCommon and TrunkConfigSide input you select a TrunkConfig.
### Workflows
### Workflows
- Create / Modify? / Terminate for:
- Create / Modify? / Terminate for:
- Trunk
- Trunk
- TrunkConfig
- TrunkConfig
- TrunkConfigCommon
- TrunkConfigCommon
- TrunkConfigSide
- TrunkConfigSide
### Workflow doubts
### Workflow doubts
In the example tutorial, _provision_in_group_management_system, a hash is created from something like the user_name and that builds the user_id. Does this mean that user_name is unique? How is this enforced?
In the example tutorial, _provision_in_group_management_system, a hash is created from something like the user_name and that builds the user_id. Does this mean that user_name is unique? How is this enforced?
Can you select which resource types are “fixed” in the modify workflow once the subscription of a trunk service is Active?
Can you select which resource types are “fixed” in the modify workflow once the subscription of a trunk service is Active?
If I update the python code of a workflow but its name and associated product stays the same, do I have to do anything to reflect its update (e.g. delete the workflow in a migration then add it again, or just add it again, or do nothing)?
If I update the python code of a workflow but its name and associated product stays the same, do I have to do anything to reflect its update (e.g. delete the workflow in a migration then add it again, or just add it again, or do nothing)?
**Nothing needs to be done**
**Nothing needs to be done**
I have a workflow called “create_trunk”, which is a workflow of the product type called “Trunk”.
I have a workflow called “create_trunk”, which is a workflow of the product type called “Trunk”.
I get this error when trying to “Create new process / subscription” in the GUI after registering the workflows, and also by doing a POST to http://10.98.1.62:8080/api/processes/create_trunk:
I get this error when trying to “Create new process / subscription” in the GUI after registering the workflows, and also by doing a POST to http://10.98.1.62:8080/api/processes/create_trunk:
``INFO: 10.98.1.62:53656 - "POST /api/processes/create_trunk HTTP/1.1" 404 Not Found``
``INFO: 10.98.1.62:53656 - "POST /api/processes/create_trunk HTTP/1.1" 404 Not Found``
Is process the same as subscription? If not, what’s the endpoint/way to create a subscription from a workflow?
Is process the same as subscription? If not, what’s the endpoint/way to create a subscription from a workflow?
**Running products DB migration again fixed this (even though I think I submitted exactly the same data...)**
**Running products DB migration again fixed this (even though I think I submitted exactly the same data...)**
## TODO
## TODO
- The current input form for the members list in create_trunk_config_side is not apprpriate for a list
- Fix flake8 errors for main.py products and workflows imports
- Integrate provision step (in CreateTrunkConfigSide) with IPAM/Infoblox
- The current input form for the members list in create_trunk_config_side is not apprpriate for a list
- Integrate provision step (in CreateTrunkConfigSide) with IPAM/Infoblox
