Jun 18 2013
Leave a comment
Automation

CloudForms and The Foreman Demonstration

The Foreman is a complete lifecycle management tool for physical and virtual servers. In other words, all that DHCP/DNS/Configuration Management/etc that is required by an operating system to function properly – The Foreman handles it, and handles it well. It also has an architecture which utilizes Smart-Proxies – which provides a restful API to underlying subsystems for distributed environments. While The Foreman understands some concepts within infrastructure management it is primarily focused on virtual and physical machine provisioning and management and managing the operating systems contained within those machines once they are deployed. Provisioning and configuration management are two areas that are very important to enterprise customers as it reduces the cost of operating while simultaneously reducing risk, specifically in the dynamic world of cloud computing.

The combination of provisioning and configuration management The Foreman provides is compelling, because it uses standard technologies that have existed for years and provides robust federation of those technologies. However, many IT organizations may already have a provisioning system or configuration management engine in place. Enterprises need a way of continuing to leverage their existing investment while planning their next generation IT architectures. CloudForms can assist with the adoption of The Foreman in existing IT architectures and also lays the groundwork for exciting new possibilities in streamlining application delivery across heterogeneous infrastructure.

CloudForms provides discovery, monitoring, eventing, control policies, chargeback, catalog based self-service – all of which are important. It also abstracts various provisioning methods for infrastructure and is not bound to a single configuration management system.

For this reason, and as you might suspect from the title of this post, it is only natural that CloudForms and The Foreman should compliment each other. Here are a few ways in which The Foreman and CloudForms can compliment each other.

  1. CloudForms can assist with the discovery and import of brown-field environments into The Foreman.
  2. CloudForms can allow users to leverage different provisioning systems while using The Foreman for configuration management.
  3. CloudForms can promote systems between environments (dev/test/prod) in The Foreman based on the data it contains or by integrating with external systems (ticketing, change control, capacity and utilization data).
  4. The Foreman can provide facts about systems to CloudForms for reporting and use in control policies, providing greater insight with less overhead.

These are just a few ideas, there are many more useful scenarios. One other scenario that may be possible soon – An application developer implements a change in a PaaS application and a change in a Virtual Machine (VM) within a IaaS provider in a development environment. Perhaps this developer needed to use a virtual machine running IIS which the PaaS doesn’t yet support.  The PaaS event (a source control check-in) and the drift detection provided by The Foreman can be correlated by CloudForms and a workflow can be initiated to re-provision the PaaS application and corresponding virtual machine to a continuous testing environment for analysis while taking into account cost, performance, and security requirements. The pieces are coming together to make this scenario a reality.

Here is a quick demonstration of how these two systems can work together. High-Res Quicktime Format

One final note: Since The Foreman will be included in a future version of Red Hat Satellite, it is likely that the integration between CloudForms and The Foreman will only improve over time.

Apr 29 2013
Leave a comment
As A Service, Automation

Auto Scaling OpenShift Enterprise Infrastructure with CloudForms Management Engine

OpenShift Enterprise, Red Hat’s Platform as a Service (PaaS), handles the management of application stacks so developers can focus on writing code. The result is faster delivery of services to organizations. OpenShift Enterprise runs on infrastructure, and that infrastructure needs to be both provisioned and managed. While provisioning OpenShift Enterprise is relatively straightforward, managing the lifecycle of the OpenShift Enterprise deployment requires the same considerations as other enterprise applications such as updates and configuration management. Moreover, while OpenShift Enterprise can scale applications running within the PaaS based on demand the OpenShift Enterprise infrastructure itself is static and unaware of the underlying infrastructure. This is by design, as the mission of the PaaS is to automate the management of application stacks and it would limit flexibility to tightly couple the PaaS with the compute resources at both the physical and virtual layer. While this architectural decision is justified given the wide array of computing platforms that OpenShift Enterprise can be deployed upon (any that Red Hat Enterprise Linux can run upon) many organizations would like to not only dynamically scale their applications running in the PaaS, but dynamically scale the infrastructure supporting the PaaS itself. Organizations that are interested in scaling infrastructure in support of OpenShift Enterprise need not look further then CloudForms, Red Hat’s Open Hybrid Cloud Management Framework. CloudForms provides the capabilities to provision, manage, and scale OpenShift Enterprise’s infrastructure automatically based on policy.

