Abstract: Technologies are provided for non-monotonic eventual convergence for desired state configuration (“DSC”). In some situations DSC cannot move toward a desired state without first moving further from that state. For example, a file that needs to be replaced with a newer version but that is currently executing (desired state of “operating”) cannot be replaced without first being stopped. But stopping moves in the wrong direction relative to the desired state, which is to have the service operating. This moving away so as to be able to move forward is a problem for conventional DSC systems that results in failures. The solution to this problem is non-monotonic eventual convergence (“NMEC”) which enables a DSC system to configure a target system for a desired state by moving further away from a desired state if that is needed to eventually reach the desired state.

Abstract: Technologies are provided for non-monotonic eventual convergence for desired state configuration (“DSC”). In some situations DSC cannot move toward a desired state without first moving further from that state. For example, a file that needs to be replaced with a newer version but that is currently executing (desired state of “operating”) cannot be replaced without first being stopped. But stopping moves in the wrong direction relative to the desired state, which is to have the service operating. This moving away so as to be able to move forward is a problem for conventional DSC systems that results in failures. The solution to this problem is non-monotonic eventual convergence (“NMEC”) which enables a DSC system to configure a target system for a desired state by moving further away from a desired state if that is needed to eventually reach the desired state.

Abstract: Technologies are provided for non-monotonic eventual convergence for desired state configuration. One class of problem in DSC is that, in some situations, DSC cannot move forward toward a desired state without first moving further from the desired state. For example, an executable file providing a service that needs to be replaced with a newer version, but that is currently executing (i.e., in the desired state of “operating”), cannot be replaced with the newer version without first being stopped. But stopping the service moves in the wrong direction relative to the desired state, which is to have the service operating. This moving away from the desired state so as to be able to move closer to the desired state is a problem for conventional DSC systems that results in failures. The solution to this problem is herein referred to as “non-monotonic eventual convergence” or “NMEC”.

Abstract: Technologies are provided for non-monotonic eventual convergence for desired state configuration. One class of problem in DSC is that, in some situations, DSC cannot move forward toward a desired state without first moving further from the desired state. For example, an executable file providing a service that needs to be replaced with a newer version, but that is currently executing (i.e., in the desired state of “operating”), cannot be replaced with the newer version without first being stopped. But stopping the service moves in the wrong direction relative to the desired state, which is to have the service operating. This moving away from the desired state so as to be able to move closer to the desired state is a problem for conventional DSC systems that results in failures. The solution to this problem is herein referred to as “non-monotonic eventual convergence” or “NMEC”.

Abstract: A workflow scripting system is described herein that combines the features of workflows and scripts by automatically translating between the two models. Using the system, a script author can create workflows on the fly using familiar scripting language, and a workflow author can use scripting steps to perform actions. Workflows run in this manner can be setup to execute in their own process to improve robustness or efficiency. Operations in an enterprise environment frequently take a long time and are subject to interruptions. By adding reliability concepts of workflows to a shell environment, users of the system can write scripts to address common needs of large-scale computing environments. Thus, the workflow scripting system blends the available resources provided by workflow and scripting environments to provide a host of powerful, advanced capabilities to IT personnel.

Abstract: A workflow scripting system is described herein that combines the features of workflows and scripts by automatically translating between the two models. Using the system, a script author can create workflows on the fly using familiar scripting language, and a workflow author can use scripting steps to perform actions. Workflows run in this manner can be setup to execute in their own process to improve robustness or efficiency. Operations in an enterprise environment frequently take a long time and are subject to interruptions. By adding reliability concepts of workflows to a shell environment, users of the system can write scripts to address common needs of large-scale computing environments. Thus, the workflow scripting system blends the available resources provided by workflow and scripting environments to provide a host of powerful, advanced capabilities to IT personnel.

Abstract: A shell environment may include a mechanism for executing commands on a remote device. The mechanism may retrieve remote commands and command metadata from the remote device and create scripts on a local device that may emulate the remote commands. The scripts may include authentication and other security measures, as well as help information provided by the remote device. The scripts may be grouped as a module and may be stored in a local cache. The cache may be periodically validated and when updates are available, the cache may be updated with new versions.