on 01-27-2014 02:32 PM
The Configuration Management Cloud Accelerator Kit v4.0 for Cisco Intelligent Automation for Cloud includes:
The kit is an extension to Cisco Intelligent Automation for Cloud 4.0 and offers:
Please note that as a cloud accelerator, the configuration management content will continue to evolve over time and may include integrations with other configuration technologies. We welcome comments and suggestions and will do our best to respond and update as appropriate.
With regard to support, the first point of contact should be the author and/or this community. If you are having issues, moderators of this forum will determine and advise if a TAC case is appropriate, otherwise issues will be addressed here.
CMAK 4.0 (VERSION 2) has been updated to work with IAC 4.0 Patch 1. FQDN is also now stored in the Virtual Server and Server Configuration service items.
Can this property be a Hidden String:
Puppet.Target.Bootstrap.Linux.Password
Also, I assume the Target Type is a Web Target (it shows under the Custom tab for Puppet Web Target)
That property is no longer part of CMAK 4.0. It is now called ConfigurationManagement.BootStrap.Linux.Password and it is a hidden string. It is not meant to be a secure password, only a seed password that gets changed during the config process. This is only for situations where IAC does not set a password (like Linux on vCenter) so we need some password to initially connect to the server to install Puppet/Chef. The password would be a common, well known password that is the same across templates; hence, not secure and gets changed to a "real" password during provisioning.
The new property is associated with the Configuration Management target type in CMAK 4.0 (there are new Chef and Puppet target types).
Hi Derek,
I'm not a puppet expert but I have a prospect for whom it is a key success factor. He asks me if we support puppetdb instead of hiera?
Do you have tips / pointers on how I could setup quickly a puppet environment in my lab to try to demonstrate?
Thanks for your help!
Damien, I'll need a little clarification on what the customer is looking to do. Currently, we use hiera for node classification and for providing class parameter overrides. I am working on an enhancement right now to provide a mechanism as alternative/addition to class parameter overrides that uses "external facts" to provide additional data about a node. This data is available to the node itself, and after a puppet agent run, is also published to puppetdb. The intention is that this data would be used by dalen-puppetdbquery (puppet module install dalen-puppetdbquery) so that nodes could query custom facts about other nodes. The enhancement will be available in the next version of CMAK, due out next out.
If the customer is trying to use puppetdb for external node classification (ENC), this is something we would need to explore further. The solution is flexible enough to allow any customer ENC (easily configured in puppet.conf). As an accelerator, the content can be modified or extended as necessary, but I'd like to understand if this will be a common requirement that we might want to build into the kit itself.
As far as setting up your own environment, it's pretty straightforward. Download the Puppet Enterprise all-in-one installer, which let's you manage up to 10 nodes for free. This option is great for learning, demos and POCs. There is an OVA called the "Learning Puppet VM", but I would not recommend using that with CMAK (we've seen some problems doing that).
http://info.puppetlabs.com/download-pe.html
You will want choose the options to install both master and agent on the same machine, allowing you to start with some basic testing without actually spinning up other nodes to configure.
I recommend installing on CentOS 6 (or Ubuntu 12.04). It takes about 5-10 minutes. I have been providing a set of "demo" modules including sample roles, profiles and parameters on request to help get people started. Please reach out to me directly when you get to that point.
Changes for v3:
1. Updated for compatibility with IAC 4.0 Patch 2.
2. Fixed "CM Generate Server Hostname, which was causing non-VM from template orders to fail
3. Fixed display of validation errors in System Health portlet
4. Fixed issues validating connections for Chef and Puppet
5. Added Environment column to Manage Infrastructure portlet for Puppet Roles/Profiles.
6. Fixed problems in RequestCenter.war packaging (removed myServersLayer.jsp from package and bad reference to nsapi.jsp)
7. For Puppet,
Added new connection option to download puppet installer from a local repository
New facts are now available for each node: stack_instance, stack_role, and iac_organization. Can be used by puppetdbquery in puppet code to
get information about other nodes in a stack (requires module … see deployment guide)
Custom facts can be added to a node by specifying "fact" instead of a class parameter name in the json used to define profile parameters (see deployment guide)
8. For Chef, added stack_instance and iac_organization node attributes during bootstrapping. Can be used to search attributes of other nodes in a stack.
Changes for v4:
1. Updated for compatibility with IAC 4.0 Patch 3.
2. Added option to Puppet connection to configure an alternate module discovery path (to point to a working copy when puppet.conf module location is a git bare repo)
3. Added option to Puppet connection to configure an alternate hiera node classification file location, separate from the module path
4. Added option to Puppet connection to configure an alternate URL for Puppet installer. For example, the installer packages can be put on the puppet master to provide a local repository (but needs to be available via a URL (not a UNC path).
5. In the Puppet pre-bootstrapping extension point, custom data can be added to hiera node classification file
6. In the Puppet pre-bootstrapping extension point, a flag can be set to bypass puppet agent installation
7. Added additional fact for Puppet nodes, stack_role_name, which is the registered friendly name for the stack role(s). stack_role reflects the actual classname (without the "role::" namespace)
8. For Puppet CMAK can use PSExec instead of WinRM to run the Puppet agent if it is installed on the PO server and on the system path. Note that WinRM is still used for Puppet agent installation. This allows for an interactive desktop required by many installers that Puppet may be running.
9. Issue with chart data not displaying for Puppet and Chef in the Manage Infrastructure Discovery portlet has been resolved.
10. Added extension point prior to Puppet agent run, allowing override of the timeout value by setting "Timeout Override" or implementing a completely customized run of the Puppet agent. Output variables from the extension include "HasRun" and "CompletedSuccessfully" flags along "Output" of the agent run.
11. For Windows, the Puppet agent run is now asynchronous, allowing for an override of the timeout value for the PowerShell activity that runs the Puppet agent through WinRM or PSExec (see #10 above for the extension point that allows you to override the timeout value).
Changes for v5:
Updated for compatibility with IAC 4.0 Patch 4 (4.0.0.4) and PSC 10 R2 (with Patch 1h)
For Puppet, a retry loop was added to wait for the Puppet certificate authority to sign the new node's certificate
Note: The only PO automation packs that have changed since CMAK v4 are the ones for Puppet. You do not need to import the others if you have already deployed v4.
Change Log for Version 6 June 17, 2014
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: