 Hi, my name is Ewan, I'm from Citrix, as you can tell from the corporate branded slides, which at great expense put together in PowerPoint. So this presentation comes from PowerPoint through to Libre office running on a Mac, so I'm quite amazed that it's actually displaying it all. This is the official spelling of Zens Abercourt. James Bulpin took away my shift key, I'm not allowed to use capital Xs and Ss and things, so we're going to have to have a word with Anil about his slides. This is joint work with Dave Scott, who's the Zens Aber architect, he's not able to be here. He does all the hard work of splitting up the packages and making them all work in the weird environments we put them in, and I sort of swan about and write a few Python scripts and get to come here and take all the credit. So it's a good division of labour for me. What is Zens Abercourt? Well, it's basically a way for us to try and get the bits of Zens Aber or a Zens Aber-like system in front of as many people as possible, as easily as possible. It's also part of our scheme to try and get our components upstreamed into distributions like Fedora and Ubuntu. What's actually in it is, this is a bit like John's slide from previously, we package all the tool stack stuff, the zappy and friends. We also package some other creature comforts which aren't really part of zappy, like the storage managers and the excess console and so forth, because what we're really trying to do is to get a system which looks as much like Zens Aber as possible on a standard Linux distribution. We don't include, off things from this slide, we don't include QAMU, we don't include drivers and we don't include Zen. That's mostly because these components are already upstreamed and working very nicely in Ubuntu and in Zentos. We just piggyback on that work. We might in future make it possible to build in the Zens Aber core build stuff that I'm going to talk about in a sec. We might make it possible to build those packages because there are things, patch queues and so forth that we develop inside Citrix which have got useful features that people might want to use. Right now, if you want to install this on Ubuntu or on Zentos, what you're going to end up using is the kernel and Zen that comes from that distribution. Here's a different way to look at it. This is a diagram that James had on a blog a little while ago. Basically, there's a layer cake. Zens Aber core is essentially the top layer. As you can see, the particular example of Zens Aber on Zentos, the Zen for Zentos extra packages, that's an extra repository which has the Zens spec files and various other Rpms for Zentos 6.4. Citrix are working quite closely with Zentos in maintaining that and getting that stuff all working well, but it's not part of the Zens Aber core effort per se. In future, you may also be able to use the ISO spinning tools that Zentos and other distributions have to build your own custom ISO which installs a Zens Aber-like system, but again, that's not quite where we are at the moment. What we're really hoping is that if you take nothing else away from this top today, we would really like for you to try this thing, to install it on a machine that you have lying around and give us feedback on how you get on. The practical point of Zens Aber core is to make it as easy as possible to get Zapi and so forth deployed on your Linux box. For most people, practically it's going to be something like this. On Zentos, you can add a pointer to our Zens Aber core repository, which lives currently on zenbits.org, but we'll have a more official permanent home for that. You'll also need to add the EPEL repository if you're doing this on Zentos, or if you're doing it on Fedora, you shouldn't need that, because there are some bits and bobs that don't go in Red Hat or Enterprise Linux or in Zentos, but that are required for building. Also, as of a couple of weeks ago, Ubuntu people are equally supported, and this is because although Zens Aber itself, we started off with Zentos because Zens Aber is an RPM based product, so we had all the spec files available, and that was a good place to start. But a lot of people, even within Citrix, are fans of Ubuntu and would rather be able to deploy and develop on Ubuntu, so we have a bit of a hack, which I'll discuss later, to reuse a lot of the effort that we put into making the RPMs on Ubuntu. Actually, my favorite command isn't actget install Zens Aber core, it's actually actget upgrade Zens Aber core. That's really nice, you can rebuild your packages, rev the bump, the revision on the package, and then with a couple of minor bugs at the minute, you can basically say actget upgrade and it will upgrade, restart your services and work. And I've been using that in development, it's really nice, very pleasant way of working. But whatever you choose to do, what you actually get after installing this stuff and rebooting, and I'm not sure if it's actually coming out super well on this screen, is, as I've said, a Zens Aber-like system. So you've got SAPI, you've got our storage managers, you've got all the other bits and pieces that you'd expect to have, and it's sufficiently Zens Aber-like that you can connect to these things from Zens Centre. You can create VMs, you can do pooling, you can move VMs around, and what this screenshot is showing, if you can make it out, is from a demo I gave a little while ago, you've got Zens Centre, there's a pool called Zens Aber core pool, it's got three hosts in it, there's a VM which is just moved from ST07 at the top to ST04. And those two terminal windows are showing that actually on ST07 it's a standard Centos 64 with Zens Aber core 0.9.0 installed, and the machine below is running Ubuntu with Zens Aber core 0.9.0. And what that shows is that because these two machines had compatible hardware and they were running roughly equivalent versions of Zen, we were able to migrate a VM from one to the other, and that's something that was quite fun to do. But why are we doing this? Well I've tried to cover that so far, but just to recap, we're doing this because we want Zens Aber to be as attractive as possible to developers outside Citrix, to users outside Citrix, but really very much to developers. They might be partners to our developing products which integrate with Zens Aber itself, or it might be open source projects like OpenStack where we're really keen to make Zens Aber or Zen as good a hypervisor base as possible. And the reason for doing all this packaging work is that Zens Aber has been fully open source now for a few months. Zens Aber 6.2, you can download it for free from Citrix and use it without any encumbrances. But it's packaged as an appliance, it's an eye, so you have to have a spare machine to install it on. And of course many developers don't have the luxury of having a spare machine that they can just use, especially if they're only trying out Zen for the first time. So all of this effort is going into trying to make it possible for you to create your existing machine like John's laptop that he is using just now. And install Zens Aber core on that and use it to do things like present your Mirage VM presentation, which I was very pleased with because otherwise I would have had to distance myself from that. So in future we're hoping to get these packages upstreamed into your distribution so that they'll actually just be there. Currently you have to add a repository that we're hosting. But most of us here are developers and so what we're particularly interested in is how we can actually build this thing. So being able to install it is great but what we really want to do is tinker with it, see how it works, change it, break it, rebuild it. So for us the other practical upshot of Zens Aber core is that you can do something which looks a little bit like this, quite a valid git command but anyway. All of this code exists on GitHub and you can clone it and then we put quite a lot of effort into making it easy to build using a very simple sort of configure, make, make, install, lookalike process. So inside Citrix Zens Aber is built using a very complicated build system which has evolved over the years and does all kinds of exciting things and cooks dinner for you and washes up afterwards. But it's very dependent on infrastructure that exists within Citrix and of course that's not very helpful if you're just trying to get it to build on your laptop. So with Zens Aber core all you have to do is clone this repository, it comes with all the bits and pieces that you need to build. If you clone it what you'll notice is you just get a large directory of spec files and a few Python shell scripts which actually handle the build for you. What happens when you do the build, well here's how you do it, clone it from github.com, run this configure.show which will set up the build tooling for you. We use mock on sentos so that the package builds are isolated from each other and the configure will set that up for you. This make, make line is basically instead of using auto make or something like that it looks through all the spec files and produces a make file which will build things in the right order. That separate line is going to go away soon and you'll just type make as usual. What you'll find is it will then download the sources for each component from their respective upstream repositories. So in the case of all the Citrix components that's github again we tag versions of our sort of trunk builds on a fairly regular basis. And so we, and then server core points of those tags so what you get is a sort of curated snapshot of trunk of at least our components. You'll also find in there some spec files for components which do exist upstream but unfortunately we have to rebuild them because for example in Ubuntu we don't have a new enough OCaml compiler. And so there are certain libraries that we could depend on from Ubuntu but we have to rebuild them because our libraries are built within your compiler and they won't link. The build takes about an hour or so on Ubuntu and about an hour and 20 minutes or so on sentos depending on your machine. We're always looking at ways of making it quicker so I have a branch for which tries to do a parallel build and it seems to work but parallel builds are tricky things. So I'm holding fire on that until I'm certain that it's okay but it's sort of simultaneously working on the internal build system. John has been doing some interesting work with RPM caching and I'm hoping to be able to pull that into the Zensa over core build system so that you don't have to rebuild everything if you're just playing around. It'd be nice if you could just pull down the hosted packages and rebuild only what you need. Currently it will do a full build and that reflects the fact that it's a distribution builder. It started off as a distribution builder and we're adding features to make it better as a developer environment but a lot of the focus so far has been to build all the RPMs from scratch so that you can install them. This is what actually happens. It's a very standard RPM building workflow. There's a spec file. Our tooling will download the tar balls. We also ship a few patches. Those are in the repository. All that gets fed into RPM build which produces an SRPM file and that then goes through Mock which is the standard shooting build tool for building binary RPMs. At the end of it you get a big pile of RPMs. You can then point your machine at that directory of RPMs and say install and it should all work. Makemake is doing this part. We've got at the top the spec file saying for example the QMP a particular version requires a bunch of packages and produces a bunch of targets. Makemake uses the RPM Python library to try and figure out what things that package requires to have installed and what things it's going to produce so that it can build the make file dependency graph correctly. I have more super over complicated build systems and I like to try and use standard features wherever possible which is why we're using make and so forth but there doesn't appear to be a tool which you can throw a directory full of spec files and say just build those things. So this is all custom hacks but it's using the RPM library and it's not really a particularly large script and again it's getting smaller and smaller as we move away from generating the whole make file to just doing the dependency stuff. But because it's useful to know what's going on when you're trying to build things if it goes wrong this make make is basically taking all those spec files and producing a make file. As of a couple of days ago you can now also make install after your build is finished so there's an extra target in the make file which will configure yum to point at your local directory of RPMs. It will add that EPL repository, it will do a few other tweaks and then run a yum install Zen server core. So from a developer's point of view you really can just do basically it's like muscle memory you can do configure make make install. You then run the Zen install wizard which John mentioned in his talk which does the sort of setup that the Zen server installer does. We still need some final setup that you then reboot and you're in hopefully a Zen server like environment. So I mentioned Debian. I gave this talk a little while ago or at the top which this one was based on a little while ago at which point Debian was experimental for us at least. It's a bit less experimental now because as well as I mentioned John's actually running it on his Ubuntu laptop so how experimental does it feel to you? A little bit yes that's the right answer. It is a very new thing and it's a little bit of a hack and I'm looking around I'm not seeing Ian Jackson so I'm happy because this is somewhat blasphemous and as a next Debian person or probably a next very senior Debian person and I'm sure still consider himself to be Debian to the core he might kill me. But again why when we started out we built RPMs because Zen servers RPM based but many people within the company and outside are Debian or Ubuntu users and so it would seem nice to cater for them. Now we have been here before so Cronos was mentioned so project Cronos actually took the components of Zen server packaged them up and got them into Debian upstream but as was mentioned this was a custom handmade packaging. A few things have changed since then well first of all Cronos has always lagged a little bit behind the tip of Zen server development and one of our goals is to keep up with tip if we possibly can. And one of the reasons for that was that it was manually generated package and so anytime you changed anything you'd have to go and redo the Debian package as well as the as well as the RPM and of course there are times when things get forgotten or whatever. So the other thing that's changed since then is that at the time of Cronos there were a few packages in Zen server but in the meantime we've been busily splitting things up and now we have 50 or 60 or something of that order. So manually writing two sets of packages for that number of package files is a wee bit error prone and a lot of effort. So what we've done for Zen server core is we've come up with another hacky python script which takes a spec file the tar bowl and the patches that we had to build the RPM and then generates a Debian package directory for that package. So instead of running it through RPM builder we run it through our own script it looks in the spec file. So for most of our packages what we're doing is we're not using super advanced features of RPM so there's a fairly clean mapping from the RPM spec to the Debian it's mostly which packages do we depend on what do we provide and a few other bits and bobs. So we map from the spec file to the Debian source and the good thing about that, the Debian source package, the good thing about that is that after that point in the lower half of this slide we're on a completely standard Debian package build path. So the earlier version of this slide we were actually using P builder which is an equivalent of mock in the Debian world and I switched to using cow builder which is its P builder using a copy on write mechanism which makes things a little bit quicker and it was simply a question of changing the word P builder to the word cow builder in the make file because as far as those tools are concerned they're just seeing Debian packages and they're happy. So yeah just to be clear there are tools which will translate an RPM into a deb they seem to be more taking a binary RPM and turning into a binary deb what we're doing is taking a source RPM and turning it to a source deb and I think that works out better for us because there are a few other tweaks that we need to make to fit in nicely on with paths and so on to fit in nicely on an Ubuntu machine. And those would be harder to do if we were just working on the binaries. Anyway I've survived through that so there aren't too many too many Debian people in the room. What we really want as I said to begin with is for people to start to get involved so this project's been going for a few months now and it's at the point where it's somewhat usable. And I think it would be great to have other people trying it out and feeding back on what works, what doesn't, how we could improve it. Patches are welcome. There's a list of issues on GitHub and if you'd like to fix some of those then I'd be very happy to receive your patches. If you're a distribution maintainer then I would love to talk to you about trying to get more and more of these bits upstreamed because currently you have to add a repository. It would be really nice if all of that stuff was already there. As I said we're working, well the Citrix works with Centos on the Zenfor Centos repository and we have these spec files so I'm hopeful that getting into an RPM based repository should be quite straightforward. I'm very keen to talk to Debian people to see how I can make these packages as acceptable as possible to them. So this is our GitHub page so if you want to contribute, those are the two things highlighted in red. Fork it please, send us pull requests please and we are very happy to accept them if it pushes things forward then we're delighted. We also hang out on the AccessDevel mailing list with all the other Zen server people and we're also on ZenAPI on FreeNode but I'm pretty terrible at watching IRC so if you ask for me on IRC and I don't respond please don't take it personally. It's probably just buried on a window at the bottom of a stack on a desktop behind a sign mark we were at the leopard. So what's next for this? As I said we're at the beginning of, we're probably at the end of the beginning with the Zen server core, it builds, it installs nicely. We've smoothed out many of the hiccups or many of the bumps that might cause you to have a hard time installing this, it installs fairly smoothly on Centos and Ubuntu. It builds fairly smoothly on both of those also and there isn't too much fiddling around especially now we've got make install, you used to have a set of instructions saying go and edit this file in Ym but now it does it for you. We're beginning to hear from people just randomly by Osmosis who've found out about this thing and have installed it and they turn up and they complain about the build speed or whatever and we try to help them. Mostly they've had positive experiences, we haven't had too many people showing up and saying this just doesn't work which is nice. One of the things that we're working on right now is getting more testing. We're actually trying, as I said we're trying to get this to work nicely under OpenStack so we're working on getting the OpenStack tests running with the Zen server core as a hypervisor and we're almost there with that. So far we've made two tech preview releases from this codebase, one of them was more specifically around Ceph, that was something that Dave talked about at the Centos dojo a couple of months ago. Since we're approaching a stable point we're hopeful that we'll be able to start pushing more frequent releases in quotes where our release is basically we will tag the Zen server core repo saying at this point things seem to be pretty stable and we will perhaps build some RPMs and host them somewhere. But we're hoping to produce these sorts of releases on a fairly regular basis so that if you follow the Zen server core you'll continue to get something pretty close, as close as we can get you to the bleeding edge of at least our packages without cutting yourself too badly. As I said we're not currently shipping kernel or Zen but it's given that we're in a completely standard, after the initial make make and makedeb we're in a standard Ubuntu and Centos build process there's nothing that really prevents us from dropping in a spec file or a Debian source file for the kernel or other components. So we will probably make that an option at least in the future. And that's all I had so we have a little bit of time for questions hopefully. No questions, excellent. Plant. So could you comment a little bit on how Zen server core relates to Zen server the ISO as shipped by a certain company in Cambridge? Yes. So well Zen server core is the, it's a packaging of the tool stack components which go into, which also end up by a different route in the Zen server ISO. It's not Zen server the product but it does contain the tip of those tools and so many of the things that you'll see in Zen server core will quite possibly show up in Zen server in the future. As I said, you might also be able to use the spinning tools in Centos or Ubuntu to produce your own ISO. That also of course won't be a Zen server, the Zen server product that you get from Citrix although you can now look for free. You can also pay for support and that's not something that we're looking at at the moment for Zen server core. However, we're spending all this effort to develop tooling for packaging and we're hoping to use much of that in the Zen server effort. So there's a convergence of tooling but Zen server the product is a special blessed thing from Citrix and Zen server core is a kind of a preview of what we're up to. But just because a feature appears in Zen server core you can't really fully, we can't guarantee that that thing will actually appear in a particular release of Zen server. One of the really nice things about Zen server is that it's always the X1 RPC API that people can build to release this one. So is the, I believe that it's in the development source because of Windows only? Yes. Does that incorporate the Zen server core and does anyone from the community build any JavaScript or web-based API on top of this API? So I had a slide a way back here somewhere, this one. So that is Zen Center in the background talking to Zen server core machines. So the Zappie that we have is trunk Zappie. So if we in the Zen server core are doing our jobs right then it should work with anything that talks Zappie. As for other tools, so I think there's something called Zen Orchestra and some other tooling around Zappie. The other point I would make is that we're trying to make this thing work really nicely under OpenStack too. So OpenStack talks Zappie to Zen server core to get it to do what it wants. So yeah, there are quite a few, there are many tools which will manage a Zen server and if any of those doesn't work with Zen server core I'd consider that a bug and I'd like you to raise an issue. Thank you.