For reference, the two previous posts I authored covered deploying the OpenShift Enterprise Infrastructure via CloudForms and deploying OpenShift Enterprise Applications (along with IaaS elements such as Virtual Machines) via CloudForms. Below are two screenshots of what this looks like for background.

image01

Operations User Deploying OpenShift Enterprise Infrastructure via CloudForms

image02

Self-Service User Deploying OpenShift Application via CloudForms

Let’s examine how these two automations can be combined to provide auto scaling of infrastructure to meet the demands of a PaaS. Today, most IT organizations monitor applications and respond to notifications after the event has already taken place – particularly when it comes to demand upon a particular application or service. There are a number of reasons for this approach, one of which is a result of the historical “build to spec” systems that existed in historical and currently designed application architectures. As organizations transition to developing new applications on a PaaS, however, they are presented with an opportunity to reevaluate the static and often oversubscribed nature of their IT infrastructure. In short, while applications designed in the past were not [often] built to scale dynamically based on demand, the majority of new applications are, and this trend is accelerating. Inline with this accelerating trend the infrastructure underlying these new expectations must support this new requirement or much of the business value of dynamic scalability will not be realized. You could say that an organizations dynamic scalability is bounded by their least scalable layer. This also holds true for organizations that intend to run solely on a public cloud and will leverage any resources at the IaaS layer.

Here is an example of how scalability of a PaaS would currently be handled in many IT organizations.

diagram03

The operations user is alerted by a monitoring tool that the PaaS has run out of capacity to host new or scale existing applications.

diagram04

The operations user utilizes the IaaS manager to provision new resources (Virtual Machines) for the PaaS.

diagram05

The operations user manually configures the new resources for consumption by the PaaS.

Utilizing CloudForms to deploy manage, and automatically scale OpenShift Enterprise alleviates the risk of manual configuration from the operations user while dynamically reclaiming unused capacity within the infrastructure. It also reduces the cost and complexity of maintaining a separate monitoring solution and IaaS manager. This translates to lower costs, greater uptime, and the ability to serve more end users. Here is how the process changes.

diagram06

By notification from the PaaS platform or in monitoring the infrastructure for specific conditions CloudForms detects that the PaaS Infrastructure is reaching its capacity. Thresholds can be defined by a wide array of metrics already available within CloudForms, such as aggregate memory utilized, disk usage, or CPU utilization.

diagram07

CloudForms examines conditions defined by the organization to determine whether or not the PaaS should receive more resources. In this case, it allows the PaaS to have more resources and provisions a new virtual machine to act as an OpenShift Node. At this point CloudForms could require approval of the scaling event before moving forward. The operations user or a third party system can receive an alert or event, but this is informational and not a request for the admin to perform any manual actions.

diagram08

Upon deploying the new virtual machine CloudForms configures it appropriately. This could mean installing the VM from a provisioning system or utilizing a pre-defined template and registering it to a configuration management system such as one based on puppet or chef that configure the system.

Want to see  a prototype in action? Check out the screencast I’ve recorded.

This same problem (the ability to dynamically scale a platform) exists between the IaaS and physical layer. If the IaaS layer runs out of resources it is often not aware of the physical resources available for it to consume. This problem is not found in a large number of organizations because dynamically re-purposing physical hardware has a smaller and perhaps more specialized set of use cases (think HPC, grid, deterministic workloads). Even though this is the case it should be noted that CloudForms is able to provide a similar level of policy based automation to physical hardware to extend the capacity of the IaaS layer if required.

Apr 01 2013
1 Comment
Uncategorized

Hybrid Service Models: IaaS and PaaS Self-Service Converge

