This blog is part of my series on Openstack Juno. In this blog, I will cover the usage of Openstack services Nova, Cinder.
I found this blog on Openstack services good in giving a highlevel overview of services and comparing individual Openstack services with Amazon AWS services.
Nova basics:
Nova is the Openstack compute service.
Following command shows the flavors available by default. Flavors are different configurations(CPU, memory, hard disk) for the VMs that can be created from Nova.
Earlier, I had written 2 blogs on Openstack devstack Icehouse installation and networking. The feedback was positive on these blogs. This prompted me to do a series on different aspects of Openstack Juno. Openstack Juno is the 10th and latest release of Openstack that got released in October 2014. In the next series of blogs, I will cover the following aspects of Openstack Juno.
In this blog, I will cover the steps to install Openstack Juno in Devstack.
My environment:
Installation steps:
This blog is part of my ongoing series on Docker containers. Orchestrating Containers is a pretty complex task and there is a lot of work ongoing to solve this particular problem. There are big companies, startups as well as Opensource projects involved with this work. There are many different technologies and projects ongoing that got me really confused when I started looking at this. In this blog, I have tried to break down the Docker orchestration problem into smaller pieces and have tried to map different existing/developing solutions into the smaller pieces. Considering that the technologies are evolving and that my knowledge in this area is limited, this blog might need updates and corrections as we move forward. Also, I might have missed few technologies as well as companies..
Docker does a great job in packaging and transporting single containers. Following are specific problems we need to address:
This is a continuation of my previous blog on Group based policy(GBP). In this blog, I will cover the GBP features in Opendaylight helium release, Use-cases that are published in the Opendaylight wiki as well as different usecase that I tried out.
Following diagram is from Opendaylight GBP wiki:
There is lot of work going on in both Openstack and Opendaylight projects on Group based policy and I will try to capture my learnings in the next few blogs.
Group based policy(GBP) is an abstracted way of specifying interactions between the applications rather than using infrastructure specifics. In the networking context, for example, rather than using terms like ip address, vlan, port numbers, the policies are specified in much higher level language in terms of what the application needs. Currently Group based policy is targeted for Networking. Eventually, it will be applicable to Compute and Storage as well. I kind of see GBP as Open source variant of Cisco’s ACI model, multiple vendors are involved in the development of GBP.
In Openstack Neutron context, following are the goals of Group based policy.
I came across few recent Opensource projects which I found them to be interesting. In this blog, I will cover some details on OPNFV, Openconfig, ONOS. There is no relation between the 3 projects, the common thing is all the 3 projects are focussed on Networking and Cloud and all are relatively new.
OPNFV is an Opensource project under Linux foundation. The goal is to create a Opensource reference platform for developing NFV applications. In 1 of my earlier blogs on NFV, I covered overview of NFV and the ETSI NFV model. The goal of the OPNFV project is to create a reference implementation using the model proposed by ETSI. OPNFV’s plan is to leverage the work done in other Opensource projects like Openstack, Opendaylight, Openvswitch, KVM, Linux kernel, DPDK. Even though OPNFV can work with other Cloud OS and SDN controllers, the goal for the first release is to use the most popular Cloud OS, SDN controller and hypervisor mentioned above. Following picture from OPNFV illustrates the blocks that OPNFV will focus on from ETSI NFV reference model.
Continue reading Recent Networking Opensource projects – OPNFV, Openconfig, ONOS
In the last few months, following were some acquisitions that happened: Cisco acquiring Metacloud, EMC acquiring Cloudscaling, HP acquiring Eucalyptus. Metacloud and Cloudscaling have Openstack based distributions, Eucalyptus has a cloud OS similar to Openstack. This set of acquisitions prompted me to look little closely at Openstack distributions and following blog is a result of this.
I see a close parallel between Linux and Openstack in terms of how they are evolving. Unix started off with various flavors like FreeBSD, Solaris, Linux etc. Linux is the dominant Unix version used now. There are different companies like Redhat, Ubuntu selling and supporting Linux distributions. There are currently different Cloud OS like Cloudstack, Eucalyptus, Openstack etc. Openstack is emerging as a major Cloud OS. There are different companies selling Openstack distributions currently.
Recently, I saw a lot of press on Cisco’s Opflex protocol that allows a declarative policy model to control a physical or virtual device. There were discussions around if the Opflex protocol would replace Ovsdb and Openflow. Within Openstack, there is a new project called Congress that allows for creating a policy framework within Openstack. This blog is my attempt to get into more details on Congress and Opflex and explain the relationship between them. This is mostly information gathered from different references that I have listed in the end.
Congress is a new Openstack project that is used to enforce compliance within the cloud environment. The end goal would be to integrate Congress with other cloud orchestration software as well. Compliance could be needed because of Government regulations, contracts between organizations, SLA enforcement etc. Following picture illustrates the need for Congress.
This blog covers a hands-on session demonstrating Openstack networking capabilities. This is a followup to my previous blog where I covered the Openstack Icehouse installation and basic usage. I have covered the following in the video.
VMs used are same as previous blog:
Controller localrc can be found here. Compute localrc can be found here. I had some issues getting connectivity across hosts working with network type vlan and vxlan. I am not clear if the issues are with the ovs switch version that I have or with the localrc configuration. Open vswitch version I am using is 1.4.6.
In this blog, I will cover steps to install Openstack Icehouse release using Devstack. I will cover Single node installation as well as Multi-node installation. In a single node installation, both control and compute instance runs in the same VM. In multi-node install, control and compute instance runs in 1 VM/host and a compute instance runs in another separate VM/host. In multi-node install, we can spin as many compute instances as needed. With 12GB RAM in my host, I was running out of memory with single control and compute instance and a bunch of host applications running in my system.
My environment:
Downloadable VM:
I have created OVA files for both the controller and compute instance that can be downloaded from below links. Import the OVA files into any VM manager software like Virtualbox to try this out. These VMs are running Ubuntu 12.04.
Alternate locations for downloading VMs in case the Dropbox link above does not work:
Following are the steps that I did to create the VMs above. If you are downloading the OVA files, you don’t need to follow the steps below. Continue reading Openstack Icehouse install using Devstack
Sreenivas Makam's Blog 