 All right. Well, we heard this morning about some of the UIs that are coming along regarding Zen. And this is one of the more interesting ones right now that Olivier is going to be telling us about Zen Orchestra. Thanks, Ves. So I'm here to introduce you to Zen Orchestra, which is basically a web interface for Zen. And for Zen it's for Zen plus Zappi. So here's the plan. I explain first why this project, then the global design. Oh, it works. What we are doing now with this project and the future. So why this project? Well, it started in 2009. I worked for a big company using Zen, the old Zen with ZenD. And sometimes it happens there is problems with some VMs and we cannot SSH on it. So I need to find where is the VM, but there is a lot of servers. So each time there is a problem, I need to find the VM to find where is the VM to get a console on it with XM console. So I need to find easily in one place to see where is my VM. So I start to hack something using ZenD and to put on a web page something that can display every host and their respecting VM. So I search something with a web interface because I like it. The global overview and if it can make my life easier, it can be cool. So not only CVM but interact with them. Then I start ZenOquistra. It was really small first, so in 2009. But it was not my main project. I've got a lot of work. I have to finish my studies, etc. That's why the project was discontinued in 2010. As you can see here, and you heard about that before, XCP is out in 2011. And it brings Zappi. And when I saw the possibilities of Zappi, I saw we can do really great things with a web interface and not the old ZenD but the new Zappi. That's why years later I choose to reboot the project, but this time using Zappi. And it seems a good choice because this year ZenSaver was open sourced. So it's a great thing for us. That's the reboot. The main objective is to get a simple and neat GUI for Zen. And like the last time, I want to use it with web technologies and the latest. And as I said before, I want to use and leverage all the possibilities of Zappi. And for sure I want this project to be open sourced. So it's AGPL. The main difference between the first ID in 2009 is this time we have a company's report, which is a small company in France. My own. We are three. But it's not a hobby anymore. It's a real project. So we do our ideal specification before starting to do something. And well, what can we expect for that kind of project? Basically, we want to be manage everything from web browser, which is normal for webUE. We want it to work out of the box. When I say that, we want it turnkey, really. And if it covers everyday administration work for Zen, it will be great. But it's not the only thing we want. We want to do more with an innovative interface, which means another way to see your VMs or your hosts, et cetera. And we want it also with a scalable design because we thought at this time if we have a lot of clients using it, we want to have a good performance on every client. What is not EXO? It's important because it explains our position in the market. We do not want to do a clone of Zen Center. We share the goal. We want to provide an interface for using Zen every day. But it's a web application and it's not heavy clients or rich clients. So it's different. We have a lot of possibilities. It's really another thing. And we do not want to do a big cloud manager. It's not the same objective. We are not talking about 1,000 and 1,000 VMs. So we want also to, as I said before, to be turnkey. So we do not want to install specific things or to have complicated things to install. We want it working really out of the box. So that's why we choose Zappi. As I said just before, now we've got Zen Center, which is Windows only so far. I've heard maybe something with Mono, maybe on Linux. I don't know. It's a rich client and there is no persistence. Persistence is, for example, when you shut down your Windows computer, running Zen Center, okay, you lose everything. You need to reboot it to have data, et cetera. So that is persistence. We saw this morning Open Zen Manager, which is great, but it's more a Zen Center clone. It's a rich client too, and there is no persistence. And it seems the last version is from 2010. So a little old. And there is a lot of projects, small projects. Some companies are doing specific things, but it's too small or not open source or too big, like all the cloud or open stack. That's why I think there is a gap for XO. About the global design of our application, first thing, as I said, we use Zappi. Why using Zappi? It's available for Zen Server, which is basically, not just that, but basically it's Zen plus Zappi. But it works also for any distribution which can run Zappi, so it can be Debian and CentOS, for example. And it's really a complete stack. You can do a lot of things with Zappi, really a lot of things. It's not like the old ZenD, which is great for a basic task. This time you can do a lot of things. And another proof. It's the backbone for a lot of existing management applications. So it's really a great thing. When I saw Zappi for the first time, the first main point I see, it's even tracking and progress with notification. That's really great for Zen Orchestra, because we just have to get all the events we want and listen to all new events without any waste of bandwidth. So by design, it's great for us. And as we talked this morning about this, about resource pools, storage, VM lifecycle, and many more, so it's really a good stack. After the choice of the Zappi, we built our architecture for Zen Orchestra. And we decided to do this architecture in two parts. There's Exoserver, which is basically a daemon, running every time. That's why I called persistence. There is connection to your Zen server. You can have ACLs, et cetera. On the other part, there is ExoWeb, which is basically the interface. The benefits for this architecture. Well, you can uncouple those two projects. So if we are more Nexo server specialists, for example, if you want to manage connection to a Zen server or XP or anything like that, you can work on Exoserver. If you want to just modify the interface, it's another thing. And there is protocol between these two parts. So if you change one of those, there's no problem. Here's the graph. So all of this is Zen Orchestra. You have the clients here talking to the Exoserver and it's Exoserver, which is talking to XP or Zen server or Zappi host, whatever. About the events. We just see that Zen Orchestra use events. So we list all events and build a cache. So that's great because if a client wants information and it's in the cache, well, you don't have to do another call to your server. So it's bandwidth friendly. Here's an example on small Zen infrastructure. We've got one pool here, pool one, with a Zen server. It can be any Zappi host. A Zen server master and two hosts in the pool and two other servers which are not in a pool. Now, if you use Zen Center, if you want each of your clients connected to all of them, you have a lot of connection to do this one. For example, client three, you need to connect to this one, this one, this one, etc. for the other one. So it's a lot of connection to all your servers. But with Exo, it's different by design. You've got your web clients connecting to the Exo, the Exo Demon, which is half cache, so that's great. And the connection are managed only by Exo. So less connection, it's more scalable. If you have a lot of clients, there's no problem. Exo manage it. So when we reboot the project, we reboot it again with PHP. But frankly, we have problem with PHP. There is a lot of bugs and those XML RPC libs. And some people are saying, well, guys, maybe PHP is not a great idea for that. And yes, why we choose PHP in the first place? Because we are familiar with it. By design, it's not really a good fit for us. So we searched for another thing. And we find Javascript, and especially not.js. It's really a good technology. It's less complex for our project. And by design, it's great for dealing with servers. So we choose this technology. And we found it's really great. Plus, it's really easy to connect with other things like no SQL database like Redis. So for Exo Server, Javascript is great. But not only for Exo Server. We choose to redesign Exo Web 2 using great Javascript technologies like Backbone, WebSockets, and a single-page application design. And that's really great because it's lightning fast. No page loads, et cetera. Just one page. For the graphical user interface, we choose Twitter Bootstrap, which is really great. So on the entire project, we do not use PHP anymore. It's on the same language now. It's Javascript. We saw the technical design in Xenochistra. Now let's talk about graphical design. Well, it's the most challenging part for our project and our priority. Why that? Because when you display a lot of information about your Xen infrastructure, believe me, there is a lot of things to display. There is a lot of things, so that's what we call data density. There's a lot of different things to display. That's what we call diversity and redundancy. So we have two choices at the moment. To cope with that. Two parallel choices. We've got a traditional solution. For example, just use tables. But we want it to be always light. Not too much information in your display, because it's a web page, and we do not want to overwhelm the user with too much information. That's one way to deal with that. The other way is to find something different, to deal with this kind of difficulties. That's why for the classical design, as I say we use table, so it's pretty simple. You've got the name of your VM, the description, the memory, the first IP address, the app time, and action. That's not the final design, but give an idea. Here, it's green dots indicating your VMs are running. It's pretty much simple. On the other side, for the innovative design, we choose to use D3.js, which is really, really a great lib in JavaScript for dealing with that complexity. If you can go on the website, that's really a great, great, great lib. With that, you can display a lot of things using mixing symbols, colors, et cetera, for displaying a lot of data. And the good side, and we have in our small team, a software agonist. With that, we have all the requirement to research for innovative design. The first and simple solution, for example, to display some infrastructure is this one. You have your pools here, and they are connected to host. It's a small example on this one, but you have pools, host, and VM. But it works for many more host or VM. Well, it's scalable for displaying information, and we can imagine other ways to add information. For example, if we fill our symbols with, for example, CPU load or memory load, et cetera, we have a lot of combinations possible. So it's a great field of research for us. And this overview is currently in Alphavation, but it works. So now, the current state of this project. Well, we wanted plug-and-play, and it's plug-and-play. We choose for easier distribution. We install it in a Debian, and we export it in an XVA appliance. So you just have to download it to import it in your existing XAN infrastructure to run it. It's in DHCP. So if you have the IP, you go on a browser, and that's it. You're ready to go. Five minutes. No complicated things to do because we use ZAPI, so it works. It works for, for example, XAN server, but it works also for Debian plus ZAPI and CentOS plus ZAPI, but we didn't test it now with CentOS. We've got another view panel, VM lists, VMs, consoles, working Firefox. Not on every web browser because we use no VNC and it's a mess. So it works now in Firefox, but our objective, our goal is to have VM consoles working in every browser, normal browser, not Internet Explorer. And we have local users and permissions. So let's see. It's pulled from a real situation. Here at the dashboard, you have the four host running and 23 vCPUs used on 20 CPUs, all the RAM, how many VMs are running, shared repository, et cetera. You can add a new server, and it's, you've got a new window here. You can connect to, in order to have admin rice and to connect to a new server. It's a host view, so all your hosts with a name, description, how many memory is used on each host. So it's pretty much simple to see if you have a server with too much RAM, et cetera. And you've got their address. So that's cool for, connect to them. We saw that just before. Simple view is all your VM. And when you click on a VM, you've got a panel with the state, the name, et cetera. If you have tools, Excel tools installing it. It's UID, et cetera, classical things. And you can have the console. So that's great. If you want to just have a look on your VM, you just have to start a browser, go on an IP of Xenochistra, and that's okay. You can work. It's a console view from Windows XP. It works too for other OSes. Here is admin pages. You've got an admin page for servers because we saw we can add a server, but if you want to remove it, there's no problem with that. You have just to tick and to delete. And you can manage users, create users with their permission, with the password, et cetera. So it's not fully implemented about the ACLs, but you can restrict basically some rights, like rights to stop or pose, et cetera, for a VM. Thus, what's the next steps for this project? Well, we want to create and manage VM storage and network. So far, you can just connect to a host and see existing VM, but we want to add a way to create VM. We want to add an LDAP backend for connecting to your directory. We want to get the RLDs for display graphs. So it's the next step for the short term this year. And we will search another views and develop them. And if we have the time to make some distro packaging, for example, for DBM. For the next year, our main objective is to provide a stable release. And with this can come the possibility of professional support or sponsoring. We don't know now, but we are thinking about it. We will provide trends because of XO architecture. We are always connected. So we can do workload analysis and check RLD history. So we can do really cool things with that. And there is a lot of possibilities. Maybe if we want to change or add a backend for Libvert, for example, we can do it without changing XO web. That's possible. And other research projects based on visualization. To conclude now, the good news. The website drained a lot of visitors in August and from literally everywhere. So that's great. But I say 10 or 15 early users and they are really enthusiasts. It helps us to fix bugs, etc. And there is a lot of expectation from this project. People want a web interface. And our bottleneck now is understepping. We are only three, so our developing rate is not that great, but it's not bad. So if you want to have any information on the project, there's the main website. There's a lot of things to read there. We've got a forum on IRC, Twitter. And if you have any questions, well, I think we've got time. So you can come to see us or ask a question now. And we'll be available here until Friday. So if you have any questions, you can go. Yes. So I was having some issues with the data from the VMs populating. I'm running Node.js 10 stable. And I think I checked it out from a clone to Git repo. And so some things that I think that they said that they were like work in progress or something, like certain parts in the UI, do you know what I'm talking about? That's why we prefer to use appliance because we expel any problem with Node.js version, etc. We want to focus on really what's bugs on our side and not on Node.js version. So if you want to try again, I think the better way to do it is to import the appliance on your Xen infrastructure and test it again. Well, what didn't work? The appliance was important. Ah, no luck. Xen appliance and then hit GitHub and get the updates for the code. Yeah, we made any script to update in Debian. So you just have to SSH and to do a service EXO update and get from Git all a new version, avoiding re-downloading every time a new appliance. So yeah, we build a script in the appliance to update. Do you know how off the current appliance is from the current head? It's based on Debian's table. I mean the code that's in the appliance, how far off is it from what you're currently? The last version is, I think, up to date. Oh, really? Yeah, I think. I re-upload when we have a lot of modification to be sure it's okay. So if you download it today, I think you have the last version. Any other questions? Let's give Olivia a good hand, huh? Thanks.