Closed dann1 closed 4 months ago
Another example
root@opennebula-frontend:~# oneflow show 576
SERVICE 576 INFORMATION
ID : 576
NAME : Function
USER : oneadmin
GROUP : oneadmin
STRATEGY : straight
SERVICE STATE : FAILED_DEPLOYING
START TIME : 11/14 02:18:40
PERMISSIONS
OWNER : um-
GROUP : ---
OTHER : ---
ROLE FAAS
ROLE STATE : FAILED_DEPLOYING
VM TEMPLATE : 15
CARDINALITY : 1
NODES INFORMATION
VM_ID NAME USER GROUP
LOG MESSAGES
11/14/23 02:18 [I] New state: DEPLOYING_NETS
11/14/23 02:18 [E] Role FAAS : Instantiate failed for template 15; [one.template.instantiate] Error allocating a new virtual machine template. User 0 does not own a network with name: github_actions_no_lease . Set NETWORK_UNAME or NETWORK_UID of owner in NIC.
11/14/23 02:18 [I] New state: FAILED_DEPLOYING
root@opennebula-frontend:~# onevm list
ID USER GROUP NAME STAT CPU MEM HOST TIME
root@opennebula-frontend:~# oneflow recover 576
root@opennebula-frontend:~# oneflow list
ID USER GROUP NAME STARTTIME STAT
576 oneadmin oneadmin Function 11/14 02:18:40 RUNNING
root@opennebula-frontend:~# onevm list
ID USER GROUP NAME STAT CPU MEM HOST TIME
Description If a flow template is instantiated and reaches FAILED_DEPLOY, a subsequent recover operation could set the flow service to RUNNING even though it could have no VMs at all backing it.
To Reproduce
Expected behavior When issuing the recover the flow should remain in a failure state as the conditions of the failures didn't change at all. Even the cardinality is set to 1 when there are no VMs backing the role.
Additional context There might also be a problem with the core as it is possible to create a virtual network with a size 0 address range
Progress Status