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.

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...

Friday Apr 13, 2007

N1SPS and Sun OTP

What is Sun OTP?

Sun OTP is a Carrier Grade platform for NEP application development, deployment and hosting that leverages commercial off-the-shelf components. OTP is also about automating deployments, and also admin procedures and runbooks.

Where does N1SPS come into play then. Well, N1SPS is one of the foundational components inside Sun OTP to be the driver and to orchestrate software deployments, upgrades and rollbacks. It also facilitates the life-cycle-management of the software.

So imagine the following scenario. I am a large Telco and I develop a lot of software. I have a lot of customers but having a hard time controlling the deployments and the software life cycle. The installation requires a lot documentation and the chance of doing something wrong is pretty high. Having someone to read, follow and execture, a 200+ steps installation guide for x number of systems... Well something is bound to go wrong.

So we have then developed and produced some foundational work with N1SPS to facilitate this. The customer can then just click on the piece of software needed, and then N1SPS knows if it is an upgrade or fresh install. It can also split the deployment to keep track on progress and if the deployment needs to be restarted from a specific point in time. The customer only needs to fill out a screen with parameters and then these will be used when the software is deployed. This will get the errors down, like human mistakes but also keep track on all the different steps needed while deploying.

The other benefit is that all this data can then later be harvested so that I, as Large Telco, knows of how things are deployed, when and by who. I can also write collection plans and scripts through N1SPS that can be used to collect information regarding this.

This is just one of the recent areas where N1SPS has been used with great success, and N1SPS is now being used as a building block for large scale NEP solutions.




« July 2016