OpenShift Operator SDK: Getting Started Guide



In this article we will introduce the concept of operators and provide a hands-on guide to building your very first operator. I will show you how to create a development environment with everything needed. Using the Operator SDK we will learn how to create boilerplate code, build and deploy an operator. A followup article is also planned that will go deeper into operator development so stay tuned!

Continue reading

Getting Started with Machine Learning




In this article we will dive into machine learning. We will begin by understanding the concept, then look at some of the use cases, requirements and finally explore a real world scenario using a demo application.  Machine learning has the potential to dramatically change our lives, jobs and influence decision making on a scale that has never been seen before. It is one of the most exciting and also scary technological advancements to ever come around. It is the future but is also happening right now which is why there couldn’t be a better time to get started than today.

Continue reading

OpenShift: Getting Started with the Service Broker



In this article we will look at the OpenShift service broker, understand how to integrate external services into OpenShift and even create a custom broker. First before we begin a big thanks to Marek Jelen and Paul Morie, Red Hatters who both helped me understand the service broker in greater detail.

Obviously if you are reading this article you already understand microservices, containers and why it is all so incredible awesome on OpenShift. Of course everything should be in a container but unfortunately it is going to take a while to get there. As we start dissecting and breaking down the monolithic architectures of the past, likely there will be a mix of lightweight services running in containers on OpenShift and other more heavy services (databases, ESBs, etc) running outside. In addition while the service catalog in OpenShift is vast, even allowing you to add your own custom services for anything that can run in OpenShift as-a-container using a template, there will be the need, especially with public cloud to connect to external services. Both of these use cases, on-premise external services and off-premise cloud services really made it obvious that a service broker and more robust service catalog was needed. Originally OpenShift did not have a service broker so you couldn’t easily consume external services. All that existed was the service catalog and templates, so every service had to be a container running on OpenShift. Thankfully other companies also saw a need for an open service abstraction and the Open Service Broker API was born as an opensource project.

Continue reading

Deploying OpenShift Enterprise from Ansible Tower

ansible-tower-logotype-large-rgb-fullgrey-300x124 plus_sign openshiftlogo


In this article we will look at how to use Ansible Tower to deploy and manage OpenShift environments. OpenShift of course uses Ansible as its deployment and configuration tool already. While that is great, using Tower provides several major advantages:

  • UI for OpenShift deployment and configuration management
  • Secure store for credentials
  • RBAC and ability to delegate different responsibilities for OpenShift deployments
  • Easy to visualize and manage multiple OpenShift environments and even versions of OpenShift
  • History, audit trail and detailed logging in central location for all OpenShift environments and deployments

Continue reading

OpenStack: Integrating Ceph as Storage Backend



In this article we will discuss why Ceph is Perfect fit for OpenStack. We will see how to integrate three prominent OpenStack use cases with Ceph: Cinder (block storage), Glance (images) and Nova (VM virtual disks).

Integrating Ceph with OpenStack Series:

Ceph provides unified scale-out storage, using commodity x86 hardware, that is self-healing and intelligently anticipates failures. It has become the defacto standard for software-defined storage. Ceph being an OpenSource project has enabled many vendors the ability to provide Ceph based software-defined storage systems. Ceph is not just limited to Companies like Red Hat, Suse, Mirantis, Ubuntu, etc. Integrated solutions from SanDisk, Fujitsu, HP, Dell, Samsung and many more exist today. There are even large-scale community built environments, Cern comes to mind, that provide storage services for 10,000s of VMs.

Continue reading

Ceph 1.3 Lab Installation and Configuration Guide



In this article we will setup a Ceph 1.3 cluster for purpose of learning or a lab environment.


Ceph Lab Environment

For this environment you will need three VMs (ceph1, ceph2 and ceph3). Each should have 20GB root disk and 100GB data disk. Ceph has three main components: Admin console, Monitors and OSDs.

Admin console – UI and CLI used for managing Ceph cluster. In this environment we will install on ceph1.

Monitors – Monitor health of Ceph cluster. One or more monitors forms a paxos part-time parliment, providing extreme reliability and durability of cluster membership. Monitors maintain the various maps: monitor, osd, placement group (pg) and crush. Monitors will be installed on ceph1, ceph2 and ceph3.

OSDs – Object storage daemon handles storing data, recovery, backfilling, rebalancing and replication. OSDs sit on top of a disk / filesystem. Bluestore enables OSDs to bypass filesystem but is not an option in Ceph 1.3. An OSD will be installed on ceph1, ceph2 and ceph3.

Continue reading

Ceph: the future of Storage



Since joining Red Hat in 2015, I have intentionally stayed away from the topic of storage. My background is storage but I wanted to do something else as storage became completely mundane and frankly boring. Why?

Storage hasn’t changed much in 20 years. I started my career as a Linux and Storage engineer in 2000 and everything that existed then, exists today. Only things became bigger, faster, cheaper, due to incremental improvements from technologies such as flash. There comes a point however, where minor incremental improvements are no longer good enough and a completely new way of addressing challenges is the only way forward.

I realized in late 2015 that the storage industry is starting a challenging period for all vendors but, didn’t really have feeling for when that could lead to real change. I did know that the monolithic storage array, built on proprietary Linux/Unix, with proprietary x86 hardware we all know and love, was a thing of the past. If you think about it storage is a scam today, you get opensource software running on x86 hardware packaged as a proprietary solution that doesn’t interoperate with anything else. So you get none of the value of opensource and pay extra for it. I like to think that economics like gravity, eventually always wins.

Continue reading