Browse Prior Art Database

Deployment scripts with proscriptive scopes

IP.com Disclosure Number: IPCOM000237483D
Publication Date: 2014-Jun-18
Document File: 3 page(s) / 114K

Publishing Venue

The IP.com Prior Art Database

Abstract

Scripts are registered with proscriptive scopes (such as "compute" or "controller", "pre" or "post"), and restricted accordingly when they are used during deployment. A given scope can be a wildcard, such as "all".

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 3

Deployment scripts with proscriptive scopes

Disclosed is a method for indicating scopes during script registration, so that the scope will be restricted during deployment. When deploying a new cloud, the user has the option to run scripts before and after deployment, and also to use the deployment scripts that are already registered. By clicking on "Add Script" button, a dialog prompts user to select the corresponding host and script. This kind of practice is typical in cloud management solutions. In this solution, these deployment scripts are registered before the deployment process in order to make it easier for the user to use and re-use.

These are some existing examples of script registration in the field: http://sourceforge.net/apps/trac/sourceforge/wiki/CVS%20hook%20scripts


1.

http://msdn.microsoft.com/en-us/library/dd293663.aspx


2.

However, in these scenarios problems can be faced. The user may use the wrong context and cause the deployment to fail. For example, a script may be specified to run before deployment but instead ran after deployment by user 's mistake. There is nothing to prevent the user to make these kind of mistakes, and also no detection after the mistake occurs. This may leave the user's environment in a bad state and they can't understand why.

The advantages of this method are:
Prevents scripts that are designed only for a specific purpose from being misused. Avoid user errors which can cause significant consequences.

The user does not have to remember each script scope or find out script ran on the wrong machine only until deployment fails .

It frees the product from providing error handling and recovery cause by misused scripts.

Wildcards enable re-use of the same script with different scope values on different machines. Users do not have to upload the same script file many times and register them with different scope values.

During the registration of the scripts (shown in Figure 1), a script is uploaded and its proscriptive scopes are selected by the user. In this case, scripts can be run on compute, controller, or both types of hosts. A script can also run before deployment (pre), post deployment (post), or both.

Figure 1.

In this way, the user creates a list of already registered scripts in Figure 2.

Figure 2.

Later, during deployment of a cloud, the user will add a script to run shown in Figure 3.

1


Page 02 of 3

Figure 3.

Wh...