More and more organizations are beginning to embrace both Infrastructure as a Service (IaaS) and Platform as a Service (PaaS).  These organizations  have already begun asking why PaaS and IaaS management facilities must use different management frameworks. It only seems natural that IT organization’s customers should be able to select both IaaS and PaaS elements during their self-service workflow. Likewise, operations teams within IT organizations prefer to be able to utilize the same methods of policy, control, and automation across both IaaS and PaaS elements. In doing so operations teams could optimize workload placement both inside and outside their datacenter and reduce duplication of effort. This isn’t just a realization that customers are coming to – analysts have also been talking about the convergence of IaaS and PaaS as a natural evolutionary step in cloud computing.

Converged IaaS and PaaS

Converged IaaS and PaaS

This convergence of IaaS and PaaS is something I referred to as a Hybrid Service Model in a previous post, but you may often hear it refereed to as Converged IaaS and PaaS. There are many detriments an IT organization that does not embrace the convergence of IaaS and PaaS will face. Some of the more notable detriments include the following.

  • Developers: Slower delivery of services
    • Developers accessing two self-service portals in which the portals do not have knowledge of each others capabilities leads to slower development and greater risk of human error due to less automated processes on workload provisioning and management.
  • Operations: Less efficient use of resources
    • Operations teams managing IaaS and PaaS with two management facilities will be unable to maximize utilization of resources.
  • Management: Loss of business value
    • IT managers will be unable to capitalize efficiently without an understanding of both IaaS and PaaS models.

For these reasons and many more, it’s imperative that organizations make decisions today that will lead them to the realization of a Hybrid Service Model. There are two approaches emerging in the industry to realizing a Hybrid Service Model. The first approach is to build a completely closed or semi-open solution to allowing for a Hybrid Service Model. A good example would be a vendor offering a PaaS as long as it runs on top of a single virtualization provider (conveniently sold by them). The second approach is one in which a technology company utilizes an approach based on the tenants of an Open Hybrid Cloud to provide a fully open solution to enabling a Hybrid Service Model. I won’t go into all the reasons the second approach is better – you can read about that more here and here – but I will mention that Red Hat is committed to the Open Hybrid Cloud approach to enabling a Hybrid Service Model.

With all the background information out of the way I’d like to show you a glimpse of what will be possible due to the Open Hybrid Cloud approach at Red Hat. Red Hat is building the foundation to offer customers Hybrid Service Models alongside Hybrid Deployment Scenarios. This is possible for many reasons, but in this scenario it is primarily because of the open APIs available in OpenShift, Red Hat’s PaaS and because of the extensibility of CloudForms, Red Hat’s Hybrid Cloud Management solution. The next release of CloudForms will include a Management Engine component, based on the acquisition of ManageIQ EVM that occurred in December. Using the CloudForms Management Engine it is possible to provide self-service of applications in a PaaS along with self-service of infrastructure in IaaS from a single catalog. Here is what a possible workflow would look like.

Higher resolution viewing in quicktime format here.

Mar 20 2013
1 Comment
As A Service, Automation

Self-Service OpenShift Enterprise Deployments with ManageIQ ECM

In the previous post I examined how Red Hat Network (RHN) Satellite could be integrated with ManageIQ Enterprise Cloud Management (ECM). With this integration in place Satellite could provide ECM with the content required to install an operating system into a virtual machine and close the loop in ongoing systems management. This was just a first look and there is a lot of work to be done to enable discovery of RHN Satellite and best practice automation out of the box via ECM. That said, the combination of ECM and RHN Satellite provide a solid foundation for proceeding to use cases higher in the stack.

With this in mind, I decided to attempt automating a self-service deployment of OpenShift using ManageIQ ECM, RHN Satellite, and puppet.

Lucky for me, much of the heavy lifting had already been done by Krishna Raman and others who developed puppet modules for installing OpenShift Origin. There were several hurdles that had to be overcome with the existing puppet modules for my use case:

  1. They were built for Fedora and OpenShift Origin and I am using RHEL6 with OpenShift Enterprise. Because of this they defaulted to using newer rubygems that weren’t available in openshift enterprise yet. It took a little time to reverse engineer the puppet modules to understand exactly what they were doing and tweak them for OpenShift Enterprise.
  2. The OpenShift Origin puppet module leveraged some other puppet modules (stdlib, for example), so the puppet module tool (PMT) was needed which is not available in core puppet until > 2.7. Of course, the only version of puppet available in EPEL for RHEL 6 was puppet-2.6. I pulled an internal build of puppet-2.7 to get around this, but still required some packages from EPEL to solve dependencies.

