About OpenStack, including Mirantis OpenStack Training

Mirantis OpenStack Training

Crystal Echo offer vendor certification training in Mirantis OpenStack, which is the most vendor neutral OpenStack training you are likely to find across all distributions.  Sure, there will be specific Mirantis training courses designed to support Mirantis customers, however the entry level training if you are looking to operate, deploy and configure will certainly meet your needs.

OpenStack Summit, Sydney, 2017

Vanilla vs OpenStack Distributions – Update on Distinctions, Status, and Statistics

Presentation delivered by Danny Al-Gaaf at the first OpenStack Summit in Sydney on November 2017.

At some point you will have to choose an install of OpenStack for your organisation and will be quickly confronted with the question, do I go with opensource Vanilla or an OpenStack distribution?

Naturally it will depend on your use case, technical requirements, resources and organization. The presentation by Danny highlights the differences between these choices and between the distributions and their offerings.

Unfortunately, it is not as clear cut as you would like and further consideration to the OpenStack product itself such as the hypervisor platform, Ceph (unified distributed storage) base distributions and support. Additionally, new topics that weigh heavily into your decision are SDN, NFV, Container, Managed Cloud along with statistics on community contribution and market share that may influence your final decision.

The vendors who distribute OpenStack; Red Hat, SUSE, Mirantis and Ubuntu/Canonical are discussed in this presentation.

Define Vanilla OpenStack?

It’s taking upstream OpenStack without any private changes to deploy in your network.  It sounds great in theory, but when you start building an OpenStack cloud solution on Vanilla upstream you must know your environment and up your knowledge, so you can answer:

  • Which software do I need?
  • What storage solution do I have?
  • What base operating system do I need?

You will then consider other topics like which specific components of OpenStack you’ll need and what features such as CephFS, SDN Controller, Hypervisor/Container and API versions will be required.  Additionally, you will consider operational topics like Automation, CI/CD and your final platform management which means release cycles, updates, SLA’s and how your organisation will be equipped to support this.

The above will have significant bearing on the ongoing operational cost and skills required to build and manage the cloud environment from a technical perspective.  An example of skills required and needing to adapt would be your storage team that have been managing your NetApp environment for many years now need to be knowledgeable CEPH Engineers. This highlights there are going to be some big decisions along with many small but influential ones to make.  Your organisation will need to be flexible for the change it is about to encounter.

Management needs fully to support this transformation and not get in the way and possibly another area requiring change will be the to address legal requirements and obligations you’ll have for internal and external customers using this environment.

When you get your organisation working with a fully automated environment with your vanilla upstream-based cloud solution, you’ll need experienced operators and likely full-time developers.  If not, your project will likely fail. On the other hand, you proactively address that you’ll need to adapt many of your processes and change the mindset of your people.  Full support from management is paramount for the success of your OpenStack deployment.

Adding to the list, you’ll need think of problems you’ll encounter with your vanilla OpenStack deployment such as how to have a bug fixed or feature implemented.  You’ll need to find the time and participate in the community.  Even if you do or don’t have developers you’ll be able to report your bugs and missing features back to the community, write blueprints/scope documents and supporting documentation to support your test results.

There’ll be risk in resolving your vanilla OpenStack bugs and having features added.  It will heavily rely on your knowing the open source developers who will either be interested and quickly jump on your blueprint, or you’ll need to pay for someone’s time to program the changes.  You should be prepared to manage this process and perform the implementation yourself.

Looking deeper into some of the OpenStack components and major projects that are highly mature and widely adopted.

There are many differing projects that have not the same level of maturity. The below displays some projects that one or another way are all supported by the different OS OpenStack Distribution vendors.

The next item to consider is what level of Automation you’ll require from your OpenStack environment.  If you decide to write your own you are likely to invest a lot of time and money to ensure you don’t fail.  That being said, you will then be stuck with your Automation code and won’t benefit from what the community is doing.  So, an alternative is to go more with what’s found in the OpenStack the community which is primarily Ansible, Puppet, Chef and SaltStack with Juju found where people are using Canonical or Ubuntu. You are then locked in with Juju with 96% of the code coming from one company.

