Red Hat loves Python
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Kabrda, Slavek
Slavek Kabrda - Red Hat Loves Python Come learn about what Red Hat is doing with Python and the Python community, and how you can benefit from these efforts. Whether it is the new Python versions in Red Hat Enterprise Linux via the new Red Hat Software Collections, compatible Python cartridges in OpenShift Platform-as-a-Service (PaaS), or being the leading contributor to OpenStack, there's a lot going on at Red Hat. We're Pythonistas, too!
 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? Can you check? Is this? So this talk is called Red Hat Lost Python. And 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, until you learn that we are 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 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. And so we like to make the world a better place like this. And so at certain points at time, we just take upstream project and basically productize them downstream. What that means, 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? OK, so you all know Red Hat Enterprise Linux. That's great. Who knows Fedora? OK, so that's almost everyone. So Fedora is sort of abstract. 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 Koper, both written entirely in Python. And as they're building back end for RPMs, they use Mock, which is also written in Python. This is basically, 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 is 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, 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. Not obviously, but it is a plan. I obviously honestly think that Python 3 is better as a language, but we can keep that to some 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 distributions. We basically make releases every half a year. It goes forward. 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 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, I don't know, 10 or 15 years. But it's not that optimal if you want to move forward. And we've also come up with a mechanism to allow people to run this super stable system, but to also go forward, to follow upstream, provide new versions of Python and databases, I will be talking about it. So we currently have three supported releases of Red Hat Enterprise Linux, shortly REL. It's five, six, and seven. They have these Python versions. And maybe sometime in the future we will also release REL 8. And so I guess you can 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 there are lots of stakeholders, big companies, big players. We'll see about that. Who would like to see Python 3 in REL 8? A 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 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. And the way you use Software Collections is basically that you run sl-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 developer and system-in-tools on top of RL6 and now also on top of RL7. So what's most interesting here is that we have Python 2.7 and Python 3.3. So because I'm a RL 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 RL6, 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 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 communities of third 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 in the past, like two years ago, when I was giving presentations, I just said Cloud once and everyone was like, what? Did he say Cloud? Great. 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? OK, who doesn't know what OpenStack is? OK, 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 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 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. It's just like it provides virtual machines. OK, virtual machines are nice. But what the programmers really want is platform as a service cloud. We want, if you'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. 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 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, not necessarily in the Docker sense of containers. But these are just 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 your application. You can even do that for free on openshift.com. So you register your application and you'll get 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 a 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 have OpenShift that uses Red Hat software collections for some of its cartridges. You can run it on OpenStack with transcend of the frail. And I guess what I want to say here is that nothing of this would be doable without Python. It's basically Python is 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 REL6 or REL7 system. Which is quite cool for developers because you can get REL6 or REL7 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 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 if you want to do security updates of all of your machines in your data center, you don't need to download the package 100 times. You just download it once to your PULP 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 its like utilities around the core itself. Fedora infrastructure, for example, is a heavy user of Ansible, which is an automation tool for CIS admins. Basically, you can say like, what's the CIS admins, 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 CIS admins. 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, or do you know anything about CentOS? Who knows? Who doesn't? OK, so there are some people who don't. So CentOS basically is a community rebuilt of red data enterprise Linux sources. What that means is we have Fedora, which is moving fast forward, we have RHEL, which is very stable. And some people thought, OK, we need something that people don't have to pay for, but it's also stable, and it's like RHEL. So people from CentOS community just basically take RHEL sources and rebuild them and provide them for free. Just like, OK, so you can get RHEL for free. You don't get redhead 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 a community platform to run community projects. So you can get it for free, and it's not moving forward as fast as Fedora. So people from this big projects like RDO, which is basically OpenStack packaging projects so that you can install OpenStack easily on downstream distributions, or GlastroFS 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 for me. I guess that the whole message that I'm trying to send here is that redhead 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. APPLAUSE I think we've got time just for maybe one question. If anyone wants to ask a question? No? OK, we'll start. OK, so if you think of anything, just approach me somewhere, just ask away. Thanks. APPLAUSE
 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?  Can you check?  Is this?  So this talk is called Red Hat Lost Python.  And 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,  until you learn that we are 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 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.  And so we like to make the world a better place like this.  And so at certain points at time, we just take upstream project  and basically productize them downstream.  What that means, 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?  OK, so you all know Red Hat Enterprise Linux.  That's great.  Who knows Fedora?  OK, so that's almost everyone.  So Fedora is sort of abstract.  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 Koper,  both written entirely in Python.  And as they're building back end for RPMs,  they use Mock, which is also written in Python.  This is basically, 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 is 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,  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.  Not obviously, but it is a plan.  I obviously honestly think that Python 3 is better  as a language, but we can keep that to some 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 distributions.  We basically make releases every half a year.  It goes forward.  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 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, I don't know, 10 or  15 years.  But it's not that optimal if you want to move forward.  And we've also come up with a mechanism to allow people to  run this super stable system, but to also go forward, to  follow upstream, provide new versions of Python and databases,  I will be talking about it.  So we currently have three supported releases of Red Hat  Enterprise Linux, shortly REL.  It's five, six, and seven.  They have these Python versions.  And maybe sometime in the future we will also release REL 8.  And so I guess you can 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 there are lots of stakeholders, big companies,  big players.  We'll see about that.  Who would like to see Python 3 in REL 8?  A 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 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.  And the way you use Software Collections is basically that  you run sl-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  developer and system-in-tools on top of RL6 and now also on  top of RL7.  So what's most interesting here is that we have Python 2.7  and Python 3.3.  So because I'm a RL 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 RL6, 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 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 communities of third 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 in the past, like two years ago, when I was giving  presentations, I just said Cloud once and everyone was like,  what?  Did he say Cloud?  Great.  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?  OK, who doesn't know what OpenStack is?  OK, 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 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 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.  It's just like it provides virtual machines.  OK, virtual machines are nice.  But what the programmers really want is platform as a service  cloud.  We want, if you'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.  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 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, not necessarily in the  Docker sense of containers.  But these are just 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 your application.  You can even do that for free on openshift.com.  So you register your application and you'll get  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 a 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 have OpenShift that uses Red Hat software  collections for some of its cartridges.  You can run it on OpenStack with  transcend of the frail.  And I guess what I want to say here is that nothing of this  would be doable without Python.  It's basically Python is 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  REL6 or REL7 system.  Which is quite cool for developers because you can  get REL6 or REL7 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 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 if you want to do security updates of all of your  machines in your data center, you don't need to download  the package 100 times.  You just download it once to your PULP 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 its like  utilities around the core itself.  Fedora infrastructure, for example, is a heavy user of  Ansible, which is an automation tool for CIS admins.  Basically, you can say like, what's the  CIS admins, 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 CIS admins.  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, or do you know anything about CentOS?  Who knows?  Who doesn't?  OK, so there are some people who don't.  So CentOS basically is a community rebuilt of red  data enterprise Linux sources.  What that means is we have Fedora, which is moving  fast forward, we have RHEL, which is very stable.  And some people thought, OK, we need something that people  don't have to pay for, but it's also stable, and it's like  RHEL.  So people from CentOS community just basically take RHEL  sources and rebuild them and provide them for free.  Just like, OK, so you can get RHEL for free.  You don't get redhead 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 a  community platform to run community projects.  So you can get it for free, and it's not moving forward as  fast as Fedora.  So people from this big projects like RDO, which is  basically OpenStack packaging projects so that you can  install OpenStack easily on downstream distributions, or  GlastroFS 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 for me.  I guess that the whole message that I'm trying to send  here is that redhead 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.  APPLAUSE  I think we've got time just for maybe one question.  If anyone wants to ask a question?  No?  OK, we'll start.  OK, so if you think of anything, just approach me  somewhere, just ask away.  Thanks.  APPLAUSE
