 Hi, thank you for attending to the talk. I'm Adam, and as a member of R&D team, I've been building clouds in OVH for four years now, and I would like to share our experience as a public cloud provider, especially what dilemma it brings in case of staying close to the upstream code. But first let me give you some context, who we are. In OVH, we do a lot of cool things. For example, we build our own data centers, cooled with water. Today we have 20 data centers all over the world, and six more are being built as we speak. The data centers are connected with our own fiber network. We total bandwidth 11 terabits per second, and 32 points of presence. Owning all the hardware and network, we provide various cloud services, including public cloud based on OpenStack. Today in production we have around 150,000 instances, 100 petabytes of object storage, and more than 10 regions. DevOps culture is deeply encoded in OVH DNA. That's why we are not just OpenStack operators, because we really like to dig into OpenStack code. And we do all of that in the pursuit of happiness of our customers. As a public cloud provider, we exist somewhere between two words. A word of customers and word of OpenStack. On one hand, we want to make our customers happy by ensuring stability of our services, and providing cool new features quickly, because this is essential to our business. But on the other hand, we want to be happy operators. We want to maintain and be able to upgrade OpenStack to new releases easily. And to get all the support OpenStack community gives. So how do we solve this dilemma? Let me show you two workflow scenarios. The first scenario is easy and very tempting. We could just respond to our customers' needs directly and very quickly, and develop all the features by ourselves. Let me present how it looks like in word of Git. Here we have some branches for an OpenStack project. It could be Nova, Neutron, et cetera. We have a master branch and a branch for release number one. Let's assume we've installed release number one in production. While operating the release, we'll get the feedback from our customers, and to satisfy their needs, we start developing new features for the release. And we are 100% focused on that. In the meantime, the community has been working on new releases, and we see that our work is drifting away from upstream. What's more, release number one is quite old now, so we would like to move to release number four. But we would like to move there with all the features we developed before. Finally, we end up in a situation where it's hard to do anything. It's hard to move the features from older branches to newer branches. It's hard to upgrade OpenStack, and it's hard to propose anything to the upstream. So as we can see, this approach may work, but only in the short term. Providing the new features is easy and fast, but in the long term, we would have to maintain a fork of OpenStack. And as operators, we would just cry. Number two is a bit different. We try to find the balance between keeping up with upstream and meeting our customers' expectations. Let's get back to our branching model. This time, we will create and keep local branches, which mimic OpenStack branching model. The local branches will additionally include all the features developed by us. We want the local branches to follow upstream closely. That's why we will pull from upstream, from time to time, and resolve all the conflicts. The main idea is to develop all the features, not in current release branch, which is in production, which is in scenario number one, but on our local master branch. Thanks to that, we can port the changes to any release we want, and the changes will be also available for the future releases. Another big advantage is that patches are almost ready to be proposed to upstream. Since our local master branch follows the upstream master. Not all the patches are upstreamable, but it's not a problem because they can still live only in our local branches. This approach may be a bit harder. In the short term, but in the long term, we get a couple of benefits. If our patches get merged, we are not along with the code anymore. They will live in upstream and be maintained by more people. As OpenStack DevOps, it enables us to check what's going on in the upstream more often, and to work with the community more closely. For example, we can report and fix more bugs, which affect upstream. We also get the flexibility of choosing which release we want to deploy in production, because basically all the developed features are ready for any release. Of course, it's not a perfect solution. We all know that pushing a patch to upstream is not always easy and may take a long time. Let me give you an example. We developed a patch that brought us an interesting feature, and it took us about three days to code and deploy in production. We submitted it to the community, and three months later, its implementation was still in discussion, while it was working well for us in the production for the past three months. Unfortunately, that's why sometimes we have to give up and stop pushing the change, which will still exist in our local branches. Our customers demand features, and that needs to be answered quickly. That's why we can't afford to spend too much time on pushing that. Anyway, we think it's always worth trying to propose our patches to the OpenStack community, because they can be merged to upstream and be supported by the community. And on the other side, the community can get a new contribution. It may be a bit harder, but in the end, it's a win-win situation. That's why I recommend us to all of you. Thank you.