It’s not that you should not use Juji but be mindful of the implications of this decision for which there are many more like this to follow as you begin your OpenStack journey.  There are reported cases of customers running Juju on Red Hat.  Understand that the community code may not 100% fit your needs which will likely require investment to modify making it work for your environment.  After this you’ll need to be aware that it could be some time before the next release or the code will not be compatible.

Looking at CEPH for storage with the main features are the RBD block devices, the RADOSGW object store and the CEPHFS distributed client system.  If you refer to the automation discussed earlier you again will likely use Ansible, Puppet, Chef and SaltStack.

So, what are the alternative to using Vanilla OpenStack?

Firstly, if you decide to run vanilla OpenStack, you’ll likely not do everything yourself and will need partner with 3rd party who can provide everything you’ll need from consulting, installation, management of package updates and ongoing operations.

Alternatively, you could consider using one of the four big OpenStack distributions who can license you OpenStack and package a range of additional services to aid in your deployment.

The decision could be easy based on which logo you are already familiar with and have an existing commercial arrangement in place and quick become the preferred solution for your company.  However, don’t jump too quick as there are many other elements to take into account pending your final deployment which we’ll now cover the pros and cons with four of the main distributions from Red Hat, SUSE, Mirantis, Canonical (Ubuntu), addressed in this order.


If you already use Red Hat, you probably want to choose Red Hat right because you don’t want to change all the engineers holding years of experience managing Red Hat.

Red Hat OpenStack product is currently version 11 and it’s coming with OpenStack Ocata based on RHEL7.3 The kernel version is 3.10 but don’t be surprised that it’s not really at 3.10.  There’s more code in there that’s back-ported from newer kernel versions. So, you have an enterprise kernel with a lot of features built in.  Virtualisation is ESX (vCentre) and KVM.

Deployment is done via OSP Director which is based on TripleO/Ironic and Anisble (Optional) or Packstack for test environments. That’s also supported by Red Hat.

There are many services within OpenStack which the OpenStack Foundation distinguishes between core services and optional services.  The core services are Nova, Neutron, Swift, Cinder, Keystone, and Glance.  The above graphic shows the additional optional services which Red Hat chooses to support.

There are many packages. They still support some are only in technical preview available and some are not supported at all.  The common situation between all distributions is that nobody supports everything.  For example if your desired service of Designate (DNSaaS component for OpenStack) is not supported by Red Hat and is important for your deployment then you will likely begin evaluation of Mirantis OpenStack.

Looking at the lifecycle for Red Hat, a new downstream version with every upstream release with the release of Pike in a few weeks or months.   Additionally, bundled in the product will be Cloudforms and will be recommended to use satellite and large installations to manage patches and licenses or subscriptions.

Last year the support model was changed similar to that of Ubuntu or Canonical so you have an LTS (long term support) release. Every three versions is an LTS release which is supported up to five years (LLR/LTS releases like r10).  Compared to intermediate releases like r11 only being supported for 1 year.

They have two phases in this report. (In the first you get) In the first two years you get auto back-ports from newer versions and then the following three years you only get big bugs fixes. The intermediate releases between the LTS releases are only supported one year. For pricing it’s very common based on machine and socket-pair. Socket-pair was introduced to prevent to use large machines with a lot of sockets in the high-performance computing area paying less in licensing fees.

If you look at Red Hat CEPH storage 2.4 it is based on Jewel RHEL 7.4 or Ubuntu 16.04.  It was meant to come out with Luminous but didn’t, so it will be in the next release of Luminous 3.0.  You can get support for RHEL or Ubuntu, so you could also buy this product to run it on your Ubuntu installation.  It comes with the deployment method is easily Red Hat Storage Console or Ansible or manually even is supported. With the next release it will be only Ansible. So, this is changing and the Red Hat Storage Console will be end-of-life.

Feature-wise, CephFS (Tech Preview) it will be in the upcoming release fully-supported.  There is support for NFS (via Object Gateway) and iSCSI (Tech Preview). As iSCSI is still Tech Preview it will be supported in the next release with support for BlueStore and will remain in Tech-Preview status to the next release.  For pricing it’s based on raw capacity with node limit. Another option is you can have pre-production subscriptions which are cheaper for testing environments.