Other then that, I was able to reuse much of what already existed and deploy OpenShift Enterprise via ManageIQ ECM. How does it work? Very similar to the Satellite use case, but with the added step of deploying puppet and a puppet master onto the deployed virtual machine and executing the puppet modules.

workflow

Workflow of OpenShift Enterprise deployment via ECM

If you are curious how the puppet modules work, here is a diagram that illustrates the flow of the openshift puppet module.

Anatomy of OpenShift Puppet Module

Anatomy of OpenShift Puppet Module

Here is a screencast of the self-service deployment in action.

There are a lot of areas that can be improved in the future. Here are four which were top of mind after this exercise.

First, runtime parameters should be able to be passed to the deployment of virtual machines. These parameters should ultimately be part of a service that could be composed into a deployment. One idea would be to expose puppet classes as services that could be added to a deployment. For example, layering a service of openshift_broker onto a virtual machine would instantiate the openshift_broker class on that machine upon deployment. The parameters required for openshift_broker would then be exposed to the user if they would like to customize them.

Second, gears within OpenShift – the execution area for applications – should be able to be monitored from ECM much like Virtual Machines are today. The oo-stats package provides some insight into what is running in an OpenShift environment, but more granular details could be exposed in the future. Statistics such as I/O, throughput, sessions, and more would allow ECM to further manage OpenShift in enterprise deployments and in highly dynamic environments or where elasticity of the PaaS substrate itself is a design requirement.

Third, building an upstream library of automation actions for ManageIQ ECM so that these exercises could be saved and reused in the future would be valuable. While I only focused on a simple VM deployment in this scenario, in the future I plan to use ECM’s tagging and Event, Condition, Action construct to register Brokers and Nodes to a central puppet master (possibly via Foreman). The thought is that once automatically tagged by ECM with a “Broker” or “Node” tag an action could be taken by ECM to register the systems to the puppet master which would then configure the system appropriately. All those automation actions are exportable, but no central library exists for these at the current time to promote sharing.

Fourth, and possibly most exciting, would be the ability to request applications from OpenShift via ECM alongside requests for virtual machines. This ability would lead to the realization of a hybrid service model. As far as I’m aware, this is not provided by any other vendor in the industry. Many of the analysts are coming around to the fact that the line between IaaS and PaaS will soon be gray. Driving the ability to select an application that is PaaS friendly (python for example) and traditional infrastructure components (a relational database for example) from a single catalog would provide a simplified user experience and create new opportunities for operations to drive even higher utilization at lower costs.

I hope you found this information useful. As always, if you have feedback, please leave a comment!

Feb 27 2013
Leave a comment
As A Service, Automation, Virtualization

Using RHN Satellite with ManageIQ ECM

Many organizations use Red Hat Network (RHN) Satellite to manage their Red Hat Enterprise Linux systems. RHN Satellite has a long and successful history of providing update, configuration, and subscription management for RHEL in the physical and virtualized datacenter. As these organizations move to a cloud model, they require other functions in addition to systems management. Capabilities such as discovery, chargeback, compliance, monitoring, and policy enforcement are important aspects of cloud models. ManageIQ’s Enterprise Cloud Management, recently acquired by Red Hat, provides these capabilities to customers.

One of the benefits of an Open Hybrid Cloud is that organizations can leverage their existing investments and gain the benefits of cloud across them. How then, could organizations gain the benefits of cloud computing while leveraging their existing investment in systems management? In this post, I’ll examine how Red Hat Network Satellite can be utilized with ManageIQ ECM to demonstrate the evolutionary approach that an Open Hybrid Cloud provides.

Here is an overview of the workflow.

RHN Satellite and ManageIQ ECM Workflow

