 Hi everyone, so thanks for the introduction. So this talk is called Red Hat, this Unicode character and Python. I guess you now know what that Unicode character is. Do you all know what that Unicode character is? Is this? So this talk is called Red Hat Lost Python. So during this talk, I'd like to basically tell you about two important things about Red Hat and Python. I'd like to tell you where Red Hat uses Python, and to learn that we're really heavy users of Python for all kinds of tasks. And what is really tightly connected to that is how you as Python developers can use the upstream products or upstream projects that Red Hat contributes to and how you can use Red Hat supported products for your work, for your development, deployment and so forth. So just before I start talking about the communities and Red Hat products, let me just briefly explain how Red Hat works in case you don't know that. So we have this kind of motto that says upstream first. That means that we just collaborate with communities, all the features, all the bug fixes, go to upstreams first. So we send all these patches, we do planning with the communities, we propose new features to communities, we make an agreement with them and then we send the patches basically. If we find some bugs or some security issues, then again we first send them to upstreams. So we like to make the world a better place like this. And so at certain points at time, we just take upstream projects and basically productise them downstream. What that means is that we do some additional quality assurance, we do integration testing, we integrate different products or projects together so that we make sure that they really work well. And if we find a bug or we want to add a new feature, then it all repeats. We go to upstream, we send them patches, we discuss with them and so on and so forth. So starting with what actually made Red Hat what it is, like everyone knows Red Hat for Red Hat Enterprise Linux. So who doesn't know Red Hat Enterprise Linux? Okay, so we all know Red Hat Enterprise Linux. That's great. Who knows Fedora? Okay, so that's almost everyone. So Fedora is sort of upstream for Red Hat Enterprise Linux. That means that all the development takes place in Fedora. And at certain point at time, we just take Fedora, branch it downstream and we do some additional Q&A and et cetera, et cetera, and we create Red Hat Enterprise Linux out of it. So as I've said, we are heavy users of Python. So in Fedora, for example, we have two parallel Python stacks. We have Python 2 stack and Python 3 stack. Currently in the supported releases of Fedora, that's 2, 7, and 3, 3. And so let me just briefly skim through what is written in Python in Fedora. So we have Anaconda, which is the system installer. We have YAM written in Python, which is the package manager. We have two build system, Koji and Coper, both written entirely in Python. And as they're building back end for RPMs, they use Mock, which is also written in Python. Mock is basically a sort of change route in its own way. And the whole Fedora community, like, it uses Python for pretty much the whole infrastructure. So like, if Python disappears tomorrow, there's basically no Fedora. You can't install it. You can't install packages. We can't build packages. We can't live without Python, really. And I'm proud that I'm a Pythonist, you know, and that I can say that my distribution can't live without Python. It's so important. And so one of our plans, obviously, is to make Python 3 a default. Well, not obviously, but it is a plan. I obviously honestly think that Python 3 is better as a language, but like, we can keep that to some, you know, corridor discussion, something. So hopefully we'll be switching to Python 3 as a default in Fedora 22. So Fedora is a rapidly moving Linux distribution. We basically make releases every half a year. It goes forward. You know, it's really, everything is really rapid. And basically, Red Hat Enterprise Linux that is made out of Fedora is quite the opposite. It's really, it really moves slow. It has very long support cycle. It's very stable. It's very secure. Which can be a good thing if you have an application that you need to run for, like, I don't know, 10 or 15 years. But it's not that optimal if you want to move forward, you know. And we've also come up with a mechanism to allow people to run this super stable system, but to also go forward, you know, to follow upstream, provide new versions of Python and databases. I will be talking about that. So we currently have three supported releases of Red Hat Enterprise Linux, shortly REL. It's 5, 6, and 7. They have these Python versions. And maybe sometime in the future, we will also release REL 8. And so I guess you can sort of extrapolate from these years, like when that might be. But you can't really extrapolate the Python version, right? I personally am sincerely, honestly hoping that it will be Python 3. But, you know, there are lots of stakeholders, big companies, big players. We'll see about that. Who would like to see Python 3 in REL 8? Applause for you. I like that. Thank you. So a minute ago, I said that REL is a really slowly moving target. It's very stable. It basically doesn't change versions. Once we place Python 2.6 in REL 6, we will never update that. We'll keep with Python 2.6 forever, basically, as long as REL 6 lives. So what we came up with is a technology that's called software collections. And we're building a few of our products on top of this technology. Software collections are basically an RPM way of providing multiple versions of basically any type of software on top of RPM-based distribution. That includes Fedora, that includes Red Hat Enterprise Linux, and CentOS. I'll be talking about CentOS in a few minutes, if you don't know what that is. So software collections are a general RPM-based technology. We have sort of upstream for them that is called softwarecollections.org. And usually, if I talk to Pythonists and they ask me, so what software collections are, I usually say it's a system-wide virtual NF based on RPM. That's pretty much it. These are just packages that install somewhere under slash opt. And they have new versions of not only Python extension packages, but actually the interpreter itself. So we can provide, in this way, you can have Python 3.3 on top of Red Hat Enterprise Linux 5 or 6 or something like that. So, and the way you use software collections is basically that you run SCL enable Python, just the name of the collection bash, instead of source, then activate. So that's pretty much it about software collections. So for Red Hat Enterprise Linux, we have a product that is called Red Hat Software Collections. We first released it last year. And it basically brings fresh versions of various useful development tools on top of Row 6 and now also on top of Row 7. So what's most interesting here is that we have Python 2.7 and Python 3.3. So, you know, because, like, I'm a real Python maintainer and people from community have been coming to me and saying Red Hat is the only thing that is really preventing us from moving to Python 3. And I was always like, sorry, I can't do anything about it. Well, now I can and I did it and it works great. So Red Hat Software Collections are basically a product that is installable on top of your system. It doesn't replace your base system versions, like if you have Row 6, you will still have your Python 2.6 that is in the system. And on top of that, you can get Python 2.7 or Python 3.3 and you can also have one of these other components that are listed on the slide. And the good thing about it is that it just works. It just does. So Red Hat Software Collections are obviously a product for Red Hat Enterprise Linux and they are designed in a way that they move, like, faster than the system itself. Now, if you, for example, take Fedora, which itself is moving very fast, then for Fedora, it perhaps makes sense to create, like, communities of our collections that actually move slower than the system so that you can create more stable software on top of Fedora. So the community does build some software collections, like, I know they've been building Ruby collections for Fedora and stuff like that. So this is really general technology. You can build your own collections and it just works. So another thing that Red Hat does is cloud. I've been advised to say the word cloud at least 10 times during the presentation because, like, you know, in the past, like two years ago, when I was giving presentations, I just said cloud once and everyone was like, what? Did you say cloud? Right? Right? Now, these days, you have to say it at least 10 times so that people would actually listen. So it's not easy at all. But we have a lot of cloud. We have OpenStack. Who knows OpenStack? Okay, who doesn't know what OpenStack is? Okay, so there are some people who don't know what OpenStack is. OpenStack is an infrastructure as a service type of cloud. It's basically a huge upstream project or more likely a set of APIs that happen to have an implementation as a huge upstream open source project. And so it's, as some people talk about it as the next Linux, there's so much contributors to this project. Red Hat is there. HP is there. Dell is there. Like, lots of huge companies contributing to OpenStack and all of them think that this is really the future of cloud computing, of the infrastructure as a service type of cloud computing. So Red Hat has been the number one contributors to the last two releases of OpenStack. And so we contribute a lot to that. And of course, we also take that downstream and productize that. And we have what we call Red Hat Enterprise Linux OpenStack platform, which is basically Red Hat Enterprise Linux with OpenStack packages. So you can, like, basically you can type yum install OpenStack and it just installs OpenStack and that's it. So this type of cloud is not really useful for programmers, right? It's just like it provides virtual machines and, okay, virtual machines are nice, but what programmers really want is platform as a service cloud, right? We want, if we're creating a web-based application, we just want the cloud to set up the environment for us so that we wouldn't need to care, right? We don't want to care about databases, we don't want to care about deployment, we just want to code. And then do git push and let the cloud take care of everything else. So for that, there is another open source project that is called OpenShift. It's written in Ruby, sorry. So platform as a service cloud is really what I just explained. It basically provides some sort of environment for your application so that you can just push your source code there and it would just run. OpenShift works in a way that it has, like, there are like two important terms that one needs to understand to understand OpenShift. There are gears and there are cartridges. Gears are basically containers, like, not necessarily in the Docker sense of containers, but these are just, like, isolated runtime units that provide you some processor cycles, some memory, some storage. And then you have cartridges, which are basically languages or services. So for example, in OpenShift online, which is like an open red hatch provided instance of OpenShift, you have cartridges for Python 2.6, Python 2.7, and Python 3.3. So the way it works is that you register an application, you can even do that for free on OpenShift.com. So you register your application and you'll get, like, I don't know, two or three gears. And you say, I want this gear to contain Python 3.3 and I want this second gear to contain MongoDB. So the cloud will create this for you and then you just push your application there and it just works. So OpenShift really does this in a very good way and it also has, like, prepared environment for a Django-based application. You can actually use any web framework in OpenShift, but the Django type of applications is supported out of the box. You don't have to do any additional setup by yourself. It just works. So we have what we call OpenShift online, which is what you can see when you go to OpenShift.com. And if you actually want to run this in your data center, you can also get OpenShift by Red Hat, or it's also called OpenShift Enterprise. So you can basically deploy this in your data center and have your own platform as a service cloud. So how cool is that? Now, you can really combine all Red Hat technologies in basically any ways you can think of. So you can, like, have OpenShift that uses Red Hat software collections for some of its cartridges. You can run it on OpenStack with transom type of rel. And I guess what I want to say here is that nothing of this would be doable without Python, right? It's basically Python throughout the whole stack, no matter what you want to do. It's just there. It's everywhere. So I just said that OpenShift online uses Red Hat software collections for some of its cartridges. So what that means is that you can reproduce the same environment that you have in cloud on your rel.6 or rel.7 system, which is quite cool for developers because you can get rel.6 or rel.7 on your development machine. You can get Red Hat software collections, which you basically get for free with Red Hat Enterprise Linux. And you can just start coding, then push your code to the cloud, and everything just works. So doing this, you can get your applications running for free in cloud in a matter of, like, a few hours, basically. And of course, that's not all. Like, Red Hat uses internally and externally lots of other upstream Python-based projects or projects that rely heavily on Python. So for example, what we use, we use Beaker, which is used for hardware integration testing. We use SPALP, which is software repository management. This is like kind of you can create a server that basically will serve all your machines in your data center with YAM updates. So you, like, if you want to do security updates of all of your machines in your data center, you don't need to, like, download the package 100 times. You just download it once to your PALP server, and it distributes the updates to all the machines, all written in Python. We are also a heavy contributor to Gluster FS, which is a distributed file system, which itself is not written in Python, but really uses Python for lots of, it's like utilities around the core itself. Fedora infrastructure, for example, is a heavy user of Ansible, which is an automation tool for sysadmins. Basically, you can say, like, I have a basically a recipe that describes how a system should be created and booted up, and you just pass it to Ansible, and it just does the stuff for you. And we also have quite a fresh project called Dev Assistant, which is, like, my pet project, so I just had to write it there, although it's, like, a bit smaller than the others. But it's supposed to be what Ansible is for sysadmins. Dev Assistant is supposed to be the same for developers. Also, entirely written in Python, so basically you write some recipes, how, let's say, a project should be created, and you give it to someone else, and he can just create the project the way you created the recipe. So kind of like this. And I promised I will also speak about CentOS. So there has been some confusion about what CentOS actually is. Do people know what CentOS does or how it, like, comes to being? Do you know anything about CentOS? Who knows? Who doesn't? Okay. So there are some people who don't. So CentOS basically is a community rebuilt of Red Hat Enterprise Linux sources. What that means is we have Fedora, which is moving fast forward. We have Feral, which is very stable. And some people thought, yeah, okay, we need something that people don't have to pay for, but it's also stable, and it's like REL. So people from CentOS community just basically take REL sources and rebuild them and provide them for free. Just like, okay, so you can get like REL for free. You don't get Red Hat support with that, but it can be good for testing or something like that. So, and the way I like to talk about it is that it's community platform to run community projects. So like, you can get it for free and it's not moving forward as fast as Fedora. So people from like this big projects like RDO, which is basically OpenStack packaging project so that you can install OpenStack easily on downstream distributions, or Gluster FS like to use CentOS for their development because it's very stable and their environment is not changing so rapidly. So this is pretty much everything from me. I guess that the whole message that I'm trying to send here is that Red Hat is really grateful to people in communities that make all of this possible. So really, if there is an applause at the end of this presentation and I hope it is, it really goes to you people who work in communities and make this all possible. So thank you. I think we've got time just for maybe one question. If anyone wants to ask a question? No? Okay, so if you think of anything, just approach me somewhere, just ask away. Okay, so thanks.