Containers are currently the hot topic in the communities right now.  Red Hat have OpenShift with Kubernetes and Docker with the Docker version coming from the open source version and Red Hat offer an Atomic and RHEL OS for this.


The SUSE OpenStack deployment is still shipping OpenStack Newton which is based on SLES 12 SP2 base so the kernel version is a little bit newer but with a very common LTS kernel version 4.4-base.  For SUSE Virtualisation there’s many options for OpenStack supporting KVM, Xen, VMware vSphere, IBM z/VM, Kubernetes via Magnum.

SUSE deployment is performed by Crowbar and Chef.

SUSE in addition to the core OpenStack services supports many others with only a few packages currently not supported.  The life cycle is different always skipping one release.  So a new downstream version with every second upstream release with the next after Newton will be Pike (Q1/18).

It is recommended if you want to build appliances on your systems to use SUSE Studio and to manage everything the SUSE Manager.  If you need staff to support your legacy applications but are not cloud-ready you probably also want to have the HA extension which allows you to run HA compute nodes based on KVM and Xen.

Current support for the product is 27 months after general availability. The next version which is coming up is the version 8 with Pike (aligned with SLES12-SP3) which will have 3 years support or depending on when you buy it, it will be bundled to the service pack 3.  If you purchase late such as one year after the GA and SP3 is flagged for end of life in 2 years then you will only get 2 years of support.

SUSE price is very comparable with a special price for Control and Admin nodes but the rest are compute nodes are basically auto-socket-pair-based and you have the same rules as everybody depending on your SLA’s the price will reflect this.

Looking at CEPH, it is probably the most driven distribution around that’s offering HA.  Offering an enterprise-ready version, they always are around half a year, ahead of Red Hat offering special features.  SUSE Enterprise Storage 5 is based on Luminous with OpenATTIC based on SLES12-SP3 being a good tool is to monitor and manage CEPH.

Deployment is via DeepSea and SaltStack with feature supported for BlueStore, Data Compression on CEPH, CEPH-vessels already widely supported and CEPHFS offering multi-DMS, MDS support.  iSCSI is supported, NFS Ganesha/S3 and recently CIFS Samba implementation for CEPH is in Tech Preview. Pricing per node plus there’s a base subscription to get your initial cluster with four nodes and controller nodes.

SUSE container platform support is via a product called SUSE CaaS platform based on Kubernetes, Docker (OS) in addition to offering Micro OS based on SUSE.

Additionally, SUSE obtained some assets from HPE that have been integrated which might have some implications on how the next releases will look.  HPE Helion and SUSE Cloud 8 will basically base on the OpenStack side and on the under-laying on the same code base in the future.  Expect some consolidation, more community engagement with more people developing.

Some experiences with SUSE is that if agreed on a specific feature you won’t pay for its development as everything is upstream and therefore everybody has the advantage of the implemented feature in their subscription.  Other distributions usually charge you engineering hours depending on the feature.


Mirantis runs OpenStack Ocata and is the only distribution that doesn’t have their own base operating system.  Today everything is based on Ubuntu and previously offered support for Red Hat and SUSE. Node (computer & controller) run on Ubuntu 16.04 LTS.  No longer support for SLES/RHEL/Oracle).

Kernel 4.4 based virtualization support for Kubernetes, Docker and KVM.

Mirantis deployment is done via MCP Drivetrain (SaltStack-based + Jenkins/Gerrit) within CI/CD chain.  There’s no traditional release model anymore with frequent updates and each time you will receive a new version of OpenStack.

Supporting only a few projects with a lot of projects that are not even technical preview.  For life-cycle management every upstream release will be released depending on the CI/CD chain. When they make it available it’s usually within 1 to 6 months of the official release.  Because they run it to the CI/CD chain, support exists for multiple versions of OpenStack next MCP 1.2 scheduled Q4/2017 supports Mitaka, Ocata and Pike (not Newton).

It comes with Stacklight, Drivetrain, Kubernetes support and OpenContrail (SDN solution) included. The pricing is similar as machine-based with no limitations on the socket-pairs.  Support of 8×5, 24×7 with Mirantis also offering managed services.

