OpenStack is the current de facto standard for cloud computing platforms and is supported by all major Linux distributions. Coupled with its role as the base technology in the domains of NFV & SDN, it has become one of the hottest softwares for networking community. It is a combination of numerous components and services, which means that deploying openstack is often complex, time consuming and error prone, especially for beginners. Deployment options vary from manual setup i.e., to install and setup each individual component manually, to use of automated tools such as Devstack, Fuel and Packstack.

The easiest way for getting started with openstack is through automated tools but using them properly requires significant forum/manual scavenging effort. This is too daunting for cloud application developers or anyone whose primary concern is to evaluate the cloud technology.

To ease these deployment concerns, our goal is to provide a robust, pre-configured (yet customizable) and easily installed openstack setup. The result will be a “CentOS Remix” with an option to setup openstack during installation. This is implemented by integrating two efforts by the Red Hat community namely RDO and Packstack into the CentOS installer i.e., Anaconda.


The development involves integrating OpenStack from the CentOS Cloud SIG (which also feeds the Red Hat community’s openstack packaging effort, RDO ) and Packstack (openstack deployment tool) with Anaconda. The resulting remix will:

  • Install CentOS along with OpenStack in one installation cycle.
  • Use packstack to configure & deploy openstack (in post-install phase).

The integration will be achieved by developing an add-on for the Anaconda installer. Anaconda add-ons can be used to add support for custom configurations screens in the graphical and text-based user interface. OpenStack support can also be added to anaconda by modifying its source but add-ons are also extensible, maintainable, easier to debug  and test. They also provide an opportunity to extend openstack support to other Linux distributions that use anaconda.

Current Status:

Anaconda has three modes of operation i.e., Kickstart, Graphical and Text User Interfaces. Hence our add-on development is divided into adding openstack installation support for each of these three modes. Uptill now Kickstart support has been implemented i.e., user is able to install openstack through a kickstart file during setup.

Currently GUI support is being developed. After that TUI support and openstack customization options will be added. Final deliverable will be an “CentOS Openstack remix” ISO (~1.2GB) extending CentOS minimal ISO.