RHN Satellite and ManageIQ ECM Workflow

  1. The operations user needs to transfer the kickstart files into customization templates in ManageIQ ECM. This is literally copying and pasting the kickstart files. It’s important to change the “reboot” option to “poweroff” in the kickstart file. If this is isn’t done, the VM will be rebooted and continually loop into an installation via PXE. Also, in the %post section of the kickstart you need to include “wget –no-check-certificate <%= evm[:callback_url_on_post_install] %>”. This will allow ECM to understand that the system has finished building and boot the VM after it has shutoff.
  2. The user requests virtual machine(s) from ECM.
  3. ECM creates an entry in the PXE environment and creates a new virtual machine from the template selected by the user.
  4. The virtual machine boots from the network and the PXE server loads the appropriate kickstart file.
  5. The virtual machine’s operating system is installed from the content in RHN Satellite.
  6. The virtual machine is registered to RHN Satellite for ongoing management.
  7. The user (or operations users) can now manage the operating system via RHN Satellite.

Here is a screencast of this workflow in action.

There are a lot of areas that can be improved upon.

  1. Utilize the RHN Satellite XMLRPC API to delete the system from RHN Satellite.
  2. Allow for automatic discovery of kickstarts in RHN Satellite from ECM.
  3. Unify the hostnames deployed to RHEVM with their matching DNS entries, so they appear the same in RHN Satellite.
Feb 23 2013
1 Comment
Automation, Virtualization

Automating a training environment for ManageIQ ECM [part 1]

I didn’t think it was possible, but since the acquisition of ManageIQ things have gotten even busier. There are a lot of people working around the clock to ensure a high quality delivery of product and deliver new capabilities throughout our portfolio. It’s really exciting to see such a comprehensive portfolio being brought together by all of the teams at Red Hat and I believe customers will be pleasantly surprised in the near future.

I’ve recently begun to work on a plan to train our field engineers on Enterprise Cloud Management (ECM). One of my goals as part of the training was to be able to quickly build up an entire classroom environment for at least 20 students. Quickly being minutes, not days. One of the great things about ECM is that is delivered as an appliance. This makes for an easy deployment. I wanted to avoid all the clicking through the Web Admin interface to deploy 20 virtual machines from a template. I also wanted the names of the virtual machines in the RHEV-M console to match the hostnames in DNS they would receive.

For this reason I wrote a quick ruby script, named automate_build.rb. I tried to keep it as generic as possible with all environment specific variables referenced in the first few lines so others could reuse it. The script assumes you’ve already imported the OVF and have a template available to base the VMs from. The script does several things including:

  1. Accepts user input for the cluster they’d like to create the VMs on
  2. Accepts user input for the template name they’d like to use as a basis for the VMs
  3. Accepts user input for the number of VMs they’d like to build
  4. Proceeds to build the VMs based on the input from above
  5. Writes a file that can be included in the dhcp.conf containing the correct static entries using the MAC addresses of the VMs that were built in the previous step

This means that with a few pieces of input one could deploy many virtual machines from a template and have the VM names match DNS entries based on static entries.

For the sake of completeness I will also create an automated teardown script named automate_destroy.rb. For now this functionality could just as easily be achieved by shift+clicking a group of virtual machines in the Web Administration console of RHEV-M and removing them. In the future I may attempt to use the build and destroy scripts to perform more advanced lab setup, so having a scripted removal process may prove more useful. Some lab scenarios that might be useful to students in the future could include:

  • Identifying which virtual machines are causing high resource utilization on a host
  • Performing capacity analysis for a cluster
  • Comparing virtual machines for differences

With this framework in place I could easily add scenarios to be built into the automate_build.rb and automate_destroy.rb scripts and have a lab ready quickly. Here is a quick screencast showing the script in action.

I hope to be able to share more with you in the future on this training environment and I hope you find the scripts useful!

Feb 05 2013
Leave a comment
Uncategorized

Automating OpenStack deployments with Packstack

If you’d like a method to consistently deploy OpenStack in an automated fashion I’d recommend checking out packstack – an Openstack installation automation tool which utilizes puppet.