CEPH is already included as part of MCP which is based on Luminous. and going the same way as SUSE with deployment via SaltStack and OpenATTIC (Decapod / ansible discontinued).  What they used before the Decapod/ansible is discontinued.

There is no support for CephFS but support BlueStore.

Pricing for the storage is the same as server-based and they also have a container platform included there which is basically Kubernetes and Docker.

Ubuntu it’s already Pike-based. On the 16.04 LTS release of Ubuntu, Kernel-wise it’s the same as Mirantis. They also support besides KVM, Hyper V and LXD for deployment.


Canonical OpenStack (enterprise version) is not the same as Ubuntu OpenStack (community version). Canonical isn’t the official name of the product but there’s an enterprise version and community version.  You will hear people say they have so many people using Ubuntu but you always have to ask yourself if it’s the enterprise or community version with support?. So while the most community developers using Ubuntu make us out of DevStack, Puppet, Ansible, SaltStack, Chef, etc, the Enterprise version uses JuJu with MaaS.

For support you see many of the additional services in a Technical Preview state with only three supported services.  Excluded are PANKO and MONASCA, so you are close to having access to getting all the services.

The Ubuntu life cycle has the new downstream version with every upstream release.  Additionally, if you have a large installation probably landscape is recommended for system management, security compliance and audit.

Ubuntu support model is a little complex. 5 year support for LTS versions of Ubuntu, 1.5 years for versions (N, O, P) and 3 years for OpenStack release of next TLS in former version.

Pricing is node-based per year or VM per hour with OpenStack regions (S/M/L) based on your scale of installation.  With additional costs based on what level of support is required 24×7, managed etc.

For CEPH, Ubuntu’s Advantage Storage is based on Luminous and it comes with the CEPH Dashboard and OpenAttic.  Feature wise CephFS is supported along with iSCSI, NFS Gateway and Erasure coding (no Juju charm) which can probably be configured manually.  Rados Gateway and RBD are supported in all distributions therefore excluded from the list.

Pricing is different as it is based on usage capacity, not on how many servers you have.

The container platform supports LXD, Kubernetes, Docker (CS) which is the commercial (not community) version supported by Docker which is Juju based.  It comes with entry-level 3 support for that from Docker.

Potential issues if you want to have an Open Source stack is that Landscape is not open source and does not have an Open Source license, additionally the controversial integration of ZFS which could be the single stumbling block for some companies.  LXD is not supported by other distributions and there’s a vendor lock-in as a result. So, if decide to change, there will be other elements you’ll need to change as a result.


Customers have many questions to ask and decisions to make when selecting their OpenStack platform.  Here’s some to consider in no particular order, which the knowledge of one question possibly changing the next question to be asked.

  • Current infrastructure and skills
  • Vendor relationships
  • Available features
  • Access to development skills in house / external
  • Support options
  • Upgrade paths
  • Experience from others
  • Community engagement, code contributions etc
  • What the distributions doing in the community
  • Other large customers using the same platform
  • Number of changes between releases
  • Bugs fix ratio, some can fix more bugs than are opened
  • Licensing and final solution pricing
  • Support options, problem ownership
  • Budget etc.

The best start would be an evaluation or proof of concept

Presentation Reference.


Juniper Cloud Fundamentals (JCF) Course Launching April 1st, 2018

Juniper Cloud Fundamentals (JFC) Training

The new Juniper Cloud Fundamentals (JCF) course will be launched on 1st April 2018.  This three-day course provides students with an understanding of cloud-enabled networks, cloud service deployment concepts, and virtualised network platforms such as vSRX and vMX.

The Juniper Cloud Fundamentals course includes a high-level overview and understanding of cloud network underlays, cloud network overlays, cloud design, cloud implementation methods, cloud services, Juniper Networks virtualised platforms.

To obtain the most benefit from the Juniper Networks Cloud Fundamentals (JCF) course, attendance of Introduction to the Junos Operating System (IJOS) course is strongly recommended prior to commencing this course.

See below the “important notes” for the new Juniper Cloud curriculum. And remember, you can contact one of our training consultants to discuss the range of options and the most current information.