Project source along with testing instructions are available at Github

  • Email:
  • IRC: asad_ (#centos-devel)



Johnny Hughes has already posted images for Cubietruck and Raspberry Pi 2 and told you how to use them with your boards. In this post, I would like to tell you all the what has gone into development of RootFS Build Factory so far which includes a bit about the CentOS ARMv7 effort.

When I first started looking up project ideas for GSoC this year, the RootFS Build Factory idea caught my attention because it fit right into my interests and skill set. This was in the first week of March. Back then there was no CentOS ARMv7 and as far as I knew, the only person who had done any work in the area of building ARMv7 packages was Howard Johnson. His post on the CentOS arm-dev mailing list described his efforts of compiling CentOS for ARMv7 using Raspberry Pi 2 and Odroid C1. This was my first introduction to CentOS ARMv7.

Back then it seemed like the RootFS Build Factory project would require building a minimal CentOS ARMv7 first and then working on a set of scripts to re-bundle packages in this minimal build.
I got in touch with members on the CentOS team on #centos-devel and #centos-gsoc on Freenode and interacted with Jim Perrin and Ian McLeod (who later became my mentor for this GSoC project). With their inputs I started thinking of alternatives to Howard’s method of compiling packages and came across work done by msalter from Redhat

He had developed plugins to cross compile packages using mock and Koji and a yum plugin for installing non native rpms. This seemed great as I did not have any ARMv7 hardware at that point and the idea of generating ARMv7 on fast x86_64 desktop seemed like a good one. Later on, after discussion with msalter (which happened in the first week of June) and based on his advice we realized that this approach wasn’t going to work for CentOS as the pre/post install scripts in the RPMs wouldn’t run in a cross environment.

My original GSoC Proposal was based on using msalter’s yum plugin to build ARMv7 images on x86_64 but after discussion with msalter and in consultation with my mentor Ian, it was decided not to go forward with the yum cross plugin approach and to focus on the targets in my proposal which would involve building CentOS ARMv7 images using either ARMv7 hardware or QEMU.

There was still the big issue of how, where and who would compile CentOS ARMv7. This is where Fabian Arrotin’s efforts came in and took care of matters. His work using a plague farm he setup on the Scaleway nodes, got us a working set of ARMv7 packages. Until then Ian and I were contemplating doing the build ourselves using hardware we had at our disposal.

We decided that until the ARMv7 CentOS build was ready, we would use Fedora for development. Fabian Arrotin was very quick in creating the repositories which meant we didn’t have to use Fedora for long. Of course the first build of CentOS 7 ARM using the RootFS Build Factory happened on Fedora 21.

The present status of the project is this:

  • Tested generation of images for QEMU (, Cubietruck, Odroid C1, Raspberry Pi 2, Banana Pi, Cubieboard 2. Tests for the last two have been reported by Nicolas [nicolas at] and David Tischler [david.tischler at] respectively. The Odroid C1 and Raspberry Pi 2 images do not use the CentOS Kernel.
  • Untested Boards: Cubieboard, Wandboard{solo,dual,quad}, Pandaboard, CompuLab TrimSlice, Beaglebone. Support for these boards has been added based on information on the Fedora Wiki. I do not have these boards with me.
  • For adding support for more boards, you can refer to

Presently there are 3 main components in RootFS Build Factory

  • : takes a XML Template and generates an image.
  • : dialog based UI using the python2-pythondialog library to load/edit/create XML Templates.
  • : Takes a Generic/QEMU image, writes it to your microSD, then writes board specific U-Boot to microSD. This works for the boards where the CentOS kernel is used since the only difference between images for different boards is U-Boot. In case of Raspberry Pi 2 and Odroid C1, just the image generated by RootFS Build Factory is written to microSD.

The original proposal mentioned writing the UI in PyGTK but because cross development was out of the picture and I didn’t think people would run X11 in QEMU just for RootFS Build Factory, I chose a console based approach. Although the interface loads in the QEMU console, it doesn’t load the colors and there is some text visible on the edges while selecting files/directories. I suggest you set up bridge networking on your host and then SSH into the QEMU instance.

If you have any queries you can post them in the comments below or email me [emailmandar at] or discuss it on the CentOS arm-dev mailing list

When using on-demand instantiation of virtual machines in cloud computing,
users pass configuration data to the cloud and that data is used for
configuring the instances.
This process is called contextualization. Contextualization includes
identity(users, groups), network, system services and disk configuration.

Flamingo is a contextualization tool that is being developed under GSoC 2015

that aims to handle early initialization of cloud instances.

The current de facto standard for instance virtualization is cloud-init.
However, there are some problems with it. The most prominent ones are:

  • The usage of a scripting language (Python in this case), since scripting
    languages have the overhead of the interpreter, its dependencies and
    being slower than compiled ones due to their dynamic nature.
  • The documentation is lacking at best. There are examples of common
    use-cases. However, most of the code-base and plug-ins are undocumented.
    Inspecting the code-base is a prerequisite to extend the functionality or
    even understand it.
  • Test coverage is low. Making it hard to extend, maintain, and improve.

Don`t get me wrong it gets the job done. But, it has a lot of issuses and
these issues make it hard to use, extend and maintain.


Flamingo aims to solve the following problems encountered in cloud contextualization;

  • Speed
  • Dependency
  • Maintainability
  • Extensibility

Go is a very suitable choice for a tool like this. Since, it is fast,
it has cheap concurrency, and dependency management is a breeze (see godep).
It allows the distribution of a single executable binary with its dependencies.


Target Distribution

The first target for Flamingo is the CentOS Atomic Host and CentOS Linux generic cloud images. We would, ofcourse, like to see wider adoption and are interfacing with other projects and image builders to see how best we might collaborate on this moving forward.


Getting Involved
You can find the source code for the tool here.

For more details please check this blog post


In the meanwhile if you’d like to share your opinions, learn more,
or contribute please feel free to open an issue, mail to centos-devel,user-list or come to #centos-devel IRC channel to have a chat.


  • E-mail: contact _
  • IRC: tmrts


Tamer Tas


The CentOS Project has been performing daily CI testing for quite a while using our t_functional test suite.

This testing has solved numerous issues for us in the past, although since it was being run daily sometimes we needed to re-release problem packages after fixes were rolled in. We have gotten the run time down considerably now (less than 1 hour for all tests) so we have adopted the policy that we will be running this test suite now as a Pre-Release process for updates so that if there are problems, we can address them before release.

The t_functional suite lives on github and we would be happy for people to help us develop new tests or make the current tests better.  You can download and run the tests on a VM or machine that you can afford to reinstall (the tests are destructive and the machine is left in a state that is different than when the tests start, so it should never be run on production/important machines).  You can also submit new tests or updates via github. We use the CentOS-Devel mailing list for discussion of these tests and for requesting changes.

Please help the CentOS Project make CentOS Linux better by testing, designing and submitting to our t_functional suite.

Ten days ago I wrote an article here about an armv7hl test image for the Cubietruck 32-bit ARM board.  I have just uploaded a similar armv7hl image for the Raspberry Pi2. Both of these images are created with the RootFS Build Factory (a 2015 CentOS GSoC Project from Mandar Joshi sponsored by the CentOS Project).

The Raspberry Pi2 image (as well as the sha256sums for the compressed and uncompressed images) is available here:

This RPI2 image actually uses the base kernel and boot files from the Raspberry Pi Firmware github site, and not the CentOS-7 armv7hl kernel.  This RPI2 kernel seems to be causing an issue with firewalld, and one must edit the file /etc/firewalld/firewalld.conf and change the variable IPv6_rpfilter from yes to IPv6_rpfilter=no.

Mandar has been making lots of progress on RootFS Build Factory and other people have reported that images generated from RBF for Odroid C1 and Banana PI are also functional, as is the image for QEMU.  I will be trying to obtain and post workable images from these boards soon.

I want to point out that the current images created are not signed and are taken directly from the output of our armv7hl builders ‘as is’ with no QA testing.  The armv7hl build is still very much a work in progress and the image manifest is based on a CentOS-7 (1503) minimal install from our x86_64 install media.  We have not yet completed the entire tree and the build repositories may at times NOT have complete closure and are only about 85% complete at this time.  We will finish the baseline build and then start the updates repository, but as of now these repos should be considered PRE-ALPHA and not production ready.

To use this image, you first extract it with this command:

unxz rpi2-centos-image.img.xz

Then just dd it to an SD Card and boot it in your Raspberry PI2 using a command like this from linux:

dd if=./rpi2-centos-image.img of=/dev/mmcblk0

(Note:  your SD Card device may vary .. you should be able to find the card device with fdisk -l )

If you are going to be at Red Hat Summit 2015 this upcoming week (June 23rd to 26th, 2015), please stop by the CentOS Booth in the Community Central area and we will have working armv7hl demos of a RPI2, Cubietruck, and Banana Pi .. as well as a working armv8 (aarch64) AppliedMicro X-Gene Server on a Chip  demo machine.  Hope to see you there.

About a week after announcing the CentOS 7 alpha build for AArch64 hardware, I got an email from the fine folks at AMD asking for my address. Three days later, a pair of AMD’s Seattle AArch64 development boards showed up at my front door.  Hardware really is the best sort of gift, especially when you’re building for a new platform. I needed to make a couple modifications to my lab (okay fine, my home) network in order to make use of the new AMD gear due to the board layout. The boards I have don’t include USB by default, and I usually cheat and do USB based installs. Instead, I set up a proper pxe environment and loaded the OS up the right way.

Because the hardware was shipped with UEFI by default, there was very little to do in the way of configuration. I simply pointed the serial console at the pxe option and then did a normal vnc based install when the installer loaded. I don’t want to spend too much time here talking about the installation, because it was exceptionally simple. If you don’t have or want PXE, a pcie usb card would work fine. You can even simply yank the drive and dd the disk image directly to it, then power up. The only downside to the last approach is the need to run efibootmgr manually to set up the UEFI boot entry. In the coming days, I’ll be updating our AArch64 documentation to reflect the added hardware and providing more detailed directions for configuration and setup for the hardware.


Apart from being able to report that the AMD boards work just fine with the CentOS 7 AArch64 beta, I can also happily report that they’re proving quite useful. Since I have multiple machines, I’m now able to run a number of test cases and multiple configurations without the need to cannibalize my build system or boot from multiple drives. This has given me the ability to run our t_functional testing suite against the AArch64 beta, and identify a few minor build issues that I need to address before we can call the release GA. Thanks AMD!


FUDCon is the Fedora Users and Developers Conference, a major free software event held in various regions around the world, usually annually per region. This year the event in APAC is happening in Pune, India, from 26th to 28th June. I will be giving an introductory talk about the CentOS Cloud SIG (CCS) in the Openstack track on 27th June at 4:20pm.  CentOS Cloud SIG  is a group of people coming together to focus on packaging and maintaining different FOSS based Private cloud infrastructure applications that one can install and run natively on CentOS. We are a non vendor, non technology and non agent specific focus group, but we will gladly work with and build content to suit relevant niches or vendor ecosystems.

In this talk I will give a brief update about our work related to Openstack releases over CentOS 7 and CentOS 6. We will also see how OpenNebula is working towards a working build on the CBS. Anyone who wants to learn about these technologies or who wants to contribute to the SIG should attend this talk. I will be available all three days during the event. If you want to say hi or want to learn more about the CentOS Cloud SIG, please do ping me over @kushaldas or find me in person there.

As of now, you can subscribe to a calendar feed (.ical) in your calendar program of choice by adding this feed url:!calendar.git/master/output!irc-meetings.ical

New meetings are added via pull-requests against this repository:

Why is this now available?

The number of SIGs and general project work has grown and more and more IRC meetings are
being scheduled. When KB announced he would begin holding office hours a discussion about how to best notify people and keep it on their minds sprang up on the centos-devel mailing list.

How is it implemented?

Louis Taylor mentioned that OpenStack had a yaml file driven calendar that didn’t require a central authentication mechansism. After a quick round of acceptances, I implemented the OpenStack model and the calendar was born.

Our next step is to host a web page that will serve as a landing zone for this information and list all of the scheduled meetings.

For those of you interested in the details, the calendar uses yaml2ical, a python module to convert the meeting yaml files into both an ical feed and an html listing. The current workflow is:

  1. A Pull Request on adds a new meeting yaml file
  2. A project member merges the pull and manually generates the new html and ical files
  3. The files are mirrored to

To Do:

  1. 1. Land the html file somewhere in our web infrastructure (to be tackled next week)
  2. Work with the yaml2ical community to land some patches for meeting duration and urls (in progress – see Issues on github)

Currently the meetings are listed in html with their frequency information. If someone knows of a simple ical->html or ical->text_list processor we can consider hosting a “calendar” view of the calendar.

As Jim Perrin pointed out in an earlier post here on, we have commenced an armv7 (actually, armv7hl) open build to try and produce CentOS-7 for arm32 boards like the Cubietruck, Raspberry Pi2, and ODROID-C1 (among others).

We now have a minimal sdcard only image for the Cubietruck from our unsigned (and as yet uncompleted) plague-builder output.

This image has been produced by the RootFS Build Factory (a 2015 CentOS GSoC Project from Mandar Joshi sponsored by the CentOS Project).  While the RBF is not yet close to being a finished product, it was able to be used to create this image.  This is our first published image built using RBF, which looks to be to be a very promising and useful GSoC project for CentOS on ARMv7.

Before I tell you where the image is, I want to point out (with emphasis :D) that THIS IMAGE IS PRE-ALPHA, PROOF OF CONCEPT ONLY !!!.  It is based on the Source Code from CentOS-7 (1503) release with none of the follow on updates and is not suitable for use in any environment that you care about at this point.  In fact, as this article is being posted, we only have 2068 of the 2523 Source Packages even built for armv7hl at this point.  The repositories used for this proof of concept are the unsigned direct output from our ongoing build of armv7hl and while the minimal install works (and should continue to work), there may not always be repoclosure there and some packages outside the minimal install may not have all their dependencies yet built, etc.

If you are interested in helping us get armv7hl working with CentOS-7, please join the Arm-Dev mailing list where we are doing the community build now.

The proof of concept, sdcard only, image is available here:

Install instructions are available from this post to the Arm-Dev mailing list.  If you are going to try this image, you should really join the list as that is going to be where the community can answer questions about it.

Next up on the armv7hl front should hopefully be a minimal install image from the same plague-builder repos for the RaspBerry Pi2 in the next week or so.

As I have already pointed out, we do not yet have an armv7hl release, in fact to date we only have about 82% of the packages for the release that actually build at this point.  We can use the help of people who understand the boards in question … especially vendors.  Join the Arm-Dev list and give us a hand.

The rolling ISO media releases for CentOS 7 for May 2015 (1505) are now available.

These rolling ISO media releases are basically just respins of the install media at release time with all bugfix, enhancement, and security updates since release rolled in.  The updated ISOs for 1505 are based on all updates in the CentOS 7 os and updates repositories at 0000 UTC on May 28th, 2015.

The goal is to make these media available on a monthly basis for CentOS 7, in much the same way as we make cloud and container images available.

Users can use the updated ISO images for installs that have far fewer updates required after install.  There is no difference between using these ISOs and the original CentOS 7 (1503) ISOs and a yum update run on May 28th at 0000 UTC.

The new ISOs are available here:

File: CentOS-7-x86_64-DVD-1505-01.iso
Sha256sum: 70c510b8ae7e742ef12e9378ef49a919361e4f891f8f4ad92b03209f2cbb3638

File: CentOS-7-x86_64-Everything-1505-01.iso
Sha256sum: 1b117390a908467723f166ee22aa300bd4b55c57f05bc37eb58fb6bf3331295e

File: CentOS-7-x86_64-LiveCD-1505-01.iso
Sha256sum: 2310f7d28ed10a9a19d3690378a6f523c666a5ad3bfd428cc2a1f6b7438cc560

File: CentOS-7-x86_64-LiveGNOME-1505-01.iso
Sha256sum: 76a9c62c363cd90d0c8235400498829dfad9fc9bbae85916b26d2346300b649f

File: CentOS-7-x86_64-LiveKDE-1505-01.iso
Sha256sum: b48e8d2798767674f9993929d6899ca8f2f0cb0f420251e5184b3cd047403399

File: CentOS-7-x86_64-Minimal-1505-01.iso
Sha256sum: d9d394dcfa40a73cf0cfad9ebc70b54fcdd29861694791a5b678c57368087306

More information is available from our announcement here: