 Hi, I'm Thierry Carréz. I'm from France. I'm the director of engineering for the OpenStack Foundation and also the chair of the OpenStack Technical Committee. Well, thanks for joining us today. I was hoping you could tell us a little bit more about the Big Tent. We've been hearing a lot about it. What is the Big Tent? So the Big Tent is an idea that we should have within the OpenStack community. We have a lot of different projects, a lot of different initiatives that are created within our community. The idea of the Big Tent is to consider those people being an official OpenStack project, rather than having a segregation between a blessed project on one side and the rest of the community project. These are all OpenStack projects as long as they're created by the OpenStack community using the OpenStack ways and that's what the Big Tent is about. So within the Big Tent there are core services projects. Can you tell us a little bit more about what they are and what it means to be a core services project? There are two different initiatives. From an upstream perspective we just produce OpenStack projects. The Big Tent is everything the upstream OpenStack community produces. On the other side we have the board of directors trying to come up with a base interoperability set. So what does it mean to be an OpenStack cloud? What does it mean to be powered by OpenStack? What does it mean to be an OpenStack power storage? And to do that there is an effort called DevCore which goes into defining what is the set of those core projects that need to be in every OpenStack powered cloud or every OpenStack storage powered cloud etc. So the difference between the two sets is the core services is a very smaller subset of projects and it's usually when a project has reached a level of maturity and deployment that you can basically assume that any OpenStack cloud would include those services then it becomes a core service. So this is new for the Liberty Cycle Release, this Big Tent and previously it was the Integrated Release. So could you talk a little bit about what precipitated the change from the Integrated Release to now a Big Tent style release? Sure. So the Integrated Release back in Ice House or Juno, back in Juno we were in a situation where we couldn't grow the Integrated Release anymore and we could not really make it smaller either. There was this set of projects, it was really difficult for other projects to reach the level where they could be integrated in that set of projects, the requirements were pretty high. At the same time we didn't have a great focus on critical pieces either. So the Integrated Release did not serve any purpose anymore, it was excluding other projects, promising projects, new technologies. So it prevented OpenStack from being an integration engine and we wanted to be able to integrate new technologies as they come and as long as you have this artificial barrier between projects that are blessed, part of the Integrated Release and things that are outside in the community, we could not really solve that. You could not get to the level of maturity and deployment if you were not part of the Integrated Release and the Integrated Release required maturity and deployment so you could not get there. We were basically stuck by the Juno Release and there were a number of blog posts by various members of the community on how do we solve this, how do we solve the TC being the ultimate judge of all good things in OpenStack and let multiple flowers bloom in our community. And that's where the idea of the Big Ten comes from and we switched the question from judging if a project is OpenStack to judging the community producing it. Is it part of our community? Is it us? Is it solving the OpenStack mission? Is it using the OpenStack ways? And as long as it participates in solving the OpenStack mission using the OpenStack way, then it's an OpenStack project for all means. Well, thanks for telling us more about the Big Ten and I have one more question which is, can you speculate about any changes that we might see in the Mitaka Release cycle? It's a hard one. It's a second day. There were a lot of interesting discussions yesterday at the cross-project workshop track in the design summit and questions that we never really asked ourselves before. Like, should we as a project never ever drop an API again? And it's a hard call for a developer community to make because that means you will have to maintain APIs forever. But that means you care about your users enough that you don't want to put them in a situation where they have to evolve their applications from one API version to another. And so it's a sign of maturity that we are having those discussions and the result of that discussion was that we would probably push for never duplicating an API again in the future life of OpenStack project. That's a major change. We also discussed the introduction of a common distributed block manager for OpenStack projects. So we currently have OpenStack projects are backed by databases and queue services but we don't have a distributed lock system and we emulate it using queues and databases and that's a failure. And so we discussed introducing a common distributed lock manager that all OpenStack projects could take advantage of to better synchronize data and scale better. So that's the two things that I saw emerge yesterday and I need to run to see more. Thank you so much for joining us today. No problem. Thanks.