 So, hi, my name is Muhammad Najjar. I'm from Nokia Cloudman. I'm a software engineer in Vitrage, contributor in Vitrage. So, we'll go on project update about Vitrage. So, short, what is Vitrage? What's all about? So, Vitrage, it's OpenStack root cause analysis service that has three main functions. The first one, it's providing root cause analysis. Suppose you are a cloud administrator and you have a severe problem in your system. You could get a lot of alarms from different resources. Vitrage can help you to arrange them and give you the root cause view and pinpoint on the problem. So, and the second one would be raise alarm, raise deduced alarm on resources that might not be directly monitored using detailed topology graph that has, from this graph, Vitrage has a deep understanding on the system so it can raise deduced alarms on those affected resources. For example, a very simple scenario if you have a host and the nick is down. On this host, you will have an instance but the instance would be unreachable because the host is down but Nova is not aware about this instance is down. So, we raise deduced alarm and setting deduced state and we'll inform Nova about that. The third thing would be the giving holistic and clear view of the system from the topology graph. The entity graph would give us the three layers of relationship between the entities. First would be the physical layer and we have the application layer and the virtual layer between them. Physical layer would be like hosts, virtual layer like instances and the application layer like deployments of application, for example, heat. Bit about project background. So, Vitrage started three years ago by Nuoka developers and since then, we, back then, we realized that there is no RCA solution in OpenStack so we initiated a new project for this purpose. After only six months, Vitrage became an official OpenStack project by the way, it's record time and now Vitrage is stable, nature running on production in large deployments. During Rocky Cycle, we had around 10 active contributors. So, let me describe the main feature we introduced in Rocky Cycle. The first and the big one is alarm history. So, one of the main features since Vitrage holds an in-memory graph database which is network X, when alarms is cleared, it is deleted from the graph so we can't go after records from deleted alarms. So, we wanted the user to see the alarms that cleared, for example, if a cloud administrator has come to work at the morning, he wants to see the health of his system so he can go back and see the alarms that occurred at night. Another example is if we have its CD problem and it's trying to scale out but we can't know what is the problem caused to its CD problem. So, if we go back in history, we can see that it was caused because safe problems that now we can go and recover this its CD container. So, another motivation would be giving statistics from previous alarms, which alarm appears the most, and we can give the administrator a big point what he could do or change in his cloud. So, what is the implementation of that? So, again, we had network X in memory. Now, alongside to that, we are using history and keeping it in a relational database, MariaDB. So, but we are storing only the basic information, meaning the alarm properties, its resource ID and the relation between the alarms. This way, we are not replacing the graph database. So, it's another additional in the side and all that going alongside from the in-memory database. So, another big feature would be fast failover mechanism. So, we tried to pull the graph again held in network X. So, period to rookie, restart graph process mean that entire graph had to rebuild itself from data sources and we have seen cases where data sources are not implemented efficiently. So, this restart took a lot of time, so we wanted to make it more efficient. So, now we are using the database, we are storing graph snapshots into and this help us to fast failover. So, how we do that? And after periodically get all, we take the whole graph and make a snapshot from it and depress it and put it in our composite and put it in the database and between each get all, we are storing the events that happened. So, after restarting a graph, we take the last snapshot and playing the events that occurred since then. So, after trying that it was very fast compared the previous situation that we had and it is more efficient. So, another thing would be, so yeah, it is all related. It gave us a significant performance enhancement, now we can support more entities, around 100,000 entities and staying we are continuing this input and we want to improve the performance. We'll see later. So, yeah. Now we have Kubernetes and Prometheus data sources. Kubernetes, if you don't know, it's the leading container orchestration framework and Prometheus is the leading monitor on Kubernetes. Vitraj now can show topology that includes both Nova and both Kubernetes cluster instances from Nova and instances that are related to the Kubernetes cluster and can perform a root cause analysis from Prometheus and Zebix and relate those alarms together. A very nice demo we can see in the booth. And so, now let's talk about the future. What we are holding to stand. So, we want this very bad to generate a template in a more easy way. We have a great template now, but it's getting complicated for a scenario which are very simple and it can get reputation like all the time. So, we are thought to let's do two things. Like, let's generate a template from few parameters or we can do easier template syntax which will be used, for example, on heat. We'll see that in a minute. Very, again, a very known scenario. It is a host with an instance. There is alarm on the host which causes alarm on the instance and the way back. So, those can be generated easily from just specifying the alert name on the host, alert name on the instance and the severity. Another thing that what I mentioned before, the motivation is shorter template syntax would be enable configuring vitrage template within heat template. So, again, from little parameters that are given from heat templates we want to generate vitrage template in a shortened way. A very basic template is not shortened as I explained the scenario before and we want the heat users to have not to write a lot to use vitrage. That's the main motivation. So, another thing that related to the database we started using it in the database and storing alarms and snapshots we still want to improve vitrage API so the pretty big work have done before and we are still want to improve vitrage API and reduce the memory it's using. Another thing would be add a graph action panel in entity graph so adding a mechanism running on external actions which are manually configured by the users from the entity graph. The action will be plugins so the user can write his actions and execute them. Example for those would be like opening external monitor, executing external tests and etc. A second phase would be actions depend on a current section, a selection in the graph. For example, selecting a host so do an action that related to the host. Other features are very big one. We needed to handle it before but it is still we want to do it now. It is vitrage tempest plugin that need to be refactored because money test and vitrage code accesses vitrage code directly and it is wrong. The tempest should access vitrage API only so we are trying to refactor that and we want now to support upgrade and trove that I just went to their presentation. Trove it is a database as a service providing automated database and life cycle management including provision, configuration, backups, scaling and etc. So we are looking to integrate with them. We already have, we want to have a data source with them to get the entities and trove them in our entity graph. We want integration with other data sources but the problem we don't have enough resources so everyone that is interested to contribute and help us with that. So we are considering sending vitrage allowance to Zakhar and very, very important we want integration with Monaska we hope to have it soon. So another thing that vitrage is highly involved in self-healing special interest group the purpose of this group is to identify use cases requires self-healing and document possible solutions that involve several OpenStack components so we already have integration with Congress that consumes notification about vitrage alarms and we would like to let users to configure vitrage within heat template as I said before and again Monaska, Monaska vitrage should get all alarms from Monaska and be able to perform root cause analysis on them. And a pretty cool project called NGPASS it's an incorporating of several companies in academics like Orange, EMEC, ATOS and DTU those companies and academics aim to define and support the coming 5G platform as a service so in vitrage side we developed the Kubernetes and Prometheus data sources on vitrage and that's it basically so contact us on those ways and if you have any questions please ask the question is is it possible to connect Kubernetes Prometheus as data source external from OpenStack vitrage can be deployed outside OpenStack so you would be able to do that on it's not related to OpenStack so it can be degraded with Kubernetes and Prometheus the question is how many memory and it repeated to how many storage we need to store 1,000 entities this is a very technical answer but I can give you the exact because it depends on what are the entities I can't tell you because it depends on the entity graph how it's going with alarms how the whole cloud is working so it's not exact number or assumption if it's working I don't know okay cool do you mean here? you mean this one right? just I want to so a comment not a question was on the entity graph action panel here is a guy that is along with Minwok is contributing this action panel and he wants a status update what is action yeah what will so yeah okay and what's edge known cool so the second note was about deploying vitrage in edge right and you have a design some architecture design on that so those are very specific things we can talk privately and we can give you information where you can contact that but thank you so the time is up right so thank you all for coming