 Hi. Hi. So my name is Zifat Afak. I'm a system architect in Nokia and the PTL of the Open Stack Vituage project. And I'm going to tell you today about the journey that we've made in this project in the last year and a half. So just a short introduction about Vituage. Vituage is an official service for root cause analysis. It helps the cloud administrator understand and organize and manage the faults of the cloud. A cloud administrator that has a fault in the cloud might see a very long list of alarms. And it may be hard for him to understand what is the root cause for all these alarms. And this is where Vituage can help. Another role of Vituage is to report alarms about problems that are not directly monitored. For example, in case of a physical nick failure, Vituage can deduce that there is a problem with the instances that are not reachable and raise alarms on the instances. And if the instances are used by applications, then also raise alarms on the applications. Vituage provides an holistic and complete view of the system where you can see the physical layer, the virtual layer, and the application layer, the relationships between these layers and the effect they had on one another. A bit about Vituage history. It was initiated in November 2015, just after the Mitaka Summit in Tokyo. It was accepted to the Big Ten six and a half months later in the first of June 2016. The first official version was Newton, OpenStack Newton. And since the beginning of this year, it is used as part of Nokia products, commercial products, and it's running in production. And now I'll start telling about our journey. So Vituage started with the Nokia Cloudband product. As part of this product, we had the root cause analysis project. I was part of the insight team and we wrote a Java code for managing root cause analysis. Everything worked well. The project was successful. But since Cloudband worked tightly with OpenStack, we started thinking that maybe the root cause analysis belongs in OpenStack and not as a proprietary Nokia code. So this was how Vituage was born. We decided to create a new project in OpenStack for root cause analysis and we started checking whether it was feasible. The first thing, the first step before even checking the feasibility was to find a name for the new product because we needed to call it somehow. And we actually made a poll. Everybody suggested names and we had a poll and the winner was Vituage. And only much later we realized that a lot of people don't know what Vituage means. Vituage is a French word for stained glass window. It's a window made of small pieces of glass with different colors. And when you look at each piece, you see just a colorful piece of glass. But only if you stand back and look at the entire window, you can see the whole picture. And this is something like Vituage is doing. Vituage tries to see the entire cloud environment, all of the alarms and make reason out of it. Vituage is a French word, but we thought it was an international word but apparently we need to explain people again and again what it means. And about a few months ago, we had to choose a mascot for the project as part of OpenStuck mascot selection and we selected a giraffe. So the giraffe, its skin is a bit like a Vituage. It's made of different pieces and we asked to get a colorful giraffe. And the giraffe is also very tall so it sees everything from above. Again, this is something that resembles the work that Vituage is doing. And actually we had other ideas for mascots. We wanted a tree like with root cause, very big roots for the root cause and food for the reduced alarms. But Sandin got a forest. We said they told us we can't get a tree. And we wanted a suricata which is always on alert but telemetry product also wanted a suricata. So I think that our giraffe is best and actually this picture was taken yesterday in Boston. So it's a seven meter tall giraffe out of Lego. So now we know that Boston welcomes our product. So we went to the Tokyo Summit, a very big group of people from Cloudband and our goal was to check whether we should really get going with this project. So we met key people in OpenStack and we tried to first understand if there is something similar in OpenStack because we didn't want to start doing something that another project was already doing. And we actually got the blessing of the community to start going. So we understood that indeed this functionality is lacking in OpenStack. There is no root cause analysis in OpenStack and there was a real need for our project. So we hit the road. We started working and we were not experienced with OpenStack and it wasn't so easy to get started. We started with a very big force and we had more than 10 developers working on Vitrasch, some of them on the Vitrasch core, some on the Vitrasch dashboard. We wrote plugins for Horizon and we knew mostly Java, so we had to learn Python and we had a lot of experience with root cause analysis. So we knew what we wanted to do but when we started doing the designs, it wasn't so easy as we expected because Python has its own limitations and different kind of designs. And in the beginning we wrote a lot of blueprints. That's the OpenStack way for doing design documents. And I mean, we wanted to write the blueprints for the design but also we hoped that other people may review our blueprints and comment and improve them. So after finishing the blueprints and as part of writing the blueprints, we had to get used to all the OpenStack way of working, the GitHub and the GoWit and the Launchpad and it wasn't really easy in the beginning. But as a new project, it was important for us to follow the OpenStack guidelines from the first day and later on when we were accepted to the big tent, we understood that we did it the right way because if you start working not by the guidelines, changing it later, it will be much harder. Okay, this is a picture from the Vituage First IRC meeting. An IRC meeting is a chat meeting that every project is supposed to do a team meeting on chat once a week. And we did it just before we even had one line of code. We had the IRC meeting. And we were sitting like almost 20 people in a big waiting room. Each one brought his own laptop and we were chatting with each other instead of just talking. And it felt like a complete fake. It felt ridiculous, but on the second meeting, we had a guest that actually interfered with our conversation and started asking questions. So what I'm trying to say is that it doesn't feel right to sit with your colleagues and chat. It feels very strange. But it gives other people in OpenStack the opportunity to listen and to participate in the conversation. And for months, we were actually talking to ourselves this way and I was a moderator, like I was saying, hey, did you see what the other guy wrote? And maybe you should respond to him. And now, I mean, it was changed. And now we have other contributors and the meetings are interesting and we have real IRC meetings today. But this was the beginning. So I talked about the IRC meeting. In addition, we have an IRC meeting, a channel, OpenStack-vitrage, which is an open place where everybody can come in and ask questions about the channel. And similar to the IRC meeting, I was alone on the channel with some OpenStack boards for months. Nobody entered the channel. I tried talking to my team members, say maybe you should enter the channel, but they tried to enter, so nothing was happening and didn't enter again. Until the first person came and asked a question and we were so excited, somebody is talking to us on our IRC channel and today we have like 15 people on the channel and if you come and ask a question, you will get the first response. Another issue regarding the community handling is the mailing list and this is similar. If you want to, we wanted to talk to each other and discuss design issues or problems or compilation problems or whatever and we tried to do it in OpenStack mailing list and it was strange because we could just talk to the person sitting next to us, but in many cases we did send an email and then when we were in Barcelona summit six months ago, we actually, people came to us and say, yeah, we know about vitrage. We were reading your emails on the mailing list and we didn't know that these people were reading our emails. They never replied to the emails, but I mean, it was worthwhile to send these emails and publish vitrage and get others the chance to understand what we were doing and to get involved. And the first real contribution was in August 2016. We currently have a contribution from ZTE as part of the vitrage project. I mean, as you may know, we have occasional contributors, people that come and fix typos, but real contributors were ZTE. Vitrage as part of what it's doing, it depends on many data sources. So the vitrage gets information from OpenStack projects and from external monitors, combine it in a topology graph and this is the baseline for understanding the cloud and getting insights about it. So from the beginning, we had integrations with many OpenStack projects and we used this information to have root cause analysis about the cloud and other than the OpenStack projects and external monitors, we had a very important collaboration with OPNFV. So OPNFV is a main project which is called the Doctor Project. It's defined specification for fault management in the world of NFV. And we realized that the Doctor Project and vitrage have a lot in common. We read the specification of the Doctor Project and it has a component named the Inspector and the role of the Inspector is exactly what we were doing in vitrage. So we communicated with the Doctor team and we collaborated with them from the beginning and I think both sides benefit from this collaboration. Back in the Tokyo Summit, first place where we initiated vitrage, we had a meeting with Doctor team. We got very positive feedback that what we were going to do was really needed and we presented vitrage to Doctor in OPNFV Hackfest in Santa Clara and then we had in two OpenStack Summit, we had common presentations with vitrage and Doctor. And in addition to Doctor, we now have collaboration with OPNFV Borometer Project and yesterday we had a session with them about the collect the integration with vitrage and the highlight for the OPNFV and vitrage collaboration was in Barcelona Summit, the keynote demo where Hector and Ilico were talking on the phone and Mark was cutting the cable with giant scissors and the phone call was not disconnected thanks to the Doctor and vitrage handling of fault management. Okay and then just six and a half months after vitrage was started, it was accepted to the big tent, it was a major achievement because it happened very quickly and it happened overnight. I submitted a request and for about a week or two I got no response but then there was a technical committee meeting and on the very first meeting with no arguments they just accepted us and when I wrote the request I looked at other project requests, I looked at projects that got into the big tent and also on projects that did not get into the big tent. So when I wrote on the request I had a few points that were important. I described the project, I had like a checklist of all the things that we are doing by the book, that we are doing the open-stack way, I listed them all and one major thing was that I described the community interest in vitrage because writing a project is not enough, you need to show that it belongs to open-stack and if it interests the community then it should be an open source and then after it was accepted to the big tent, the next release about two months later was a Newton release, I mean vitrage was released in Mitaka and it was a stable release with a working functionality but it was not official and in Newton we had to make an official release and as a new PTL I didn't know how to do it so I tried to release it and it was redacted, I didn't do it right and I tried again and again it wasn't right but eventually we have a release for Newton which is good and I mean by now we already have Ocata and we are working on Pike of course and from the beginning of this year, vitrage is already used by Nokia product running in production and so it is a stable product that can be used both open source or used by other companies and we have of course many future plans, we have all the basic functionality in place, the engine is working but we have a lot more to add, very interesting roadmap and we would like to add root cause analysis history meaning if I see an application failure and this failure is a result of a problem on the host that was yesterday and the problem on the host affected the instance that is used by the application and the problem on the host is already solved but the application did not recover, we would like vitrage to show it that the root cause is no longer there but that's the root cause and we have an alarm aggregation for example in the vitrage UI, we would like to show only the root cause and then you can click and drill down to the related alarms we need to improve the UI, the usability of vitrage, the entity graph is a wonderful feature which shows you a lot of information but we need to add some filtering on top of it and on Pike version, we started writing a machine learning algorithm, we have a very first version of it, we want to automate the process of understanding the root cause of alarms, currently we have a human-editable templates that define the root cause and deducing of new alarms in the system, we want the process to automatically understand this and this is a new thing that we started very promising and very interesting and with a lot of future and actually just after this session we have a forum session on room 102 and we are going to discuss in detail some of these future projects and the major goal is of course to extend the vitrage community, we already have a community but we want more companies to be involved and more contributors to join us and this is just the beginning of the journey, we hope to have on the next summit some to tell you some more about the rest of the journey and now like I just gathered a few tips from our experience of the things that we did right and what you can do if you want your project to enter the Big Tent so you should start with the research I mean you should define your goal, your use cases what you are trying to solve and verify that it is really needed you need to check other projects in OpenStack and see that there is no one else that is currently doing the same thing because you can have another project doing the same thing but it will be harder to be accepted into OpenStack and you might just as well join the existing project you want to, if you think that you passed this stage you should go and talk to key people in OpenStack you should identify the people that are doing relevant things talk to them, gather feedbacks maybe get some good advice and let the community know that you are going to do something and start building your relationship, your community and the guidelines when we started before we even add one line of code we checked the guidelines because when you start working correctly everything will work smoothly but if you start working different than the guidelines of OpenStack it will be harder later to change the way you work and sorry, it will make your process of entering the Big Tent harder and when you submit a request to enter the Big Tent they will check your history and you need to show that for a few months you have a history of weekly IOC meetings and you have an history of email exchange and you need to prove that you are involved in the community and not just sit in your own office and write your own code because if you do this you can have proprietary code you don't need to be part of the community and then after you have all this in place sorry, then you can start coding which I guess is what you wanted to do in the first place and you can start writing your project which I guess by now you know what you want to do and unfortunately coding is not enough you need, there is some overhead you need to write blueprints which are the design documents it's not just a matter of design when all these blueprints appear in an official site of OpenStack so when people go and want to understand what you did they will go and look for the blueprints it's very important to have a nice documentation the developer guide I mean there are different kind of documentation in OpenStack the developer guide is one of them there is user guide and installation guide but a developer guide is meant for people trying to use developers trying to use your project if you don't have good documentation they will have a hard time using your project and it's your interest to help other people get involved as easy as possible and writing documentation is not fun but it's extremely important and tests are similar it's not fun writing tests but you need unit tests and integration tests it's very important that if you especially when the community grows and people that you don't know so well start contributing code you need to have a good test say the gate that you can be assured that if the test is not broken then the code is probably okay and communication communication, I already talked about it you need to have the weekly RSE meeting and to communicate using the OpenStack mailing list and it feels like you are talking to yourself okay, talk to yourself we realized after a very long time that people were listening to what we were saying and even if everything is recorded if you send an email there is a chance that one day someone will Google and find it and someone may go to the history of your RSE meetings and see what you are talking about and it gives people a chance to get involved in your project you want people to know your project and one way of achieving it is by collaborating with other projects so you need to find similar projects or projects that the integration with your project can make both sides benefit and have better functionality of course the first place to look for is other OpenStack projects but there could also be other open source not OpenStack projects we found similarities with OP NFV community but there are other open source communities and the more collaborations you have the more people know your project and it becomes something that makes more added value to more people you want more code contributors to join your project you do it by everything that I already mentioned I mean you send emails, you collaborate you make it easy for them to join so documentation is important also in OpenStack there is the concept of tagging bugs as low-hanging foot you can find very easy bugs and put a tag on them, low-hanging foot and there is an option in OpenStack to search for such bugs and we had developers that actually found low-hanging foot bugs and started going and fixing them so it gives people, new people an easy opportunity to get to know your project and do the easy fix and then they might decide to stay and fix more complex bugs doing PR, presenting your project is of course important whenever there is an OpenStack summit or other relevant summit not only OpenStack you try to submit a proposal to present your project use every option to present and publish your project and then there is the matter of finding the right time to submit a request to get into the big tent and it's not, I mean there are different aspects there is no exact right date to do it of course but before you submit your request you need to check the guidelines again and make sure you didn't miss anything if you miss something it's not that bad you submit a request in Go-Eat they may give you a comment that you need to fix something and then you can fix it and if it's something procedural you can fix it and the request will be re-evaluated but if it's something big problem like you didn't do any public emails or any IRC meetings then you might have to wait a few months so we better check before submitting you need to have some working code it doesn't have to be perfect there could be bugs some functionalities can be missing it's okay what's important is to show that you are actively working on this project and this project is interesting and you are contributing and you have a roadmap so the actual state of the project regarding how stable it is this is less important and you need to show the history of IRC meetings and the history of emails and very important you need to show that someone except you is interested in this project because if you want to get into the community you need to show that the community is interested in what you are doing and good luck if you are going to do this and we are presenting vitrage today in Nokia booth and we will be very happy to hear from you either on IRC or on the emails or whatever we want we have a wiki page with a lot of information and demos and documentation and if you have any questions I'll be happy to answer okay thank you