As Containers Rise, OpenStack TripleO Slides
In the OpenStack ecosystem, change is common, but when a vendor pulls out of a project it once championed, it’s a big deal. And so it is with TripleO, the project to simplify deployment by using OpenStack as an undercloud on which to deploy OpenStack. Originally championed by HP, the project appears to be losing steam, while momentum builds for using container technology as a better way to approach the implementation of OpenStack, especially at scale.
How big is the pullback? At the community level, Clint Byrum of HP announced he is stepping down from his role as project team lead (PTL), shortly after another HP engineer, Robert Collins, former PTL and one of TripleO’s biggest original supporters, stepped down as a core reviewer. Meanwhile, HP has shifted resources away from TripleO related work, taken the HP CI region back, and has decided not to bring a second TripleO-based CI gate—needed for testing TripleO—online, due to “some stability issues.”
To some, the move isn't surprising. “If something is hard to install, I don’t think you ought to use it to install itself,” said Roland Chan, COO of Aptira.
And that's exactly the idea behind TripleO, or OpenStack On OpenStack (OOO): to use one “undercloud” OpenStack infrastructure—OpenStack bare metal (Nova and Ironic), Heat, diskimage-builder, and orchestration tools such as Puppet, Chef, Salt, or Ansible—as the foundation on which to install, maintain and upgrade “overcloud” OpenStack clouds.
It all sounds good in theory, but in practice, it’s not so simple. Because core components of OpenStack are often improved, TripleO’s dependences on those moving targets make it easy to break. In addition, lack of HA for testing and stability issues led to a change in strategy for HP.
‘Monumental shift in focus’
The wave of defections started with Collins, HP Distinguished Technologist, who recently decided to drop his core reviewer privileges and focus on making OpenStack core components more stable instead. Collins, a former TripleO PTL, wrote: “One of the things I found myself reflecting on during my break was the extreme fragility of the things we were deploying in TripleO - most of our time is spent fixing fallout from unintended, unexpected consequences in the system,” he wrote. “I think its time to put some effort directly in on that in a proactive fashion rather than just reacting to whichever failure du jour is breaking deployments / scale / performance.”
Two days later, Clint Byrum, also of HP, announced he was stepping down as TripleO PTL.
“There has been a recent monumental shift in my focus around OpenStack, and it has required me to take most of my attention off TripleO. Given that, I don't think it is in the best interest of the project that I continue as PTL for the Kilo cycle.”
Byrum suggested an immediate election for a replacement, and James Slagle of Red Hat was quickly voted in.
“Thanks everyone for your hard work up to this point,” Byrum continued. “I hope that one day soon TripleO can deliver on the promise of a self-deploying OpenStack that is stable and automated enough to sit in the gate for many, if not all OpenStack projects.
Byrum said HP had pulled the HP CI region, which the company had donated to the project for testing, due to “some stability issues.” HP won’t be adding a second region, as originally planned. His comments are telling. “Recently HP's focus for deployment has changed, and as such, some of the resources we had dedicated for TripleO are being redistributed.”
"Folks from HP involved in TripleO apparently determined that the design of TripleO was not something that they could build a robust deployment system around, and have decided to redirect resources previously working on TripleO to instead work on other OpenStack projects,” said Mirantis’ Jay Pipes, an OpenStack community contributor.
Up to now, TripleO has largely been an HP-supported project. HP even used it in its Helion release last year, despite its lack of ability to deliver HA; because everything relies on the stability of the seed VM, “if the seed VM fails, it has an impact on the undercloud functionality,” according to HP’s site. There are rumors that HP is moving to use Ansible as its deployment story instead.
Now Red Hat seems to be stepping in to lead the TripleO project. What will Red Hat’s leadership mean to the project going forward? Red Hat already has Packstack and Foreman as deployment tools.
Project Kolla, the silver lining
Meanwhile, Project Kolla, which began as a proof of concept to show that containers could be used as building blocks for deploying OpenStack—and was to become part of TripleO—has become its own tool-agnostic project.
In his note about resigning from TripleO, Collins said, “I’m super excited by Kolla - I think that containers really address the big set of hurdles we had with image-based deployments, and if we can one-way-or-another get cinder and Ironic running out of containers, we should have a pretty lovely deployment story.”
The Kolla team is moving ahead, creating three new container types: a controller node, a storage node, and a compute node, as well as a tool to build docker images from diskimage elements. “We plan to use this along with our other R&D in the area to integrate container tech into TripleO,” Steven Dake of the Kolla team wrote. “I’m not quite sure how it will all come together, but after numerous discussions with folks from the TripleO and Heat teams, I believe we can find a path forward.”
TripleO and the future
At its core, TripleO uses an image-based build system to produce 'undercloud' machine images that contain a number of infrastructure services (like databases, message queue systems, and OpenStack 'controller' services), and these resulting images tend to be quite large and inflexible, Pipes explained. “Tools like Docker enable smaller, streamlined images to be built for individual services, making the deployment system more flexible,” he said. “Projects like Kolla get this fundamental idea—that fine-grained service or application images enable a more flexible and robust deployment architecture. It's yet to be seen whether TripleO can refine its vision to accommodate containerization and adapt to this new world.”
Red Hat appears to be solidly behind TripleO still. Last month, it released version 6.0 of Red Hat Enterprise Linux OpenStack Platform with a technology preview of TripleO, and a story in eWeek said Red Hat is investing heavily in TripleO. "I think there is something really interesting and new happening with TripleO," Mark McLoughlin, OpenStack Technical Director at Red Hat, said.
"There are many OpenStack installation tools out there. The whole point of TripleO is to think beyond installation—to think about the long-term maintenance, management, monitoring and upgrading of the cloud," McLoughlin told eWeek. "TripleO provides a holistic take on cloud management.”
However, according to the article, the Red Hat preview is not recommended for production use, and “differs a bit from the upstream project in that it uses Red Hat Package Manager (RPM)-based packages, rather than just pulling from a Git code repository.”
All of that begs the question: if TripleO does move forward, will its trajectory be changing?
Meanwhile, TripleO plods ahead. There’s even a QuintupleO project, for TripleO on OpenStack, or a TripleO deployment in a virtualized environment using OpenStack APIs to create and manage instances, for those who want to use TripleO but don't have the required bare metal hardware infrastructure. “Rather than provisioning the target virtual machines directly via virsh, we would be able to use the standard OpenStack APIs to create and manage the instances,” the OpenStack wiki explains.
Why stop with TripleO or QuintupleO? SeptupleO, anyone? In what appears to be an early April Fools’ joke, Lorin Hochstein tweeted:
SeptupleO. Let's make it happen, OpenStackers. cf http://t.co/K39IFQWhNV
— Lorin Hochstein (@lhochstein) March 5, 2015Make it happen, indeed.
