Category: OpenStack

Welcome back, here we will continue with the second part of my post, where we will work with Red Hat Cloudforms. If you remember, in our first post we spoke about Red Hat OpenStack Platform 11 (RHOSP). In addition to the blog article, at the end of this article is also a demo video I created to show to our customers/partners how they can build a fully automated software data center.

In this blog, I would like to show you how you can create your fully software-defined data center with two amazing Red Hat products: Red Hat OpenStack Platform and Red Hat CloudForms. Because of the length of this article, I have broken this down into two parts.

As you probably know, every organization needs to evolve itself becoming a Tech Company, leveraging its own Digital Transformation, embracing or enhancing existing processes, evolving people’s mindset, people’s soft/hard skills and of course using new technologies.

Remember we are living in a digital era where if you don’t change yourself and your organization someone will disrupt your business!

So, how can I become disruptive in my business?

Well, speaking from a purely technical perspective a good approach should consider cloud technologies.

These kinds of technologies can be the first brick of your digital transformation strategy because they can grant business and technologies values.

Overview

In an environment where OpenStack instances are automatically subscribed to Satellite, it is important that Satellite is notified of terminated instances so that is can safely delete its host record. Not doing so will:

Exhaust the available subscriptions, leading to unsubscribed hosts not being able to apply updates and security errata.

In the event that an emergency security errata needs to be deployed across the organization, Satellite administrators would be unable to determine if a host was either off or terminated, leading to uncertainty with their security posture.

In smaller environments, where one team is responsible for both OSP and Satellite, it’s possible to have one system administrator do this by using their administrator level access across both systems to determine which host records can be safely deleted in Satellite when the corresponding instance no longer exists.

This post describes how to manually integrate Red Hat OpenStack 9 (RHOSP9) Cinder service with multiple pre-existing external Red Hat Ceph Storage 2 (RHCS2) clusters. The final configuration goals are to have Cinder configuration with multiple storage backends and support for creating volumes in either backend.

This post will not cover the initial deployment of OpenStack Cinder or the Ceph clusters.

Open vSwitch (OVS) is a virtual switch used in production from small to large scale deployments. It is designed to provide network automation along with support for a number of management interfaces and protocols.

However, the developer or the administrator might need to understand more of what is going on under the hoods and OVS does a good job providing a very good logging facility which is the subject of this article.

The last 4-5 years have seen the debut of many new software products specifically targeting both infrastructure services and IT automation. The consumerization of IT has caused its architects to take a fresh look at their existing, often times monolithic apps and IT infrastructure and asking: Can we do better? How do I keep IT relevant? How do I keep track of all these VMs and data? How do I scale out my IT environment without a huge budget increase or physical buildout? How do I develop and get bits to production faster and with higher quality?

These organizations are looking to evolve their development and deployment processes to be more agile and accelerate time-to-market. They are trying to embrace things like DevOps and Continuous Deployment to do that. They are breaking monolithic apps out into microservices that can be independently updated, with a focus on speed and agility, so their apps can be more reactive to changes in their business. They are evolving from traditional virtualization to public and private cloud deployments.

In the current world of DevOps, Continuous Delivery, Microservices, and PaaS many organizations want to know how Software Governance practices and requirements fit. Some of this comes from a regulatory perspective, ensuring compliance (e.g HIPAA/PHI, SOX, PCI) and auditing requirements are met. Another perspective focuses on existing technology standards, design practices, and application architecture. At the same time developers and teams are being told to be more agile, adaptable, and self-directed. How do we achieve the latter while mitigating the risks associated with the former?

I would argue that a “Descriptive” approach to Software Governance is required. In my perfect world, Solution Architectures are monitored for exception as they progress through the delivery process. The technical underpinnings of systems, in terms of infrastructure and software, are “described” in code and configuration that can be easily audited against established policies. The runtime implementation of a particular solution is then transparent to all interested parties. In many ways, this is just an extension of Open Source practices to the delivered solutions and systems themselves.