Friday Jul 27, 2007

Handy N1 SPS Import-Export Feature

The N1 Service Provisioning System just got a lot easier to use,
thanks in part to a great new import-export feature. Now, you can very
simply copy a whole raft of artifacts at once between your SPS master
servers. You can roll a bunch of SPS artifacts up into what's called a "bundle
" on, say, master servers your test environment. What SPS artifacts might these be? They might be things like host types,
components, component types, folders, and any plans you want. 
And you can then get access to these SPS artifacts from another master server. How is this done? Well, you declare a list of  "search criteria" that
represent these SPS artifacts. This list of search criteria forms the bundle template. For example, a bundle template might contain criteria for searching for component types and plans. Then, with a few simple clicks, you can save this bundle template, and export it into a bundle jar. On another master server, import that bundle jar. Once you've imported the bundle jar to a master server, the SPS artifacts are now held on that master server. This means of course that you can easily copy several SPS artifacts from one master server to another, which is great for testing things out before putting them in live environments. This new feature will make things easier for those customers who want to really be able to test complex things out on in one or several SPS environments before going live. Learn how to do this using the command line. This feature is already available through the command line in the recent N1 Service Provisioning System 5.2 Update 2 release. In the upcoming N1 Service Provisioning System 6.0 release, you can also use this feature through the new, improved browser user interface.

Tuesday Jun 12, 2007

Workaround for Installing N1 SM and N1 SPS on Same System

The latest sets of release notes for N1 System Manager and N1 SPS include a workaround for installing the N1 SM managed server and N1 SPS master server on the same physical host. Essentially, you install the N1 SPS master server in an alternate root directory by prepending the following to your N1 SPS installation script.

alias -x pkgadd='pkgadd -R $NEW_PKG_ROOT'
alias -x pkginfo='pkginfo -R $NEW_PKG_ROOT'
alias -x pkgparam='pkgparam -R $NEW_PKG_ROOT'

One limitation: You can't install the OS provisioning plug-in for N1 SPS on the master server.

This is a really brief description of what's involved. Take a look at the release note for the full details.


Sunday May 27, 2007

SPS - More Best Practises and hints

Have you always wondered how things are coded and why, or why someone uses more execNative than others. Some people like to distribute a whole bunch of scripts that they run after deploying them. Why should I create a component type and when you I just create XML templates and use a lot of copy paste.

We have tried to answer some of these questions in documents that we would refer to as best practises document but also guidelines based on years of experience.

Here is one example (taken from the document):

5.6. Plan Parameters

 Pros Flexible to use since you set them when installing the components.
Static components due to "interactive" installs... Passwords since they
may not always be allowed storing somewhere.
 Cons The variables are not stored after install of component. Hard to re-use
variables. This will however change a little bit when we release SPS
6.0 later this year, where we are introduciong Variable Sets for Plans.
 Example of usage
 Using this kind of variables is perfect for non static data that is
only needed when doing the installation and when you need an
interaction from the operator running the plan. This should be used
when doing ad-hoc plans where one just need a quick response back
without the complexity of updating the component or container and also
avoid the version number increase. A typical example when this is used
is when you have a plan that simply reports a specific logfile or
textfile back to the Web UI, i.e. /usr/bin/cat <filename> where
filename would be the parameters inputted by the user at run-time.

The following example is a complete XML of a working plan. This is because all sections are needed to exemplify the use of plan parameters, e.g. paramList is needed to be able to use the parameter in combination with the execNative procedure.

<executionPlan xmlns:xsi='' name='StartServer-plan' version='5.0' path=/ >
        <param name='ServerName' prompt='Enter server to start:'>
        <var name='RunUser' default=':[session:UserName]'>
        <execNative userToRunAs=':[RunUser]'>
            <exec value=''></exec>
            <arg value=':[ServerName]'></arg>

For more information, please read at the following links:



Stay tuned for information about the SPS 6.0 release coming up...




« April 2014