Discussion on the state of cloud computing and open source software that helps build, manage, and deliver everything-as-a-service.

  • Home
    Home This is where you can find all the blog posts throughout the site.
  • Categories
    Categories Displays a list of categories from this blog.
  • Tags
    Tags Displays a list of tags that has been used in the blog.
  • Bloggers
    Bloggers Search for your favorite blogger from this site.
  • Login
Subscribe to this list via RSS Blog posts tagged in Apache

Last week, the CloudStack Silicon Valley User Group held its 12th meetup in Mountain View, CA at Nuage Networks. Thank you to Sanjeev Singh and Nuage Networks for hosting our group!

21133360129 638336df6e z

We kicked off the night with an introduction of our speakers and a quick reminder about the CloudStack Collaboration Conference Europe 2015. The schedule is now live – check it out now!

Guest Speakers

Our guest speakers for the evening were Suresh Bottapatti, Tim Mackey, Chiradeep Vittal and Youcef Laribi.

Suresh Bottapatti is the VP of Engineering at Nuage Networks. He has over 19 years experience in software development, building great teams and delivering high quality software. As the first engineer at Nuage Networks, Suresh played a key role in shaping the architecture of the Nuage Virtualized Services Platform (VSP).

Hits: 2843
Rate this blog entry:
Continue reading Comments

I had a recent discussion with some folks wondering why there was now an option for 32 or 64-bit System VMs with CloudStack 4.3. I provided an answer, and linked back to some mailing list discussions. I figured this might be of general interest, so I’d document in the short term with a blog post.

For background, system VMs provide services like dealing with snapshots and image templates, providing network services like load balancing, or proxying console access to virtual machines. They’ve historically been 32-bit. The reason for this is that the 32-bit arch has been very efficient with memory usage, and since these are horizontally scalable it’s easy to just spin up another.

But you can have either – which do you pick?

Depending on the workload you might have a different answer. Some hypervisors work better with one arch over the other; and that might be a factor; but ignoring hypervisors lets examine the reason you’d want to use either. 32-bit: 32-bit operating systems are pretty efficient with their use of memory compared to 64-bit. (e.g. the same information typically occupies less space in memory). However there are limits on memory. (Yes, you could use PAE with a 32-bit kernel to get more addressable memory, but there is considerable CPU overhead to do so – which makes it inefficient given that all of this is virtualized) The 32-bit kernels also have a limit on how much memory is used by the kernel. This is really where the use case of 64-bit System VMs evolved from. Because one of the system VM functions is providing load balancing, the conntrack kernel module had a practical limit of ~2.5M connections – and that left precious little room for the kernel to do other things. CloudStack orchestrates HAProxy as the default virtual LB, which in turn uses conntrack. Having a heavily trafficked web property behind CloudStack’s 32-bit virtual load balancer might run into that limitation.

64-bit: Not nearly as efficient with memory usage; however it can address more of it. You’ll actually tend to need more memory for the same level of functionality; but if you need to push the envelope further than a 32-bit machine, then at least you have an option to do so.

Hits: 16695
Rate this blog entry:
Continue reading Comments

ApacheCon approaches

Posted by on in Open Source

It doesn't seem possible, ApacheCon is less than a week away. CloudStack Collaboration Conference follows shortly. I am excited about seeing ApacheCon this year, the schedule is huge and contains a ton of interesting content. That actually may be a detriment - so much content it will make deciding what talks to see difficult.

Particularly interesting to me is the ton of big data talk. There are plenty of big data projects at the ASF, and those projects have managed to bring 5 days worth of big data content to ApacheCon, coupled with 3 days worth of Lucene/Solr content. Keeping in mind that the ASF is the home for the majority of open source big data projects and ApacheCon becomes a must-attend event if you care about big data.

But ApacheCon is more than just big data, there are tracks for cloud and mobile development, as well as perennial favorites like Traffic Server, and Tomcat. 28 tracks in total.

All of this content is great; and I look forward to learning a lot while I am at ApacheCon, but it ignores the most valuable reason that I am attending: the hallway track. Being able to converse with  many members of various Apache project communities is invaluable.

