DevOps requires that everything goes into Revision Control. CloudForms’ modifications are no exception. But how do you revision control something that is managed by a GUI and stored in a database? Import and export with the command line. Here’s how.

To get code into and out of CloudForms, you use rake.  A version of version of rake is provided with the appliance.

This requires a rakefile, and to get access to the default one distributed with the appliance, run

cd /var/www/miq/vmdb

I’m using /tmp/cfme as my import and export directory, and the domain is younglogic. Adjust your commands appropriately.

To export code from the appliance to a directory, use the following command:

 /var/www/miq/vmdb/bin/rake evm:automate:export DOMAIN=younglogic EXPORT_DIR=/tmp/cfme OVERWRITE=true

To import code into the CloudForms server, run:

/var/www/miq/vmdb/bin/rake evm:automate:import DOMAIN=younglogic IMPORT_DIR=/tmp/cfme SYSTEM=false ENABLED=true PREVIEW=false OVERWRITE=true

The OVERWRITE parameter is essential:  if you do not include it, you will not see changes in the destination.  It is a a little tricky;  without OVERWRITE explicitly set, either command will work the first time, when there is no code in CloudForms for import or if the target directory is empty for export.

The PREVIEW=false is also essential: The PREVIEW option is used for doing a test run. If PREVIEW is set to true, no changes will be written.

There are a few points to consider when using this for your workflow.

1. File permissions.  If you run export as root, you will create the target directory as the root user.  This is not usually the preferred account.  However, on the appliance, the root directory /var/www/miq/vmdb and all its children are owned by root:root.  A better approach would allow this code to be run as a non-root user based on group membership.  Locking down sudo for the user such that they can only run /var/www/miq/vmdb/bin/rake might be an acceptable mitigating approach as well.
2. Running this on a production server.  it might make sense to have a single CFME instance that has almost all roles removed except for those required to import and export code in order to constrain where the import process can be run.
3. This is not the git repositories owner role.  That is explicitly for managing access to Ansible playbooks.
4. There is no guarantee that old files will be removed. If you are concerned about old artifacts, you should delete the domain on the server prior to import. This may not be a real concern; It is always possible to delete spurious items post import, too. I’ll update this as I learn more.

With those things in mind, we should be able to build a workflow for Continuous Integration and Deployment of code to our Cloud Forms instances.