Abstract: Techniques are disclosed for migrating one or more services from an edge device to a cloud computing environment. In one example, a migration service receives a request to migrate a first set of services from the edge device to the cloud computing environment. The migration service identifies a hardware profile of a computing device (or devices) of the cloud computing environment that matches the edge device, and then configures the computing device to execute a second set of services that corresponds to the first set of services. The migration service establishes a communication channel between the edge device and the computing device, and then executes a set of migration operations such that the second set of services is configured to execute as the first set of services. The computing device may operate in a virtual bootstrap environment or dedicated region of the cloud computing environment.

Abstract: Techniques are disclosed for deploying a computing resource (e.g., a service) in response to user input. A computer-implemented method can include operations of receiving (e.g., by a gateway computer of a cloud-computing environment) a request comprising an identifier for a computing component of the cloud-computing environment. The computing device receiving the request may determine whether the identifier exists in a routing table that is accessible to the computing device. If so, the request may be forwarded to the computing component. If not, the device may transmit an error code (e.g., to the user device that initiated the request) indicating the computing component is unavailable and a bootstrap request to a deployment orchestrator that is configured to deploy the requested computing component. Once deployed, the computing component may be added to a routing table such that subsequent requests can be properly routed to and processed by the computing component.

Abstract: Techniques are disclosed for migrating one or more services from an edge device to a cloud computing environment. In one example, a migration service receives a request to migrate a first set of services from the edge device to the cloud computing environment. The migration service identifies a hardware profile of a computing device (or devices) of the cloud computing environment that matches the edge device, and then configures the computing device to execute a second set of services that corresponds to the first set of services. The migration service establishes a communication channel between the edge device and the computing device, and then executes a set of migration operations such that the second set of services is configured to execute as the first set of services. The computing device may operate in a virtual bootstrap environment or dedicated region of the cloud computing environment.

Abstract: Techniques discussed herein relate to monitoring and/or detecting destabilization events of a host machine of a cloud computing environment. At least some of these destabilization events can be associated with a converged network adaptor of the host machine. The converged network adaptor may include a combination of functionality of a host network interface card (NIC) and functionality associated with a smart adaptor (e.g., a smart NIC). The smart adaptor may be configured to use at the host machine. A converged infrastructure management service may monitor operational data associated with the host machine to identify destabilization events that may be associated with the converged network adaptor. One or more remedial actions may be identified based at least in part on identifying these destabilizing events.

Abstract: Techniques are disclosed for deploying a computing resource (e.g., a service) in response to user input. A computer-implemented method can include operations of receiving (e.g., by a gateway computer of a cloud-computing environment) a request comprising an identifier for a computing component of the cloud-computing environment. The computing device receiving the request may determine whether the identifier exists in a routing table that is accessible to the computing device. If so, the request may be forwarded to the computing component. If not, the device may transmit an error code (e.g., to the user device that initiated the request) indicating the computing component is unavailable and a bootstrap request to a deployment orchestrator that is configured to deploy the requested computing component. Once deployed, the computing component may be added to a routing table such that subsequent requests can be properly routed to and processed by the computing component.

Abstract: Techniques are disclosed for deploying a computing resource (e.g., a service) in response to user input. A computer-implemented method can include operations of identifying a first set of computing components already deployed within the cloud-computing environment and identifying a second set of computing components available for deployment within the cloud-computing environment. A request for deployment may be subsequently received for one of the available computing components. A bootstrap request corresponding to the particular computing component requested may be transmitted to a deployment orchestrator, the deployment orchestrator being configured to deploy the particular computing component to the cloud-computing environment based at least in part on the bootstrap request. A user interface may present status indicators for each computing component (e.g., deployed, available, requested, etc.).

Abstract: Techniques are disclosed for processing flows by a smart network interface card (smartNIC) based on modifying a packet. In one example, an accelerator receives a packet from a first port of the smartNIC. The accelerator determines that the packet was received from a first port via a second data path instead of a first data path. The accelerator modifies the packet to indicate that the packet arrived from the first port via the second data path. The accelerator inserts the modified packet into a queue. A programming data plane of the smartNIC receives the modified packet from the queue. The programming data plane processes the modified packet based at least in part on determining that the packet arrived at the first port via the second data path.

