Skip to content
Snippets Groups Projects

Modeling of Trunk service in WFO

Products & fixed inputs

  • Trunk
    • Reference to PB Trunk
  • TrunkConfig
    • Reference to PB TrunkConfig
  • TrunkConfigCommon
    • Reference to PB TrunkConfigCommon
  • TrunkConfigSide
    • Reference to PB TrunkConfigSide

Product blocks & resource types

  • Trunk
    • Id
    • GeantSSid
    • Name
  • TrunkConfig
    • Id
    • Reference to PB Trunk
  • TrunkConfigCommon
    • Id
    • Speed
    • IsLeasedLine
    • IsIsMetric
    • MinimumLinks
    • Reference to PB TrunkConfig
  • TrunkConfigSide
    • Id
    • Name
    • AEName
    • GeantASid
    • IPv4Address
    • IPv6Address
    • Members (How to model arrays?)
    • Reference to PB TrunkConfig

Doubts related to products

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.

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)

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

  • Create / Modify? / Terminate for:
    • Trunk
    • TrunkConfig
    • TrunkConfigCommon
    • TrunkConfigSide

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?

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)? Nothing needs to be done

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: 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? Running products DB migration again fixed this (even though I think I submitted exactly the same data...)

TODO

  • Fix flake8 errors for main.py products and workflows imports
  • Integrate provision step (in CreateTrunkConfigSide) with IPAM/Infoblox

Resources

WFO API: https://workfloworchestrator.org/orchestrator-core/architecture/application/api/ (Swagger) https://github.com/workfloworchestrator/orchestrator-core/tree/main/orchestrator/api/api_v1/endpoints

Carolina notes: https://wiki.geant.org/pages/viewpage.action?pageId=562921625