[root@rhc-05 ~]# packstack
Welcome to Installer setup utility
Should Packstack install Glance image service [y|n]  [y] : 
Should Packstack install Cinder volume service [y|n]  [y] : 
Should Packstack install Nova compute service [y|n]  [y] : 
Should Packstack install Horizon dashboard [y|n]  [y] : 
Should Packstack install Swift object storage [y|n]  [n] : y
Should Packstack install Openstack client tools [y|n]  [y] : 
Enter list of NTP server(s). Leave plain if packstack should not install ntpd on instances.: ns1.bos.redhat.com
Enter the path to your ssh Public key to install on servers  [/root/.ssh/id_rsa.pub] : 
Enter the IP address of the MySQL server  [10.16.46.104] : 
Enter the password for the MySQL admin user :
Enter the IP address of the QPID service  [10.16.46.104] : 
Enter the IP address of the Keystone server  [10.16.46.104] : 
Enter the IP address of the Glance server  [10.16.46.104] : 
Enter the IP address of the Cinder server  [10.16.46.104] : 
Enter the IP address of the Nova API service  [10.16.46.104] : 
Enter the IP address of the Nova Cert service  [10.16.46.104] : 
Enter the IP address of the Nova VNC proxy  [10.16.46.104] : 
Enter a comma separated list of IP addresses on which to install the Nova Compute services  [10.16.46.104] : 10.16.46.104, 10.16.46.106
Enter the Private interface for Flat DHCP on the Nova compute servers  [eth1] : 
Enter the IP address of the Nova Network service  [10.16.46.104] : 
Enter the Public interface on the Nova network server  [eth0] : 
Enter the Private interface for Flat DHCP on the Nova network server  [eth1] : 
Enter the IP Range for Flat DHCP  [192.168.32.0/22] : 
Enter the IP Range for Floating IP's  [10.3.4.0/22] : 
Enter the IP address of the Nova Scheduler service  [10.16.46.104] : 
Enter the IP address of the client server  [10.16.46.104] : 
Enter the IP address of the Horizon server  [10.16.46.104] : 
Enter the IP address of the Swift proxy service  [10.16.46.104] : 
Enter the Swift Storage servers e.g. host/dev,host/dev  [10.16.46.104] : 
Enter the number of swift storage zones, MUST be no bigger than the number of storage devices configured  [1] : 
Enter the number of swift storage replicas, MUST be no bigger than the number of storage zones configured  [1] : 
Enter FileSystem type for storage nodes [xfs|ext4]  [ext4] : 
Should packstack install EPEL on each server [y|n]  [n] : 
Enter a comma separated list of URLs to any additional yum repositories to install:    
To subscribe each server to Red Hat enter a username here: james.labocki
To subscribe each server to Red Hat enter your password here :

Installer will be installed using the following configuration:
==============================================================
os-glance-install:             y
os-cinder-install:             y
os-nova-install:               y
os-horizon-install:            y
os-swift-install:              y
os-client-install:             y
ntp-severs:                    ns1.bos.redhat.com
ssh-public-key:                /root/.ssh/id_rsa.pub
mysql-host:                    10.16.46.104
mysql-pw:                      ********
qpid-host:                     10.16.46.104
keystone-host:                 10.16.46.104
glance-host:                   10.16.46.104
cinder-host:                   10.16.46.104
novaapi-host:                  10.16.46.104
novacert-host:                 10.16.46.104
novavncproxy-hosts:            10.16.46.104
novacompute-hosts:             10.16.46.104, 10.16.46.106
novacompute-privif:            eth1
novanetwork-host:              10.16.46.104
novanetwork-pubif:             eth0
novanetwork-privif:            eth1
novanetwork-fixed-range:       192.168.32.0/22
novanetwork-floating-range:    10.3.4.0/22
novasched-host:                10.16.46.104
osclient-host:                 10.16.46.104
os-horizon-host:               10.16.46.104
os-swift-proxy:                10.16.46.104
os-swift-storage:              10.16.46.104
os-swift-storage-zones:        1
os-swift-storage-replicas:     1
os-swift-storage-fstype:       ext4
use-epel:                      n
additional-repo:               
rh-username:                   james.labocki
rh-password:                   ********
Proceed with the configuration listed above? (yes|no): yes

