 Hello, my name is Troy Toman. I'm the Vice President of Cloud Infrastructure at Rackspace. Rackspace is a hosting company that provides hosting services to our customers on both dedicated gear, private clouds, and public clouds. And we really focus on our service and the ability to offer that in a consumer way for our customers. So doing continuous delivery in an infrastructure product has been a real learning experience for us over the last couple of years. A lot of established best practices focus on continuous delivery with multiple deployments a day. But they typically are user-oriented websites or things that are easier to build that in. And when you're talking about running infrastructure on a large scale, and in our case, it's literally hundreds of thousands of virtual servers, thinking about continuous delivery, we had to take the concepts and do things a bit differently. I think also when OpenStack was first put together, it was a very release-minded approach about thinking about deliverable products every six months. And so what we've been trying to do is take our learnings of trying to pull from trunk on a regular basis. And right now, we pull from trunk once a day. We try to deploy every one to two weeks. So we're not doing anything like multiple deployments a day yet. But as we learn through that process, what we've been doing is working with the community to adapt their processes to move to the monthly milestones, to think about doing automated tests off of trunk on a regular basis to make sure that changes going into the process aren't breaking trunk, and to basically sort of work cooperatively to make continuous deployment an easier process, not only for rack space, but really for anybody in the OpenStack community. I wouldn't say we've been able to quantify, you know, with real discreet numbers what the benefits of continuous delivery are, but I think what we feel is in our ability to move things into production in a faster way. So in particular, we're seeing features that came in with Grizzly. We were running months away from waiting from the actual Grizzly release. And so it allows us to either move new features in without having to wait for the rest of the community to catch up in a way that might need our particular use case, or because we're running at such an extreme scale, which is not common, we often run across bugs or issues within the code and bottlenecks that need to be fixed that we can then fix in trunk and pull down into our environment and not need to maintain a separate fork. And that was really important for us. What we didn't wanna do is get in a situation where we felt like rack space had to run in a different version of the code than the community was working on. And by the fact that we're pulling from trunk so regularly, we can actually let our developers work upstream in trunk on a regular basis and pull that into our production environment and not have to worry about making bug fixes or changes in say a local rack space branch and then figuring out how to push them up later. So it really allows us to stay on the leading edge and stay in the community and not get too far separated from what the rest of the community is doing. And so I think we're many ways we're exploring new territory, but I think that's the exciting thing about being in an open source project is it's not the perspective of just rack space. It really is rack space and Dell and HP and cloud scaling and piston and Nebula sort of all coming together and providing these different points of view and we're finding the right way to bring those into something that we probably wouldn't discover on any one company's turf. And so that's the amazing part of it. And there's a lot more to do, but really excited about the pace at which we've progressed over the last several releases.