 Hello, my name is Daniel Jaff. I'm working for Deutsche Telekom and would like to welcome you to my talk about vanilla and distributions and how they differentiate. So, let's start. What means vanilla in this context? I would define this for this talk as upstream without any private changes and it's taken from obviously Git in this case or from some release packages. But it's important there are no private or propriety changes within. So, sounds great, right, in general. But let's take a deeper look onto that. If you start for your organization with evaluating if you probably choose vanilla or distribution you should, you know first what your requirements are really and what's your use case. So, you may consider topics like which top feather you need. In this case, simply I would say open stack and obviously you also need storage and in my presentation I assume here to use Zephard and you need a basic operation system including stuff like the kernel and the hypervisor and so on. And you should also know which specific components you probably need in your project from OpenStack. And also what kind of features for example from Ceph like Ceph S or which SDN controller you need or which hypervisor you want to use and probably also which API versions of whatever. And for sure there are also types of operational requirements you have in an organization like do you want to use CI CD or topics like automation and for sure also topics like all the management of release cycles, updates, upgrades. If you have requirements for special SLAs in your organization and for sure also topics like support for your cloud. That means internal and external support. But you also have always topics like constant efficiency and probably also legal topics. I come later to that. The second point you should consider is your organization itself. And I have to say even with full automation of your stack you absolutely need experienced operators and for sure also very likely developers. Our experience is that without that you can't use vanilla. And you maybe also need to change the mindset of the existing people depending on how old your company is, what the operators and developers did before. And you for sure need also to change a lot of processes. Another topic you need to consider as the community if you use vanilla. And you need to think about how to fix bugs you find and how to add features you have and which are not implemented currently upstream for example. It's very easy, you should simply participate in the community. That would be with vanilla the only way to do it. And that means you report your bugs and your findings and you report also what you need, your missing features. You open blueprints and simply get feedback and you also start reviewing stuff that other people do. Without that you will fail with running and vanilla OpenStake. But what then? So typically open source developers do either what they are interested in or what they are paid for. So if you, that's applies to the most of the open source communities. So if you have a bug and nobody of the upstream developers are interested in this topic or don't see the problem then you probably very likely end up and doing it yourself. So you need to be prepared that you may fix or implement the stuff yourself otherwise probably nobody will do it if it's not attractive enough or somebody has the same problem as you and is paid for fixing it. So with that in mind let's take a deeper look onto the components. First on OpenStake we have these six core projects, core services which are really mature and also widely adopted in many environments that's Swift, Keystone, Nova, Neutron, Synder, Glance, you all know it. But besides that there are some optional services which are not fully mature which are simply not considered core services for that and are not that widely adopted. You may ask why this list is that short that simply because these are packages that are really projects that are supported by distributions at least by the distributions I checked. So if you would discuss about OpenStake then the question is always automation. One option would be write your own. Yeah, you can do it sure but only if you want to end with an epic fail because for sure you can't write that on your own and with each other update you will stuck with adapting stuff and changing stuff and from our experiences that likely ends in a big fail and you stuck with the version you have. So what does the community, the most of the, at least as our experiences is Ansible, Puppet and Chef currently or Croba and that is the most of the stuff that's done so do you maybe ask what about fuel and chujul? Yes, it's maybe also an option from my experience if you use Miranthus or Canonical because 96%, 69% of the code is from these companies so it's probably the best you stick at least for chujul with Canonical and probably also for Miranthus with fuel. But even then, if you take the automation from the community you probably even then end with code that doesn't fit you and it's maybe something missing or it's not applying to your automation or to your environment. So it can also happen that you take a lot of time or need a lot of time to even bring up your cloud environment and I have, for the most people that did automation and our environments on our own or did use Vanilla it took at least a half a year to get it running for a news case so and you maybe stuck longer with the release of OpenStake than you think. So especially if you have to fix automation stuff on your own and do a lot of stuff on your own. And very likely that means at the end that's a lot of work for yourself. So let's come to Ceph and Ceph you have at least two parts that are really mature, that's Rara's block devices and this Rara's gateway object storage interface. These are considered as mature and the other one is Ceph of S that's not that mature but it's on the way to be enterprise-worthy. So what about automation of Ceph? I can only say check what I said before so it's applying again don't do it yourself. And then you can choose from either self-deploy or you could use Ansible Puppet and Ceph that's what it's available in the community. Yeah for sure it's also true, but that is what the community is mostly doing. So what are the alternatives to using Vanilla? It's simply using one of the distributions. I choose here for the presentation, Rattat, Susie and Mirandis and Ubuntu, meaning Canonical. I left every other like HP solutions out of that. So the question is what is the preferred solution for your company? So usually I would say if you are only for example in Rattat shop it's probably Rattat so but if you are free to choose you should take a deeper look on the distributions. So let's take a look on Rattat. For the OpenStake stuff, they have a product called Rattat OpenStake platform, it's version nine and it's coming with MetaCar and it's based on their Enterprise Linux version 7.2. And the kernel version on this product is 3.10 but don't take it wrong, that is not an old kernel. That is probably, there are a lot of patches than a high number of patches. So for enterprises it's not always needed to have the latest greatest bleeding edge kernel. So it's from the number and old kernel but there's a lot of features from newer kernel versions. And the available hypervisors are KVM, vCenter, ESX and Docker via OpenShift. If you use this solution you're stuck with that or you have to use one of these. For deploy event they use OpenStake director with triple O and Ansible. You have also the opportunity to use PecStake instead but it's recommended to use the OSP director for that. If you take a look on what's really supported in with an OpenStake from this distribution from Red Hat it's that is true for all of them. The core services are all supported. Six core services are all supported by all distributions but they differentiate by what they support otherwise. So with Red Hat it's only Silometer, Heat, Horizon, Orionic and Sahara as will be supported to get full support. And for the gray runs you get a technical preview so it's probably maybe fixed if it's important to get it for the next release ready but you also have a set of services that are currently not supported with the product. Fuel is only in general only supported currently by Miranta Soy that's very clear but from the rest the most of them are also really services that have a very low number of maturity and so one or two in the papers and that's probably the reason why they don't support it. The life cycle of the product is that they provide packages for every upstream release. So the next one will be Newton obviously because they currently support Metaka and so you can get an update with every version and there are additional products recommended as I said before OSP directors as one of them. Satellite is also recommended to manage a lot of stuff around the products and cloud forms. Let's take a look on support. That's very different between all the distributions and Red Hat supports in the first year you get full support. That also means you probably get a new feature if you agree on it and get a lot of updates but in the additional two years they say you still get support for bug fixes basically. So if there are bugs you get a fix but you don't get back port for driver or packages and no install updates. I said before one topic is always cost and here the pricing is based on socket pairs and machines and as with all the distributions it highly depends on what you are kind of support you want. Do you want to have only support within the business hours or do you want to have 24 seven or do you want a special SLA and very short reaction times. So and it also depends in this case on if you are running real guests in your system or not. So I didn't put any numbers on that because it's really hard to compare and to be honest the default prices are usually not that what you pay at the end. So if you are interested in prices go to Red Hat, Susie and whatever and us. If you take a look on Ceph they provide providers called Red Hat Ceph Storage. It's version two and it's basically a jewel release also based on rail or you have to choose you can use Ubuntu 16.04 for that. That's deployed via Ansible or via Red Hat Storage Console. Ceph FS is available but only as a technical preview and it will be supported in next release probably. It's planned at least. Pricing I said that partly before it's based on yearly subscription and it based on raw capacity with a load limit. You can't have really large nodes. There's a limit in it and but it's raw capacity. It's you can discuss if that's what you want. So you need to decide it on your use case if you have a lot of storage there and it's not full then it's probably a little bit expensive. And there's also a pre-production subscription available for a low price you can use and can test it and you will still get support. Let's take a look on Susie. The OpenStack product, at least the version announced today was OpenStack Cloud 7 and it's coming with Newton and it's based on the latest SP2 from Slash 12. And the kernel version here is 4.4. They switched from SP1 that was 3.13 or so. Switched with the new release to 4.4. And you have a high number of hyper-wise supported. It's KVM, it's Zen, Hyper-V for Windows, VM Bear. It's also IBM set VM and it's Docker. The automation is done via Krober and Chef and the services supported are these. The difference to Rated in this case is also that they support basically Magnum and Manila but Ironic is only a technical preview and they also support Tempest. The life-cycle management or the product life-cycle from Susie is different to all the other distributions. They only take every second upstream release and concentrate on making that stable and providing a stable product and then jump over one and it's supported to switch between and they make sure that you can switch between them so the next release will be release in this case. There are also a list of recommended tools in this case, Susie Studio for example, to build appliances and Susie Manager and for KVM and Zen instances that are not cloud-ready you can also have these less high extension that's basically handling old, not cloud-ready applications and make them high already, HA already, sorry. The support is at least 27 months, it's a strange number, right? So it's two years and three months after the product released. From the pricing, you have different prices for a control node, for an admin node and you have the compute nodes that are like with Red Hat, a socket pair based so if you have more than two sockets in your machine you have to pay another subscription and it's also depending on the type of availability of the support services. With SEV, we have the Susie Enterprise Storage Solution and it's also based on Jule and is using a Calamari as a front-end to monitor it and it's deployed either through CROBA or in the future it will be deployed via Salt but that's currently also a technical preview. Features in this case are also like with Red Hat, ZFFS as a technical preview and there's also an ISCSI gateway to connect Windows VMs or VM-ware VMs to your ZFFCLOS node. Pricing is a little bit different to the other ones. Here you have a set of basic subscription and then you pay for additional nodes. There is one difference to all the other distributions if you have features that you need that are upstream features that go upstream, you don't have to pay for them. If you agree with them, it's part of the subscription so every other distribution probably shards you with whatever it is per mandate implementing and doing it but Susie says that's all included in the subscription because all other users or customers of us will also have something from it and then so you don't need to pay. So let's take a look on Mirantis. They are also based on VTACA but they are the only distribution that don't maintain on basic OS or on base OS. So you can choose between for the controller nodes is only Ubuntu, either 14.04 or 16.04 and for compute nodes you can choose between Ubuntu, RAL, Oracle and Susie. Not sure if that's very common to run different base OS in your cloud but you can choose it that there are cases where our customers need that. The corner base basically depends on the base OS and the supported hyperwizards are KVM, ZAN and VMRARE. Deployment via a fuel, I said it before and the list of supported packages are these. They basically also support Moran what's one of their projects basically and they have no packages which are considered technical preview and not fully supported. Life cycle as this read had every upstream release was in one or six between one and six months after release and the next one will be with Newton in the next year. It's recommended to use the stack light for monitoring and so on and probably the partner catalog they provide for stuff like billing and so on. They supported three years their product and the pricing depends on your base OS basically. So for Ubuntu it's per machine and for RAL it's per socket pair and I guess it's the same for Susie but there was no information on that so with Ceph it's a little bit different to the R1s. It's part of the OpenStack distribution not of the base OS and currently it's Hammer. Ceph Hammer with Ubuntu and it will also be in the next release. So it's a little bit older. It's one stable release behind what the R1s are using and deployment also via a fuel token and due to the fact that it's Hammer it's only RBD and RALS gave it a support. So it notes with Ceph's support. Pricing is for Ceph based on gross capacity. So let's come to Ubuntu. The OpenStack product is also Newton based and it's Ubuntu 1604 and the kernel is S now with Susie 4.4 based and the hypervisors that are supported are KVM, Hyper-V and LXD. So let's, I have to say, let's get one thing out of the way. The canonical OpenStack solution is probably not what you expect to be the same as the Ubuntu OpenStack. That's very confusing or is often confused by people that saying Ubuntu is widely used and the product is widely used. But in fact, between the most upstream developers, it's the community version that is used. So the enterprise version is basically using also Juju and Mars while the most community developers are using probably DevStack, Puppet, Enzymil or Chef to do their product. So if there are numbers in some poll to check how many users are using Ubuntu, that's probably not the same as using the enterprise product. The supported services from the additional services currently only Cylometer and Horizon are really supported. Probably surprising for some people. The other ones, most of the other ones are unsupported as technical preview. So it's not fully supported for production. Life cycle is every upstream release and the recommended product is Lenscale for system management and security compliance and auditing and the support, to be honest, I find it really complicated. Generally, the LTS version is five years supported but within the LTS release, you can have updates or have new OpenStack releases. But these are only then one and a half years supported and even if you are on an LTS version, at the end of the lifetime of the LTS version, you get an update to the OpenStack version that's part of the next LTS and that's then three years supported. So I don't know, it's a very complicated matrix to find out what really is currently supported with the product and how long is it supported. The pricing is per node and year or per VM and hours. They have a lot of different models or per OpenStack regions if they are small or large, medium and so on. And as with the others, it's highly depends on what kind of support you want. With SAF, they provide a product called Ubuntu Advanced Storage with Joule and a tool called Ubuntu Performance Dashboard to check what's going on on the cluster and see where you have performance problems probably. The pricing is based on used capacity. Sounds nice. In general, from my point of view, you have three potential issues. Landscape and Ubuntu Performance Dashboard have a non-open source license as a proprietary license. So whatever happens when canonical goes bankrupt or something like that, or probably it's an even compliance problem for you. So you should know that. And the other one is the kernel and I would say it's at least a controversial integration of CFS. You probably followed the discussion in the community, built your own opinion on that, it is at least controversial. So there are probably problems for you. So let's take a look on how would you assess which distribution can provide support for your project, for your cloud environment? So marketing, just kidding. Retoric question. So if you are lucky, you made your own experiences. So if you are already probably a Ubuntu shop or a ASUSU or a Red Hat then you probably stick to that and you know what you get. Or you know somebody that can say that's good or that won't work or whatever. So if you have a lot of time or at least have some time and have the resources, I would really recommend evaluation of the products and do a POC. All of them provide their enterprise product for at least 60 days or so to download and test it and get all updates. So use it, install it and make your own experiences with that before you stick one with one. Because I have to say, everybody says it's probably easy to switch from one to another or from vanilla to a distribution, but that's not true. So it's not very easy to fix. If you have something in production, you don't change that easily. So another indicator would be to probably take a look on what is the contribution of these distributions to the core components of your project. So probably on OpenStack, on CIF, KVM, Kernel, whatever. I put some numbers together. Let's take a look on OpenStack. These are the commits between the Grizzly and the current O-release or upcoming O-release for the core projects. As you can see, currently Red Hat bit the most and Mirantes is coming up. The other ones depends on, looks the same for the selected OpenStack optional projects. In this case, yeah, build your own opinion. I also took a look on how many reviews are done. So for me it's also important that if you don't, you should also participate in bringing the project forward. And one of that would be to review bugs or to do reviews. And that's the numbers from the core and the former optional projects. To be honest, it still looks the same. The only difference is the bug-fixed ratio. I checked how many bugs are opened by the distribution and how many are fixed. It doesn't mean that they fixed what they opened, but you get an idea on the behavior of the distribution. If they only open bugs and wait for it, that somebody in the community is fixing it or if they are going and fixing. I also took a look on documentation and translations. That's one of the numbers. And surprisingly here, Susie is really concentrating on that and bringing forward the project documentation. If you remember some years ago, the documentation really sucked. And at least they are doing this work, reviewing, checking what is missing and what's wrong and fixing it. So let's take a look on Seth. It's the same colors, but it looks a bit strange as well. As you can see, you only see currently Miranda, Susie and Redhead. Obviously, I mean, it's a Redhead project. The numbers for Redhead are from Ink Tank and Redhead together. So there are some competes from Canonical, it's 28. Over all the time, over the complete project. Let's take a look on the kernel. That's for all the kernel releases, for the standard kernel releases and the standard Linux 3. That's generated from the tool that's used by the community for making the release informations together and who contributed how much. So here, you obviously see that Susie and Redhead are the most active, but also even Miranda's contributed. What I did is I checked out all the stable trees and checked if there is something different because I expected if you have an LTS kernel for distribution ever, you stick for some time with that and you probably hit the box and you need to fix it. So I checked it, but to be honest, it makes no difference. It's still the same behavior. And if you take a look on KVM and LibWord, in this case, it's LibWord and QEMO Git repositories because KVM is already in part of the kernel. So that's called by that and it looks the same. So I'm at the end of my presentation. You can download the presentation from GitHub and simply scan the QR code and yeah. I'm open to questions. Could you take a microphone or so that's to get it on the video stream? Is there a microphone for the audience? Yeah, then say it and I repeat it. Just comment. It's serious. The contribution is serious from Canonical Ubuntu when it comes to packaging, preparing Debian packaging while they haven't included the support of so many non-core OpenStack services in their distribution. Question is what is supported, right? I mean, if you pay support, the real question for you as a distribution is what is really supported and that's in here. So yes. Yeah, another question. So have you compared the installation? Do you have a firsthand experience, time, complexity, anything? So I would recommend to check the presentation from Florian Haas from Tokyo for that. I didn't do it again. That was basically evaluation and it was not what, how long one needs and what's good. So he did a very good presentation on that and I would recommend to check that, this one. Politically correct, we use Ubuntu. Canonical, Canonical, yeah. We are using Canonical. At least for the project I'm working in but there are parts in the company that are using Huawei as you heard before was underneath Susan. And there are also parts in the company using Red Hat. So it's the project I'm working on that's using Canonical. It's not the company, it's the big company. It's fine, okay. I just said that in our company we use Mirantis Fuel without their support. We use it by ourselves and we pretty much like it but are there any other distributions that can be used for free? With fuel? Not necessary with fuel. So, sorry, I didn't get the question. I mean, are there any other distributions that can be used also for free? There is obviously Ubuntu for free. I mean, Ubuntu, not the commercial thing, the community thing. You can use it or you could use DB and whatever. Yeah, make you happy, it's no problem. I don't know if Fedora and OpenSuzi are really concentrated on OpenStack but there are packages. So for sure there is OpenSuzi with packages and I guess there is also Fedora with packages for OpenStack, that's not the question. They are available for sure. Sorry? Or RDO, yeah. RDO, you read it. So anyway, if you do vanilla you probably even have to choose anyway your basic distribution. Yes, and all of them provide a way to run them with OpenStack. Yes? No, I left them out. There are two, for me there are two specialized on very special topics. So that I mean before was you need to know your use case. There are use cases for using probably the HP products or some other things. But I concentrated for this presentation on the four major distributions. But to be honest, I didn't check it because we did the evaluation on our own. So it's our own requirements and it was a very long list. Any other questions? No? Then thank you.