2). BidEngine Calls/Initiates an Event Bus to Monitor New Orders
The NewService function called from provider/bidengine/service.go checks for existing orders and subscribes to a RPC node event bus for new order processing.
Eventually the run method in this package is called with a service type passed in.
3). BidEngine Loop is Created to React to New Order Receipt and Then Process Order
Within the run function of provider/bidengine/service.go an endless for loop monitors for events placed onto a channel.
When an event of type EventOrderCreated is seen a call to the newOrder function - which exists in provider/bidengine/order.go - is initiated. The newOrder function call creates a new manager for a specific order.
4). Order/Bid Process Manager Uses Perpetual Loop for Event Processing and to Complete Each Step in Bid Process
When the newOrder function within order.go is called in the previous step, an order struct is populated and then passed to the run method.
Within the run function details of the order are fetched.
groupch Channel
Still within the run function, a perpetual for loop awaits order group details to be sent to a channel named groupch. When order/group details are placed onto that channel, the shouldBid method is called.
Eventually the result of calling shouldBid will be placed onto the shouldBidCh provoking further upstream order processing. But prior to review upstream steps we will detail the shouldBid function logic.
shouldBidCh Channel
When a result from the prior step is placed onto the shouldBinCh channel, the shouldBid function - also located within provider/bidengine/order.go - processes several validations to determine if the provider should bid on the order.
The validations include:
MatchAttributes - return unable to fulfill if provider does not possess necessary attributes
MatchResourcesRequirements - return unable to fulfill if provider does not possess required, available resources
SignedBy - return attribute signature requirements not met if provider does not possess required audited attributes
Should either MatchAttributes, MatchResourcesRequirements, or SignedBy evaluations fail to satisfy requirements, a boolean false is returned. If the result evaluates to false - meaning one of the validations does not satisfy requirements, shouldBid is set to false, the loop is exited, and a log message of decline to bid on the order is populated.
The next step will begin the Kubernetes cluster reservation of requested resources.
While the bid process proceeds the reservation of resources in the Provider’s Kubernetes cluster occurs via a call to the cluster.Reserve method. If the bid is not won the reservation will be cancelled.
If the provider is capable of satisfying all of the requirements of the order the result is placed onto the clusterch channel which provokes the next step of order processing.
The Reserve function called - the result of which is placed onto the clusterch channel - is called from provider.service.go.
clusterch Channel
When a result from the prior step is placed onto the clusterch channel, an analysis is made to ensure no errors were encountered during the Kubernetes cluster reservation. If not error is found a log entry of Reservation fulfilled is populated.
If the Kubernetes cluster reservation for the order is successful, the result of calling the CalculatePrice method (using the order specs as input) is placed onto the pricech channel which provokes the next step of order processing.
Calling CalculatePrice provokes the logic to determine price extended thru bid response.
The CalculatePrice function is located in /bidengine/pricing.go and will determine the price used in bid response to the order. The price will be dictated by the order specs - I.e. CPU/memory/storage/replicas, etc - and the Provider’s pricing script which defines per specification price.
When a result from the prior step is placed onto the pricech channel, an analysis is made to ensure that the bid price is not larger than the max price defined in deployment manifest.
If the order gets past the maxPrice check the logs are populated with the submitting fulfillment with specified price message.
If the bid proceeds we eventually broadcast the bid to the blockchain and write the results of this transaction to the bidch channel which provokes additional upstream logic covered in the next section.
bidch Channel
When a result from the prior step is placed onto the bidch channel, an error check is made to ensure the bid has not failed for any reason. And post this final bid validator a message is written to the provider logs of bid complete.
The Bid Engine Service logic for single bid processing is now complete. The Bid Engine perpetual loop will continue to monitor for new orders found on the blockchain and repeat reviewed order processing on each receipt.