Slavek_Kabrda_-_Red_Hat_Loves_Python_0_83.png Slavek_Kabrda_-_Red_Hat_Loves_Python_84_167.png Slavek_Kabrda_-_Red_Hat_Loves_Python_168_311.png Slavek_Kabrda_-_Red_Hat_Loves_Python_312_383.png Slavek_Kabrda_-_Red_Hat_Loves_Python_384_2075.png Slavek_Kabrda_-_Red_Hat_Loves_Python_2076_3119.png Slavek_Kabrda_-_Red_Hat_Loves_Python_3120_3443.png Slavek_Kabrda_-_Red_Hat_Loves_Python_3444_3503.png Slavek_Kabrda_-_Red_Hat_Loves_Python_3504_3551.png Slavek_Kabrda_-_Red_Hat_Loves_Python_3552_4151.png Slavek_Kabrda_-_Red_Hat_Loves_Python_4152_4811.png Slavek_Kabrda_-_Red_Hat_Loves_Python_4812_5987.png Slavek_Kabrda_-_Red_Hat_Loves_Python_5988_8567.png Slavek_Kabrda_-_Red_Hat_Loves_Python_8568_8615.png Slavek_Kabrda_-_Red_Hat_Loves_Python_8616_11651.png Slavek_Kabrda_-_Red_Hat_Loves_Python_11652_14087.png Slavek_Kabrda_-_Red_Hat_Loves_Python_14088_17147.png Slavek_Kabrda_-_Red_Hat_Loves_Python_17148_20711.png Slavek_Kabrda_-_Red_Hat_Loves_Python_20712_23015.png Slavek_Kabrda_-_Red_Hat_Loves_Python_23016_25379.png Slavek_Kabrda_-_Red_Hat_Loves_Python_25380_27743.png Slavek_Kabrda_-_Red_Hat_Loves_Python_27744_33479.png Slavek_Kabrda_-_Red_Hat_Loves_Python_33480_33779.png Slavek_Kabrda_-_Red_Hat_Loves_Python_33780_33863.png Slavek_Kabrda_-_Red_Hat_Loves_Python_33864_34163.png Slavek_Kabrda_-_Red_Hat_Loves_Python_34164_34235.png Slavek_Kabrda_-_Red_Hat_Loves_Python_34236_34523.png Slavek_Kabrda_-_Red_Hat_Loves_Python_34524_34931.png Slavek_Kabrda_-_Red_Hat_Loves_Python_34932_35003.png Slavek_Kabrda_-_Red_Hat_Loves_Python_35004_35051.png Slavek_Kabrda_-_Red_Hat_Loves_Python_35052_35111.png Slavek_Kabrda_-_Red_Hat_Loves_Python_35112_35171.png Slavek_Kabrda_-_Red_Hat_Loves_Python_35172_35179.png