* The JN0-411 Cloud, Specialist (JNCIS-Cloud) certification was formerly known as Juniper Networks Certified Specialist – SDN and Automation (JNCIS-SDNA).

*** Yet to be released as of February 2018, the Network Automation in the Enterprise Cloud (NAEC) course was formerly known as Network Automation in the Data Center (NA-DC). Course and exam information (length, availability, content, etc.) is subject to change.

The full Juniper Networks Cloud Fundamentals (JCF) course outline can be found below.

Download Course Brochure

Crystal Echo’s Network Automation Training

Industry Network Automation and Official Juniper Network Automation Training

We offer public schedule training, customised network automation training and consulting solutions, by our own Crystal Echo Engineers, or through partnerships with suppliers and specialists in given areas.

What is Network Automation?

Nowadays, everyone seems to have their own perception of what constitutes network automation. Notably, Techopedia defines network automation as the process of automating the configuration, management and operations of a computer network. It’s a broad term that includes a number of tools, technologies and methodologies used to automate network processes.

At Crystal Echo, however, we believe network automation can be best defined as clever processes designed to save time, make changes to improve productivity, and achieving more with less.

How is network automation implemented?

Network automation is implemented through the combination of hardware and software-based solutions that automatically execute and manage repetitive network environment processes.

Crystal Echo – Network automation training

Crystal Echo is proud to be Juniper Networks’ longest serving Juniper Networks Authorised Education Partner (JNAEP), worldwide. In addition, we are an ANZ-appointed Juniper Professional Services Specialist (PSS) Partner. In fact, we are one of the few Juniper Training Partners that Juniper Networks have authorised, outside of their own entity, to deliver their course: JAUT Junos Platform Automation and DevOps.

Maybe you have earmarked 2018 as the year to introduce network automation to your organisation? Or, perhaps your goal is to enhance your network automation knowledge, skills or organisational capabilities? In these situations, please bookmark Crystal Echo’s divisional websites, itemised below.

In summary, here’s an overview of each website’s core focus:

Divisional website

Use this website to


Training course outlines, company overview


Remote labs available for hire, proof of concept and recertification practice


Juniper certification curriculum, Juniper certification paths, graphical representation, course prerequisites and discounted Pearson VUE exam vouchers.

Note: If you have a need to do something different in your network, require guidance, or would like to implement something of best practice, a quick email or call to see if we have experience with the given topic might save you considerable time.

Official Juniper Automation Training

Official training program:

Junos Platform Automation and DevOps

Course code:


Course overview

Junos Platform Automation and DevOps, is a 5-day, all-encompassing Juniper course that covers on-box automation within Junos. Furthermore, this course addresses modules covering industry open source DevOps tools, and how they interface with Juniper’s Junos to achieve business outcomes.

Note: This course will soon become part of an automation-based certification.

Click on our further information link:

Juniper Automation Course

Customised Juniper Solution-Based Automation Training

Crystal Echo understands that no two businesses are identical. Every organisation has its own unique specific goals and objectives. It is, therefore, not surprising that similar businesses operating in the identical industry, also have their own unique network automation needs. As such, if you require customised Juniper network automation training and solutions, simply contact Crystal Echo today.

To illustrate our custom automation solutions, in mid-2017, Crystal Echo worked with Juniper ANZ to deliver prerequisite training for a customised Throw down event, which was delivered to Telstra Melbourne. Due to the success of this customised automation training, more events are planned for 2018. The 2017 event took identified business issues within Telstra. They were then scoped and defined as problem statements, which were then work-shopped across a 5-day event using industry automation tools.

  • The objective was to solve these problem statements with automation.

To ensure the success of this event, participants needed to become competent in Junos, Software Development and Automation Platforms. Crystal Echo addressed this in a limited but in-depth format over 7.5 days (3 x 2.5 days for each subject). Materials, which were appropriate to the customised training, were developed under a Joint Venture arrangement between Crystal Echo and SDN Essentials (US-based).

To learn more about these essential core competencies, click on the relevant links, below:

Juniper Automation with DevOps

