Hello,

in a CC template for installing the Integration Server, it’s possible (necessary) to specify the list of the packages to install.

Is it possible to specify the package list in different layers and have CC to collect and install all the packages?

Here’s an example of what I’m saying.

Let’s say I’d like to have the layer “Server.Core” and the layer “BPM”. With the layer “Core”, only some packages should be installed (WmRoot, WmPublic). With the layer “BPM”, the package “WmPRT” should be installed.

I’d like to specify the two layers. In the end, I’d expect that CC installs the packages WmRoot, WmPublic, and WmPRT, i.e. that it collects the packages to install over all layers.

Does CC works like this?

Thanks for any hints!

Hi,
When IS instance is declared in the template you can specify which packages should be provisioned into this instance by using ‘package.list’ parameter.
Note that these packages have to be first installed as ‘products’ in the same or previous layer/template.

Here is an example:

templates:
myis: 
licenses:
"IntegrationServer/config/licenseKey.xml": ${is.license.key.alias}
products:
Deployer:
Monitor:
integrationServer: # the core IS product that owns the instance 
Monitor:
primary.port:    5555 
diagnostic.port: 5556
jmx.port:        5557
license.file: IntegrationServer/config/licenseKey.xml
package.list: WmMonitor
Deployer:
primary.port:    6666 
diagnostic.port: 6667
jmx.port:        6668
license.file: IntegrationServer/config/licenseKey.xml
package.list: WmBrokerDeployer,WmNUMDeployer,WmDeployer

You do not need to specify core packages like WmRoot,WmPublic. They are always provisioned.

Thanks
Sergei

Sergei, thank you for the response.

I must have been a bit unclear about what I want because your example does not quite fit my need.

I’d like to have three layers: One for the core IS, another for the Monitor (I’ll use your example) and still another for the Deployer, like this:

templates:
IS-Product:  # This will install the product but will not set up an instance
products:
integrationServer:
Monitor-Product:  # This will install the product but will not set up an instance
products:
Monitor:
Deployer-Product:  # This will install the product but will not set up an instance
products:
Deployer:
IS-Instance:  # This will set up an instance with just the basic packages
products:
integrationServer:
default: # Name of the instance we're working on
# . . . (config etc)
Monitor-Instance:  # This will install monitor packages in the instance
products:
integrationServer:
default: # Name of the instance we're working on
package.list: WmMonitor
Deployer-Instance:  # This will install deployer packages in the instance
products:
integrationServer:
default: # Name of the instance we're working on
package.list: WmBrokerDeployer,WmNUMDeployer,WmDeployer

layers:
IS-with-Instance:
templates: [IS-Product, IS-Instance]
Monitor-with-Instance:
templates: [Monitor-Product, Monitor-Instance]
Deployer-with-Instance:
templates: [Deployer-Product, Deployer-Instance]

provision:
default:
mySingleNode: [IS-with-Instance, Monitor-with-Instance, Deployer-with-Instance]

I.e. the whole Integration Server is set up not via just one but via three layers, I hope you get the idea.

My expectation / desired result is that the above fragment would install the IS with the Monitor and Deployer components, and set up an instance named “default” with IS packages WmMonitor, WmBrokerDeployer, WmNUMDeployer, WmDeployer. I.e. the package list is the cumulated list from all the templates. This would allow me to construct templates in a very modular way.

Here is how you can achieve that:

environments:
default:
is.templates: [is-core]
monitor:
is.templates: [is-core,is-monitor]
deployer:
is.templates: [is-core,is-deployer]
all:
is.templates: [is-core,is-monitor,is-deployer]

layers:
is:
templates: ${is.templates}

templates:
is-core:
licenses:  
"IntegrationServer/config/licenseKey.xml": IS_LICENSE_KEY
products:
integrationServer:
default:
primary.port: 5555
diagnostic.port: 5556  
jmx.port:        5557  
license.file: IntegrationServer/config/licenseKey.xml
is-monitor:
products:
Monitor:
integrationServer:
default:
package.list: WmMonitor
is-deployer:
products:
Deployer:
integrationServer:
default:
package.list: WmBrokerDeployer,WmNUMDeployer,WmDeployer

Now run

provision core IS

sagcc exec templates composite apply mytemplate

provision core IS with Monitor

sagcc exec templates composite apply mytemplate environment.type=monitor

provision core IS with Deployer

sagcc exec templates composite apply mytemplate environment.type=deployer

provision core IS with Deployer and Monitor

sagcc exec templates composite apply mytemplate environment.type=all

NOTE: I did not test it but it should work this way.

Thanks
Sergei

Sergei,

I understand how your solution would work. Do you mean that my approach will NOT work? I.e. that it is not possible for CC to collect e.g. the IS packages over different layers and templates within them?

For some reasons I’d prefer to have many layers – like in the example I gave.

Thanks!

The layers should be used for actual software stack layers definition that can be deployed and scale independently from other layers.
Inline templates should be used as tasks/steps to build them.
What you’d like to do will work if you always co-locale all your layers which is a limitation of the generic design.

But if this is what you prefer, go for it, it will work, just ensure that your layers map to the same set of nodes.

Thanks
Sergei

OK, that’s what I wanted to know. Thank you very much! The consistency will be provided by the fact that we generate the templates not manually but with a tool.

I’m curious what kind of tool? Something you developed or will develop?
Can you share more details?
Thanks,
Sergei

I’m not sure I may share all the details in public, but it’s kind of templating engine to create complex CC templates from smaller building blocks.

Hi Sergie, can ou please post the full template, I need it for my reference.

@fml2 : i would like to know if you can share some details about that tool. We have about 130 Integrations servers

I created the tool as we planned to use CC to set up our servers. We still do not use CC because there were always some issues preventing its usage (some components could not be set up in the desired way). It’s possible that the problems are resolved in the mean time, we didn’t try again.

But the idea was that you have small files, each describing an aspect of the whole system. Each file is small and very well maintainable.

Then you have another file that describes how the small building blocks should be combined to produce more coarse grained features. And then you’d have yet another file describing which features should be installed to which nodes.

The tool processes all the files and produces a big template which can be fed to CC. An aspect might occur hundreds of times in the resulting template. The template is guaranteed to be consistent. If the definition of an aspect changes, you just edit a small file for that aspect, and then run the tool again.

I.e. it is “divide and conquer” approach.

There is a smart mechanism allowing to set certain values (e.g. node address) in a consistent way.

Since we don’t use CC, we also do not use the tool. Besides, this approach (creating large templates on the client side) is not the approach chosen by SAG. SAG chose to let people to compose bigger templates via CC GUI (or the command line) on the server side. Which is an inferior approach IMO, but my opinion is biased.