I hope to see you there.

Hits: 10652
Rate this blog entry:
Continue reading Comments

Building CloudStack RPMs with Ansible

Posted by on in Open Source
I've been hearing a lot about Ansible lately. First I've seen folks like Paul Angus building tooling around installing CloudStack with Ansible. Ansible intrigues me a bit; first it's largely being shepherded by Michael DeHaan, who originally wrote Cobbler and really eased a lot of pain for sysadmins needing to provision machines; so his work has some immediate credibility because of how awesome Cobbler was to use. Second, the entire decentralized config management angle is interesting. I like how minimalistic it is; and while I don't think that's necessarily a good fit for every environment, it is compelling for some. Finally, I see the blurring of lines between config management and workflow/job automation and that makes Ansible pretty versatile in my mind.   I tend to learn best when I have a concrete project to actually apply new tools to, so when the hosted puppet master service I had been using went permanently offline, I decided to recreate some of the tooling around building CloudStack RPMs in Ansible. I started out with a very basic playbook, which worked reasonable well.

Playbooks, in Ansible parlance, are a place to both define system configuration, as well allowing a known order for workflow automation. I first started with just defining a build environment for building CloudStack RPMs.

Then I had the chance to listen to Michael DeHaan showing off Ansible at a DevOps DC meetup in November, and one of his code snippets had an unknown-to-me built in variable that cut my playbook length in half (as well as the number of ssh calls as a result.)  Specifically I went from a playbook like:

  - name: Install wget
    yum: pkg=wget state=latest
  - name: Install rpm-build
    yum: pkg=rpm-build state=latest


  - name: Install deps and niceties
    yum: pkg={{ list }} state=latest
     - wget
     - rpm-build

This made things much more efficient, and I pushed further from merely configuring the environment to also using Ansible as a bit of a workflow automation tool. So I added the entire build portion as well.

Things weren't 100% happy though - a number of the Maven dependency downloads failed, which caused compilation to fail. I really need to setup a Nexus mirror for CloudStack dependencies both to speed things up as well as to ensure they are reliably available for building. But this failure isn't the fault of Ansible, so can't really fault it here.

The end result is being able to spin up a fresh machine, point Ansible to it, applying the playbook and coming back (admittedly building the RPMs takes a long time) after a long cup of coffee and finding RPMs done. You can see my admittedly beginning attempts at this playbook here:

If you need to build CloudStack RPMs, or want to  see a very basic Ansible playbook you can look at:

Hits: 26258
Rate this blog entry:
Continue reading Comments


Are you looking to run your own cloud computing environment and want to interface with other users? Are you trying to cut through the hype and find out how to really run a cloud? Are you looking for a great personal conference that is run by users not marketing dollars? Then you should be in Amsterdam next week at the CloudStack Collaboration Conference. It's a user run confererence designed to bring the users, developers and other supporters of Apache CloudStack to collaborate on the development and best practices for running cloud computing. 

Just One Word - Plastic DevOps

As the cloud computing has accelerated the time to deployment for infrastructure the need to keep up with our capibilities is leading to a culture change, DevOps. The methodologies and practices used to fully utilize cloud computing are being championed by the elite operators of Cloud Computing infrastructure. The CloudStack Collaboration Conference has a full program to help provide some of the best thinking on devops and cloud all in one place. 

Patrick Debois the man who coined the term DevOps and conducts DevOps Days worldwide will be the opening keynote at CloudStack Collaboration conference. 

Dell's Chief DevOps Evangelist and the co-host of the popular DevOps Cafe podcast will be talking about how the principles of DevOps combined with the emerging trend in Software Defined Networking(SDN) are driving the cloud. 

Hits: 42464
Rate this blog entry:
Continue reading Comments


Citrix supports the open source community via developer support and evangelism. We have a number of developers and evangelists that participate actively in the open source community in Apache Cloudstack, OpenStack, OpenDaylight, Xen Project and XenServer. We also conduct educational activities via the Build A Cloud events held all over the world.