Acquiring DevOps-like skills takes time and experience. Typically, learners with programming backgrounds are most suited to the task. Crystal Echo offers courses that offer varying depths of content and practical lab activities to gain DevOps skills. For example, we offer a specialised 5-day course on Python programming, Ansible or overall Network Automation.

Crystal Echo partners with Network to Code, to facilitate 5-day in-depth training programs. These training programs have the option to extend beyond the training event itself. This optional extra, alone, presents an excellent opportunity to take advantage of the instructor’s attendance. For example, many of our clients use this time for:

  • Organisational consultancy, and
  • Seeking expert advice on architecture, implementation and deployment of automation tools.

Note: From our perspective, teachings can be put straight into practice. This can, therefore, facilitate the achievement of immediate results.

To learn more about these Dev-Op related competencies, tap on the relevant links, below:

Juniper Vendor Platform Automation

Customised tools and platforms provided by vendors provide simple user interfaces that enable configuration and monitoring of vendor-specific functions, typically limited only to their own platforms without having to program or script specific tasks.  This saves time, but the licensing of the platform comes at a cost.

Juniper provides a platform called Junos Space, which is a Network Element Management platform. Junos provides Juniper-specific tools enabling you to automate configuration, network management and reporting functions. These are turn key solutions. Juniper-specific templates and processes are already defined. These can provide a scalable means by which to manage large networks — with thousands of devices.

In simplistic terms, Junos performs the tasks of routing, switching and security in Branch, Enterprise and Service Provider networks. Licensing a Junos Space platform from Juniper can solve many network management issues for large Juniper deployments.

Learning to install, operate and maintain the Junos Space platform are addressed in the below Crystal Echo delivered courses:

Juniper Software Defined Networking (SDN)

Today’s necessity to build networks suitable for large Enterprise, Data Centres and Service Providers, has seen prolific growth of Software Defined Networking (SDN) Controllers. SDN has the ability to control network decisions from a single device with specialist software. They allow uniform changes to be quickly implemented end to end, across a network, leveraging an SDN Controller.

SDN strategy based on open source or a vendor-specific implementation can be costly and fraught with uncertainty. Our Juniper SDN training programs, and SDN consulting experience, covers concepts from many vendor and industry implementations. Juniper’s training opportunities in this space, include:

Software Defined Networking (SDN) by SDN Essentials

Leveraging our Joint Venture with SDN Essentials, we have training materials and instructors ready to deliver SDN training across multiple vendor solutions. Vendors include: Juniper, Big Switch, HP, NEC and Cisco.

 SDN – Skills Transformation Program within Industry

Recently, a unique and innovative SDN Skills Transformation Program was designed for 40 new SDN networking engineers. The training program was delivered over a 30-day period and utilised a progressive assessment strategy. The end result was miraculous; furnishing Juniper Networks with a healthy injection of SDN engineers to work on confirmed projects.

If you’re wondering what this successful SDN course consisted of, here are the modules of learning that were delivered over a duration of 30 days:

  • Intro to SDN
  • Linux Admin
  • Intro to OpenStack
  • Python for JUNOS
  • Study Day
  • 1st Written Exam
  • Yang/Netconf
  • Juniper Intermediate Routing (JIR)
  • Advanced Juniper Service Provider Routing (AJSPR)
  • Introduction to Contrail
  • Advanced Contrail Configuration
  • Study Day
  • Onsite 8-hour Lab Session

Note: Further program detail can be supplied upon request.

Orchestration with Mirantis OpenStack

There are many platform options at one’s disposal when it comes to deploying OpenStack.  Solutions from Mirantis, Redhat, Suse and Ubuntu are four popular and supported options that are available.

Crystal Echo’s Mirantis course content and training program equips engineers with universal skills. Learners will gain essential knowledge and skills that will not exclusively limit them to implementing and working on Mirantis installations of OpenStack.

Mirantis OpenStack courses focus on the core OpenStack technology and operation. This certification-based Mirantis training maps to other vendor implementations of OpenStack. In addition, small references to additional features that Mirantis can provide to assist in maintaining and easily operating your OpenStack installation.

Crystal Echo currently offers the current OpenStack training of OS50 and OS100 and in future will offer OS200 and Kubernetes-based training. Further information about these programs can be found by following the links, below: