uncloud
/
uncloud
2
0
Fork 1
Code Issues 4 Pull Requests Projects Releases Wiki Activity

Don't run code in the TIMEOUT event (check that we don't do that) #14

New Issue
Closed
opened 2021-11-20 11:15:25 +00:00 by ungleich-gitea · 12 comments
ungleich-gitea commented 2021-11-20 11:15:25 +00:00
Copy Link

I think the following logic is fundamentally broken:

        for request_event in request_iterator:
            request_entry = RequestEntry(request_event)
            # Never Run time critical mechanism inside timeout
            # mechanism because timeout mechanism only comes
            # when no other event is happening. It means under
            # heavy load there would not be a timeout event.
            if request_entry.type == "TIMEOUT":

                # Detect hosts that are dead and set their status
                # to "DEAD", and their VMs' status to "KILLED"
                dead_hosts = dead_host_detection()
                if dead_hosts:
                    logger.debug("Dead hosts: %s", dead_hosts)
                    dead_host_mitigation(dead_hosts)

Just run the code that should ALWAYS be executed prior to the if statement.

I think the following logic is fundamentally broken: ``` for request_event in request_iterator: request_entry = RequestEntry(request_event) # Never Run time critical mechanism inside timeout # mechanism because timeout mechanism only comes # when no other event is happening. It means under # heavy load there would not be a timeout event. if request_entry.type == "TIMEOUT": # Detect hosts that are dead and set their status # to "DEAD", and their VMs' status to "KILLED" dead_hosts = dead_host_detection() if dead_hosts: logger.debug("Dead hosts: %s", dead_hosts) dead_host_mitigation(dead_hosts) ``` Just run the code that should ALWAYS be executed prior to the if statement.
ahmedbilal was assigned by ungleich-gitea 2021-11-20 11:15:25 +00:00
ungleich-gitea commented 2021-11-20 11:15:41 +00:00
Author
Copy Link

Removed, although still have some concerns. See the above comment.

Removed, although still have some concerns. See the above comment.
ungleich-gitea commented 2021-11-20 11:15:41 +00:00
Author
Copy Link

@nico I am not sure yet about removing the timeout mechanism and moving the maintenance code inside i.e handling of user's request, because it is entirely possible that user's don't make any request for a long time which also means that we won't execute the maintenance code that is responsible for updating the status/hostname of VMs.

@nico I am not sure yet about removing the timeout mechanism and moving the maintenance code inside i.e handling of user's request, because it is entirely possible that user's don't make any request for a long time which also means that we won't execute the maintenance code that is responsible for updating the status/hostname of VMs.
ungleich-gitea commented 2021-11-20 11:15:42 +00:00
Author
Copy Link

Thanks. Yes, it doesn't make sense in scheduler.

Thanks. Yes, it doesn't make sense in scheduler.
ungleich-gitea commented 2021-11-20 12:32:42 +00:00
Author
Copy Link

Removed, although still have some concerns. See the above comment.

Removed, although still have some concerns. See the above comment.
ungleich-gitea commented 2021-11-20 12:32:43 +00:00
Author
Copy Link

@nico I am not sure yet about removing the timeout mechanism and moving the maintenance code inside i.e handling of user's request, because it is entirely possible that user's don't make any request for a long time which also means that we won't execute the maintenance code that is responsible for updating the status/hostname of VMs.

@nico I am not sure yet about removing the timeout mechanism and moving the maintenance code inside i.e handling of user's request, because it is entirely possible that user's don't make any request for a long time which also means that we won't execute the maintenance code that is responsible for updating the status/hostname of VMs.
ungleich-gitea commented 2021-11-20 12:32:43 +00:00
Author
Copy Link

Thanks. Yes, it doesn't make sense in scheduler.

Thanks. Yes, it doesn't make sense in scheduler.
ungleich-gitea commented 2021-11-20 13:21:08 +00:00
Author
Copy Link

Removed, although still have some concerns. See the above comment.

Removed, although still have some concerns. See the above comment.
ungleich-gitea commented 2021-11-20 13:21:08 +00:00
Author
Copy Link

@nico I am not sure yet about removing the timeout mechanism and moving the maintenance code inside i.e handling of user's request, because it is entirely possible that user's don't make any request for a long time which also means that we won't execute the maintenance code that is responsible for updating the status/hostname of VMs.

@nico I am not sure yet about removing the timeout mechanism and moving the maintenance code inside i.e handling of user's request, because it is entirely possible that user's don't make any request for a long time which also means that we won't execute the maintenance code that is responsible for updating the status/hostname of VMs.
ungleich-gitea commented 2021-11-20 13:21:08 +00:00
Author
Copy Link

Thanks. Yes, it doesn't make sense in scheduler.

Thanks. Yes, it doesn't make sense in scheduler.
ungleich-gitea commented 2021-11-20 15:16:57 +00:00
Author
Copy Link

Removed, although still have some concerns. See the above comment.

Removed, although still have some concerns. See the above comment.
ungleich-gitea commented 2021-11-20 15:16:58 +00:00
Author
Copy Link

@nico I am not sure yet about removing the timeout mechanism and moving the maintenance code inside i.e handling of user's request, because it is entirely possible that user's don't make any request for a long time which also means that we won't execute the maintenance code that is responsible for updating the status/hostname of VMs.

@nico I am not sure yet about removing the timeout mechanism and moving the maintenance code inside i.e handling of user's request, because it is entirely possible that user's don't make any request for a long time which also means that we won't execute the maintenance code that is responsible for updating the status/hostname of VMs.
ungleich-gitea commented 2021-11-20 15:16:58 +00:00
Author
Copy Link

Thanks. Yes, it doesn't make sense in scheduler.

Thanks. Yes, it doesn't make sense in scheduler.
nico closed this issue 2022-02-15 08:47:23 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
master
35/order-confirmation-page
38/restrict-selection
user-billing-api-revamp
update-vm-ordering
uncloud-api-refactoring
3.1.0
3.0.0
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0.1.0
0.0.8
0.0.7
0.0.6
0.0.5
0.0.4
0.0.3
0.0.2
0.0.1
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: uncloud/uncloud#14
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?