Abstract: Techniques are disclosed for a smart network interface card (smartNIC) performing a unified logging process. In one example, an accelerator transmits a packet to a programming data plane of the smart network interface card. The programming data plane determines whether the packet is to be forwarded. In accordance with a determination that the packet is not be forwarded, the programming data plane modifies the packet to include an instruction that instructs the accelerator to log the packet and to not forward the packet. The programming data plane transmits the modified packet to the accelerator. The accelerator logs data associated with the modified packet to a unified log based at least in part on the instruction.

Abstract: Techniques are disclosed for utilizing control packets to manage flows. In one example, an accelerator determines that a cache entry is a candidate for removal, the accelerator being responsible for forwarding packets associated with a particular flow based at least in part on a flow state. The accelerator generates an instruction to remove a cache entry of the particular flow from a cache based at least in part on receiving the determination that the cache entry is the candidate for removal. The accelerator removes the cache entry from the cache based at least in part on the instruction. The accelerator generates a control packet that includes a flow information associated with the particular flow being formatted utilizing a particular header format. The accelerator transmits the control packet to a programming data plane utilizing a path based at least in part on the control packet utilizing the particular header format.

Abstract: Techniques are disclosed for a smart network interface card (smartNIC) performing a unified logging process. In one example, an accelerator of the smartNIC receives a packet that is a candidate for rejection, whereby the accelerator is configured to log traffic for authorized flows that are forwarded by the accelerator to another device. The accelerator transmits the packet to a programming data plane of the smartNIC for further processing. The programming data plane determines that the packet should not be forwarded by the smartNIC, and modifies the packet to include an instruction that instructs the accelerator to log the packet. The programming data plane then transmits the modified packet to the accelerator. Upon receiving the modified packet, the accelerator logs the packet to the unified log based on the instruction.

Abstract: Techniques are disclosed for processing flows by a smart network interface card (smartNIC) based on modifying a packet. In one example, a smartNIC accelerator receives a packet from a first port of the smartNIC, the first port being connected to a splitter device that splits a first data path into a second data path and a third data path, and the packet arriving at the first port via the second data path. The accelerator modifies the packet to indicate that the packet arrived at the first port via the second data path. The accelerator inserts the modified packet into a queue that is associated with both the second data path and the third data path. A programming data plane of the smartNIC receives and then processes the modified packet based on determining that the packet arrived at the first port via the second data path.

Abstract: Techniques are disclosed for utilizing control packets to manage flows by a smart network interface card (smartNIC). In one example, an accelerator determines that a cache entry is a candidate for removal, the cache entry being part of a cache that is managed by the accelerator, the cache entry storing flow state of a particular flow, the accelerator being responsible for forwarding packets associated with the particular flow based at least in part on the flow state, and the flow information formatted utilizing a particular header format. The accelerator generates an instruction to remove the cache entry of the particular flow from the cache based at least in part on receiving the determination that the cache entry is the candidate for removal. The accelerator removes the cache entry of the particular flow from the cache based at least in part on the instruction.

Abstract: The present disclosure is directed to devices and techniques for auto-qualifying images on new hardware or infrastructure configurations. The systems and methods include initiating an auto-qualification process for pre-testing one or more images registered within a bare metal system having one or more new infrastructure configurations, discovering all of the one or more images registered for use within the bare metal system, booting each of the one or more registered images into an isolated infrastructure having the one or more new infrastructure configurations, probing instances of each of the one or more registered images booted on the isolated infrastructure to determine stability of each of the one or more registered images on the one or more new infrastructure configurations, and marking each of the one or more registered images as stable or unstable.

Abstract: Techniques are disclosed for deploying a computing resource (e.g., a service) in response to user input. A computer-implemented method can include operations of receiving (e.g., by a gateway computer of a cloud-computing environment) a request comprising an identifier for a computing component of the cloud-computing environment. The computing device receiving the request may determine whether the identifier exists in a routing table that is accessible to the computing device. If so, the request may be forwarded to the computing component. If not, the device may transmit an error code (e.g., to the user device that initiated the request) indicating the computing component is unavailable and a bootstrap request to a deployment orchestrator that is configured to deploy the requested computing component. Once deployed, the computing component may be added to a routing table such that subsequent requests can be properly routed to and processed by the computing component.

