Content Packs

Content Packs Alter an OCCP machine's configuration. A scenario contributor specifies one or more content packs in the ScenarioFile which allows the OccpAdmin program to configure the machine for the VSN. Currently the only type of content pack is supported by the OCCP which is Puppet Modules. Though in general content packs can take parameters and respect ConfigurationPhases. They accomplish things like installing software, adding users, transferring files, and other configuration tasks. Ideally content packs will be written with modularity in mind such that a content pack may be reused in other scenarios.

Although it is possible to write Content Packs from scratch, it is recommended that you first review how an existing Pack works, such as those available in the ReferenceVSN or the Example Scenario. You can also just use parts of those as a starting point for your own Scenario.

Puppet

These content packs are designed to work with Puppet and their structure mimics puppet modules exactly. In fact one could technically use any existing puppet module in place of a content pack with some limitations. The module would need to support the ConfigurationPhases. One issue that might prevent that would be a module that uses

ensure => latest

for software which would go against phase 1 principles. Puppet content packs may use other modules but then must include those modules in the "PackDependancies" folder in the scenario. Each puppet content pack should have configurations that will be applicable to all machines that would use the pack in it's main class, but advanced packs might make use of additional classes. Puppet content packs should test the "environment" variable to determine the Configuration Phase to apply.

Variables

Not to be confused with Variables, the Administrative VM will also write some variables when generating the node file that ContentPacks could use. They are experimental and will likely not exist in future versions, but were intended to be like facts. In normal uses of puppet facts can be trusted, but during OCCP setup, may not be correct at certain points. For example, the hostname fact. If specified in the Scenario File, it will not be set until phase 2. So the Administrative VM would write the $OCCP_hostname variable which could be used and trusted at any point in the setup. It is important to note that one could just use Variables in their Scenario File and then pass the variable to the ContentPacks as a parameter.

Variables from the XML:

    OCCP_hostname
    OCCP_domain
    OCCP_fqdn
    OCCP_numberOfInterfaces
    OCCP_InterfaceNames[]
    OCCP_InterfaceIPv4s[]

Advanced Content Packs

Generally speaking it is best to break up larger content packs in to smaller ones, but in some situations that is not appropriate. Take for example a content pack that wants to install a web application which requires a database component. Instead of making one pack to install the web application and another to install the web application's specific database information, it would be best to contain this in one pack. However it might be possible to have separable configurations. Designing the content pack such that the web application was one class and the database portion was another, would provide greater flexibility. For example one could just specify the content pack which would then use the main class. That main class would include the other classes and the one machine would be configured as expected. But one could instead specify the individual classes separately on individual machines with some additional parameters. As a result they could deploy the web application and database across several machines.