Installing:
Clean Up...                                              [ DONE ]
OS support check...                                      [ DONE ]
Running Pre install scripts...                           [ DONE ]
Installing time synchronization via NTP...               [ DONE ]
Setting Up ssh keys...                                   [ DONE ]
Create MySQL Manifest...                                 [ DONE ]
Creating QPID Manifest...                                [ DONE ]
Creating Keystone Manifest...                            [ DONE ]
Adding Glance Keystone Manifest entries...               [ DONE ]
Creating Galnce Manifest...                              [ DONE ]
Adding Cinder Keystone Manifest entries...               [ DONE ]
Checking if the Cinder server has a cinder-volumes vg... [ DONE ]
Creating Cinder Manifest...                              [ DONE ]
Adding Nova API Manifest entries...                      [ DONE ]
Adding Nova Keystone Manifest entries...                 [ DONE ]
Adding Nova Cert Manifest entries...                     [ DONE ]
Adding Nova Compute Manifest entries...                  [ DONE ]
Adding Nova Network Manifest entries...                  [ DONE ]
Adding Nova Scheduler Manifest entries...                [ DONE ]
Adding Nova VNC Proxy Manifest entries...                [ DONE ]
Adding Nova Common Manifest entries...                   [ DONE ]
Creating OS Client Manifest...                           [ DONE ]
Creating OS Horizon Manifest...                          [ DONE ]
Preparing Servers...                                     [ DONE ]
Running Post install scripts...                          [ DONE ]
Installing Puppet...                                     [ DONE ]
Copying Puppet modules/manifests...                      [ DONE ]
Applying Puppet manifests...
Applying /var/tmp/packstack/20130205-0955/manifests/10.16.46.104_prescript.pp
Testing if puppet apply is finished : 10.16.46.104_prescript.pp OK
Testing if puppet apply is finished : 10.16.46.104_mysql.pp OK
Testing if puppet apply is finished : 10.16.46.104_qpid.pp OK
Applying /var/tmp/packstack/20130205-0955/manifests/10.16.46.104_keystone.pp
Applying /var/tmp/packstack/20130205-0955/manifests/10.16.46.104_glance.pp
Applying /var/tmp/packstack/20130205-0955/manifests/10.16.46.104_cinder.pp
Testing if puppet apply is finished : 10.16.46.104_keystone.pp OK
Testing if puppet apply is finished : 10.16.46.104_cinder.pp OK
Testing if puppet apply is finished : 10.16.46.104_glance.pp OK
Applying /var/tmp/packstack/20130205-0955/manifests/10.16.46.104_api_nova.pp
Testing if puppet apply is finished : 10.16.46.104_api_nova.pp OK
Applying /var/tmp/packstack/20130205-0955/manifests/10.16.46.104_nova.pp
Applying /var/tmp/packstack/20130205-0955/manifests/10.16.46.104_osclient.pp
Applying /var/tmp/packstack/20130205-0955/manifests/10.16.46.104_horizon.pp
Testing if puppet apply is finished : 10.16.46.104_nova.pp OK
Testing if puppet apply is finished : 10.16.46.104_osclient.pp OK
Testing if puppet apply is finished : 10.16.46.104_horizon.pp OK
Applying /var/tmp/packstack/20130205-0955/manifests/10.16.46.104_postscript.pp
Testing if puppet apply is finished : 10.16.46.104_postscript.pp
Testing if puppet apply is finished : 10.16.46.104_postscript.pp OK
                            [ DONE ]

 **** Installation completed successfully ******

     (Please allow Installer a few moments to start up.....)

Additional information:
 * Time synchronization installation was skipped. Please note that unsynchronized time on server instances might be problem for some OpenStack components.
 * To use the command line tools source the file /root/keystonerc_admin created on 10.16.46.104
 * To use the console, browse to http://10.16.46.104/dashboard
 * The installation log file is available at: /var/tmp/packstack/20130205-0955/openstack-setup.log

You can also generate an answer file and use it on other systems

[root@rhc-06 ~]# packstack --gen-answer-file=answerfile

Be careful, if your system is subscribed to Red Hat Network’s classic entitlement packstack will register the systems via subscription-manager (certificate based entitlement). This can cause some issues if you already subscribed the system and added the OpenStack  channels via RHN.

← Older posts
Follow

Get every new post delivered to your Inbox.

Join 550 other followers