Abstract: Techniques are disclosed for deploying a computing resource (e.g., a service) in response to user input. A computer-implemented method can include operations of receiving (e.g., by a gateway computer of a cloud-computing environment) a request comprising an identifier for a computing component of the cloud-computing environment. The computing device receiving the request may determine whether the identifier exists in a routing table that is accessible to the computing device. If so, the request may be forwarded to the computing component. If not, the device may transmit an error code (e.g., to the user device that initiated the request) indicating the computing component is unavailable and a bootstrap request to a deployment orchestrator that is configured to deploy the requested computing component. Once deployed, the computing component may be added to a routing table such that subsequent requests can be properly routed to and processed by the computing component.

Abstract: Techniques are disclosed for deploying a computing resource (e.g., a service) in response to user input. A computer-implemented method can include operations of identifying a first set of computing components already deployed within the cloud-computing environment and identifying a second set of computing components available for deployment within the cloud-computing environment. A request for deployment may be subsequently received for one of the available computing components. A bootstrap request corresponding to the particular computing component requested may be transmitted to a deployment orchestrator, the deployment orchestrator being configured to deploy the particular computing component to the cloud-computing environment based at least in part on the bootstrap request. A user interface may present status indicators for each computing component (e.g., deployed, available, requested, etc.).

Abstract: Techniques are described for changing and customizing the functional behavior of a network virtualization device (NVD) using multiple different personalities. The disclosed techniques enable a network device such as an NVD to be configured and reconfigured during its lifetime to support different functional behaviors in an easy and convenient manner. In certain embodiments, this is accomplished through the use of personalities. During the lifetime of an NVD, different personalities may be associated with or bound to an NVD, where the personality bound to a NVD determines the capabilities or functional behavior of the NVD. By changing the personalities bound to an NVD, the functional behavior, characterized by a set of functions that the NVD can perform, can be changed.

Abstract: Techniques are disclosed for deploying a computing resource (e.g., a service) in response to user input. A computer-implemented method can include operations of receiving (e.g., by a gateway computer of a cloud-computing environment) a request comprising an identifier for a computing component of the cloud-computing environment. The computing device receiving the request may determine whether the identifier exists in a routing table that is accessible to the computing device. If so, the request may be forwarded to the computing component. If not, the device may transmit an error code (e.g., to the user device that initiated the request) indicating the computing component is unavailable and a bootstrap request to a deployment orchestrator that is configured to deploy the requested computing component. Once deployed, the computing component may be added to a routing table such that subsequent requests can be properly routed to and processed by the computing component.

Abstract: Techniques are disclosed for efficient communications over a network path between an accelerator of a smart network interface card (smartNIC) and a remote programming data plane of a remote device. In one example, the accelerator receives an instruction to register a pairing between the accelerator and the remote programming data plane, and then stores registration data indicating the pairing. The accelerator then receives from the remote programming data plane a second instruction associated with processing one or more flows. The accelerator then stores instruction data corresponding to the second instruction based on confirming the registered pairing with the remote programming data plane. Subsequently, the accelerator receives a data packet and processes the data packet in accordance with the stored instruction data. In some embodiments, the accelerator may transmit packets to the pair remote programming data plane, for example, requesting further instructions associated with processing a packet.

Abstract: Techniques are disclosed for a smart network interface card (smartNIC) performing a unified logging process. In one example, an accelerator of the smartNIC receives a packet that is a candidate for rejection, whereby the accelerator is configured to log traffic for authorized flows that are forwarded by the accelerator to another device. The accelerator transmits the packet to a programming data plane of the smartNIC for further processing. The programming data plane determines that the packet should not be forwarded by the smartNIC, and modifies the packet to include an instruction that instructs the accelerator to log the packet. The programming data plane then transmits the modified packet to the accelerator. Upon receiving the modified packet, the accelerator logs the packet to the unified log based on the instruction.