 Sorry for that. So how to do building an open stack using CloudKit is a little bit of a new key. So first of all, I think it's a good place to start doing a review of the definition of building, a telcos definition of a building system. So as you can see, we have three world-defined processes here that take place in a building system. We have the method in process that is the process to get all the information from your cloud, information that you want to build. And as a result of that collection, you will get a collection of samples that you will store to be used later in the way you want. Then we have the rating process that is the process to analyze that collection of samples in base of business rule that can be set, for example, for the marketing department of your company. And in base of that analysis, you will create the build line items that you will store to be used later also. And finally, we have the building process that is the process to assemble that build line items into a per customer build or several per customer's build to start the building collection. So today, we will go through all these processes, and we will connect these processes with the corresponding open stack service. For example, I will start talking about methoding with Silometer and Yuki. Then, Stephen will talk about rating with Locity. And finally, I will show you a brief demo about how you can do bidding reports and how to show graphics in base of that metrics with an open stack dashboard. So as you already know, Silometer is the service to do methoding in open stack. It was launched in 2012 to provide the architecture to collect all the metrics from your cloud, from different services across your cloud, then store that metrics, and then expose that metrics via an HTTP API to be consumed. But after the kilo version, Silometers, the telemetry introduced several changes into this project, mainly to resolve several kind of performance issues that were reported. So they introduced Yuki as a completely different project to store all the metrics collected from the cloud in a new format. They also add a new dispatcher, a Yuki dispatcher that is used by the Silometer collector now to collect the metrics and store the metrics into the new service into Yuki. They introduced also another completely different service that is called AODH, that is for manage all the alarms and the notifications by the result of consuming the metrics, analyze the metrics from Yuki in the cloud, and finally, Silometer, that in this new architecture, just manage the events that comes from our cloud. So host the architecture of this new telemetry system after kilo. As you can see, you have all the Silometer-Asians structure that keeps the same structure that in the older versions. You have the compute, the Asian computes that get information from your instances through the hypervisor. Then the Asian notifications for the events from your APIs, Asian central that get information about the hardware using SNMP and EMI protocols, and all the Asians that collect that information from your cloud send that information through the OpenStack notification bus. Then you have the Silometer collector that collect that information from the OpenStack notification bus, and now split that information in two. First, store the events in their own database and then push the metrics using the Yuki dispatcher to the new Yuki service. Then Yuki process and store that metrics in their own back end. And then another service that is AODH, consume the metrics from new Yuki now, analyze that metrics and manage the creation of alarms and notifications, and store that data in their own database. So in this architecture is more modular. Each one of the modules has their own database, has their own storage back end, and also has a specific role in this architecture and store a specific kind of data. So what's new Yuki and why is so important in this new architecture? Yuki is a multi-tenant time-series metric and resource database for OpenStack. The main change thing is here. It's that Yuki now stores the metric in a new format, in a time-series format, and in an aggregated manner. So this enables Yuki to store big quantities of data, being easily scalable, and also without losing the performance. And that's the most important part, without losing the performance. So to do this, Yuki used two different back ends for storing the data. First of all, Yuki has an indexer to index the resources to then match the metrics and use my SQL back end to do this. And then have another driver that is the storage driver that had the role to push to store the final metrics into usually a distributed storage. So for this purpose, Yuki used a storage like Swift or Set that are distributed storage that are easily scalable and can store a big amount of big quantities of data. Also, Yuki has, as the other OpenStack services, their own API. It's a stateless process. So if you have more metrics coming on, you can store more processes. And also the asynchronous processing, that it's also stateless. So if you want, you can add more process to process more data in parallel. So how is the new architecture with Yuki and Cylometer? As I have said, you have the Cylometer relations in every part of your cloud. This is the architecture that we build in new value. So the Asians are getting information from computers, from the APIs, from the hardware, and pushing that information into the notification bus, OpenStack notification bus, with the Ocelol Diabetes. For that purpose, we use RabbitMQ cluster. Then we have a pool of Cylometer collectors. Sorry. There are a pool of process that get and consume that meshesys from RabbitMQ in parallel, and then have the new Nokia Dispatcher configure to push the metrics into the Yuki API. And as the Yuki API, we have a pool of Yuki API processes under a load balancer that consume that metrics in parallel, then index the resources into a SQL vacuum. In this case, we are using MariaDB, Galera Active Active cluster, and finally push the raw metrics into our self-distributed cluster. So as the first time that the Yuki API pushed the metric into the self-cluster, the format of that data is a raw format, we have to aggregate that data regarding some rules that we created in our Yuki API. So for that reason, we have a pool of Yuki metric processes that get the data, the raw data, from the self-cluster, aggregate that data regarding our policies, and then push the data again. And that pool of Yuki processes are coordinated by our latest cluster. So how we did this? The integration with Cylometer and Yuki is quite simple. You have to adjust a new dispatcher, that is, the Yuki dispatcher, into the default section of your Yuki configuration file. Then you have to add a new section that is the dispatcher Yuki. You have to add some flags that are optional. But the really important flag here is the URL. You have to put there the URL of your Yuki API. In this case, we are using a load balancer. So you will put the API of the load balancer. And then we have the also message in which we put all the addresses of our ribbed cluster, and the Kiston out-talking, and the service credential, like in other open stack services that are obviously connected with Kiston. Now, self-induration. As I said, we are using Ceph as our preferred storage. We have been testing all the storage backends that Yuki provides. Ceph, it's the one that gave us the better results. And we have been working with the telemetry team to improve the performance with this type of backend. So how to integrate it with Yuki? It's quite simple also. You have to add in the source section the Ceph driver. Then you have to add all the information about the pool. You have to create a new pool to use in Yuki. So it's yuki underscore three. It's the name of the pool in Ceph. You have to put the name of the pool, the username, and all the Ceph key ring and config file. All of them are credentials that you have to use when you connect something with Ceph. It's like when you use Cinder and Ceph with multiple backends, the same configuration. And if you will be using multiple metric these to process information in parallel, you have to add the coordination URL. That is based on radius. OK. So once the metrics, we have to create different policies to aggregate the data, as I say in the previous slide. So first of all, you have to create that policies in Yuki before start the metric collection and the metric pushing. So we have here the archive policy. You can define several archive policies. The archive policies are composed by different parameters. In this case, we have the time span that is the period of time that you will store, that you will store your metric. And then you have the granularity that is the interval between the samples that you will store in that metric. So it's like the resolution of the metric. So in the first example, you have a time sum of seven days. So you will keep that metric for seven days. And you will be pushing a sample every 20 minutes. So you will get 504 points. And then you have to add also the aggregation method, like summarize, average, minimum, maximum, et cetera. Those are the aggregation methods that you will use when you use the metric. Then you have to create an archive policy rule, because you want to match every metric and put every metric with an archive policy. So you have to create the archive policy rule that works with a metric pattern, that it's a regular expression that will match the name of the metric, and will put the metric into an archive policy. Then you have to create the resources. The resources are the resources that you get from your cloud, for example, instances, volumes, hypervisor, images. You can add metadata to that resources. In case of an instance, for example, you can add the project DD, the project name, user ID, et cetera, the metadata that you want. And then you have the metrics that Synometer provides for each one of these resources. In case of an instance, you have the CPU delta, CPU utilization, instant sub time, and a lot of more metrics. So once you configure your Synometer relation to push the metrics into Niochi, Niochi will match that metrics in your resources. And then the archive policy rule will match the name of the metrics and will aggregate that data in base of the archive policy that you have in set. And as a result of this matching, you will get the measures, that are the samples that you want, timestamp, granularity, and values. And that's the measure that you will be able to see when you do a query. So some improvements in the latest versions. So the addition of the new resource IPH to create resource, so before this feature, Niochi creates automatically all the resources in a fixed manner, so you couldn't change that. Right now, you can create your own resources. And the second point, you can create the metadata for that resources. You can set metadata for that resources. And you can use that metadata to do a group patience. And that's the first point. So you can do native group buy. For example, if you will get the instance sub times, you had to ask instance sub times to Niochi. Niochi will give you all the instance sub times from all your instances in the cloud. But you want to, that result will be aggregated, for example, by tenant, by project ID, then by flavor ID, and then by instance ID. So you can do that kind of queries. And then you can filter also by metadata. You can just get the metadata for a specific tenant or for a specific flavor. And the last thing is several performance and stability improvements. We have been working really hard with the telemetry team, providing feedback, and trying to solve some performance issues that we had at the beginning. And we get a really good performance, for example, using Ceph. So this is an example. SirRoudox is a different library that the telemetry team created to use Ceph with Niochi to get a faster access from the metric DE and from the Niochi API to our Ceph cluster. So now, Stephen will talk about CloudKitty. And then I will show you an email. Thanks, Max. OK, so you've got your data stored. That's good, but you want to do billing, so you need to apply some calculation on your data. So that's where CloudKitty comes. The goal of CloudKitty is to connect to all your components in OpenStack that are gathering metrics. So it's decomposed in a few parts. That's the red parts on the schema. So basically, first step is to collect the data. We have drivers in CloudKitty to collect data from the Celerometer API or Niochi API. So you can have both activated at the same time or only use one. Every red part is a driver, a SteveDog driver. So if you want to create your own driver because you have some data in a database, for example, some custom customer data, you can collect the data too and push it in the rating pipeline to do specific calculation based on business data, for example. When you've got your data, you need to apply calculation on it. So it's the rating part, the part in the middle. As I said before, simple plugins, you can have as many plugins as you want. And the calculation is done on every plugin. So we have a few plugins in CloudKitty, some plugins to create your rating rules directly in Python. So you can create Python script that will work on the data and do calculation. Or we have a hash map, as we call it, rating module, which is a way to model your rating rules with some objects. So you don't have to create some specific equation to do your calculation. You only create objects and map based on the different object and do your calculation this way. Every configuration of CloudKitty is stored in the database. You have your basic configuration, which is in configuration file, like Kiston of tokens and all the Kiston integration and the basic integration of every collectors because you need to connect to Kiston. But when you're set, you can use the same configuration file for all your processes. And then you configure CloudKitty directly from the API. The goal is to be able to scale up and scale down easily and configure it directly from the API so you can give the right to some people to modify the configuration without the need to access to the servers. We have some integration in Horizon, so you can directly modify the configuration and the rating rules in Horizon. And it's better for security because you're not allowing some salespeople, for example, or marketing people when they want to create rating rules to access the servers and modify configuration files that might look a little bit shady to them. And when you're done, we store the data. So we have a native storage backend that was the first backend that we created. So we store it in SQL Alchemy. It's a SQL Alchemy backend, so basically it will be Postgres or MySQL. And we can store the data this way. All you can use, since the Mitaka release, a new key backend. So basically, you get a reference to your new key information, and you only store the rate. So the final, final calculation. This way, you benefits for all the performances from new key, and you don't duplicate the data. Again, you can create your own storage driver if you want to. And there is a common API on top of storage. So if you're using new key or our native storage, there is only one common API, and you don't need to care about what's behind. About the state of the Mitaka release, so it's our first release with OpenStack. And what we work with in Mitaka is the integration with new key. So we created the first iteration of the new key driver. Basically, we can collect data from new key. So all the data that is in new key, we can collect it in Cloud Kitty, so you can do calculation on it. And we support a hybrid storage in new key. So we don't store all the data in new key because some features were not there at the time of the Mitaka release, for example, the dynamic resources. So if you collect data outside of new key, you need to create resources. And we weren't able to do it at the time. That's why we didn't integrate it fully with new key. Basically, you keep a reference to the new key metrics and resources, and you only store the final calculation. So it's only aligned with the final calculation, and all the metadata and metrics are still in new key. So you can still leverage the scaling capabilities of new key. And we improved the scalability of Cloud Kitty. We added a DLM, which is basically a lock that you can distribute in a cluster. So you can have as many nodes as you want, processing nodes as you want, and shatter your calculation across all the cluster. And Q&A, we added a lot of tests on the storage part to be sure that we don't have any consistency. So about our work with NubeLU, we first met in Tokyo. They were really excited about the Cloud Kitty project because they needed to do billing, and it was a good way to integrate with an open stack and open source component and to make it go in a good way. So basically they told us they need new key integration. We knew that we needed it in some time to integrate with new key, but as it was not requested by people, it was back in the roadmap. And they really told us that they wanted new key integration, they were able to test the code and run it in their servers on real workloads so we can have huge feedbacks. So we put new key on the number one spot in the roadmap, and it was really, really good to have them as a user because they gave us review on code. They tested it on their open stack clusters with real data so we can get a real sense of will it be scaling? Is it working with real data and not test data? You get some data that you might not have thought when you write a test and all this stuff. And they committed patches to what we did. And last slide's about Cloud Kitty before the demo. What we will do in Newton. So the first step in new key was a good step. We improved scalability issues and we don't relate on that much code from Cloud Kitty part. So all the storage will be done in new key and all the collection will be done in new key. So we only do rating and we don't need to focus on storage for example, which is a good thing because people can focus on new key and improve at the same time storage in Cloud Kitty. So the goal is to improve the hybrid storage of new key, create a new storage that will directly store data back in new key. So you'll have your raw data and the result of your calculation. The goal is to be able to use the same API. So you can use new key API and graph. For example, if you want to do graphs, you can query only one API and you graph off your raw data and your calculated data. And you don't need to know two APIs which is new key and Cloud Kitty. We have new collector models coming up. It's part of better user experiences. In some ways, it's pretty hard to know what the data is looking like. For example, if you want to apply rating on an instance, you need to know what the fields and the metadata field will be. At the moment, you need to have some insight on new key and know how the data is modeled in new key. With the new collector model, we will self-document on the API what the object are looking like. So you can have an API call or in our Iceland directly consume API and show to your user, okay, this is an instance object. This is all the field. For example, you can apply rating on the flavor and then you can directly show them what the field looks like. And as I said before, improved storage model. So we will mostly use new key to have better performances. Perfect. That's time for the demo. So, okay, so now we're going to see how to use all of these APIs in the real life. And this is based on our dashboard. It's a new value dashboard. It has several changes regarding user experience and usability from then. But we also added some features like the possibility to do reportings in different ways to explore that reportings, to create charts that are like a graphic way to show the users the metrics and the measures and also the dashboards that we will see in a couple of minutes. So suppose that you have, this horizon is connected to our cloud. We have all the salometer agents pushing data into our new key system. And we will be calling to that APIs to the Cloud Kitty and to the new API. So first of all, we will create new rules because we have the metrics in our new key system. So we have samples, but we need to create the line items with currency values. So I will disable the rating model first because we don't want to create inconsistencies. Then we will create a new rule set that is a set of rules, of course. We will choose these device write bytes. We will choose the unit in which the rule will be base and then an aggregation function. In this case, summarize. Perfect. So once it's created, we will manage that rule set and we will start into create rules. So we will create a new rule. It will be a flat rule and we will put here $10. So this rule is quite simple. We will charge $10 per gigabyte written in the disk of an instance, per hour of course. So you can create more complex rules in a rule set, like the threshold rules that are rules that, for example, I can say I will charge $10 per gigabyte, but if the user writes more than one petabyte, I will charge $10 extra per gigabyte. Or maybe if you can create rules in base of metadata, that are metadata rules, that for example, added to this base rule, if the user will use another flavor, for example, a platinum flavor, we will charge $10 extra. Or if they use a gold flavor, we will discount $5, for example. So once we have all our rules created or our set of rules set, we will enable again the rating module and we will go to the report section. Showback, the report screen. And now we will create a report. That's what we want to do finally. Okay, so now we have the measures, the samples, and we have the line items. And we want to show that the line items in a report. So we will put the name, we will put if the report will be able for common users or for administrators, a little description. And here we have all the available metrics in our NEOGI system, in our CloudKiddy system. So if we want, we can show the costs, or we can show just the measure. So you can choose the granularity from your storage policy. You can choose between several granularities and the timestamp. In this case, one day of granularity and seven days of timestamp. Then we can put a description of the metric because instance, it's the instance sub time but nobody knows that. So we want to show that it's the instance sub time of all the instance from my cloud. We will just show the cost, not the measure. And we will select the group by, the metric groupings and the order. So this is the group by feature that I told you. We will get our report divided by project ID, in this case, then flavor ID and then instance ID. And we will have the partial cost of every one of these levels. Then if you want, you can, for example, filter by a specific project because you want to create a report from a specific project or from a specific flavor. So this is creating, I have created another one to show you, perfect. So this is how the report looks like. So you have the period that it's the granularity, that from your report, we will choose here just one granularity that is one month, 30 days. And then you have a navigation bar in which you can move from different periods. So we are seeing the month of March, you can move to the previous months, to February and so. Then we have the total cost of the month, in this case, $75,000. And then we have the partial cost of the projects, for example, in this first screen. And you can notice that we have two metrics here, the CPU, Delta and the instant sub time. And we are summarizing these two metrics. And we have the partial cost of each one of the projects. For example, the admin project, migration test, that is another project, another project that you have in your cloud. If you, for example, drill down in one of these projects, you will be the partial cost of every one of your flavors in your cloud, for example, the large flavor, medium flavor, et cetera. And if you go deeper, you will have the partial costs of every one of the instances in your cloud. So if you go to the previous month, February, you can see the same information. The total cost, $38,000, then the partial cost of every project in the last column. And if you drill down, you can have the partial cost of every flavor and then every instance in your cloud. So what you can do with these reports. So far you can export the reports in two different formats. One is PDF, and the other is the CSV. So for example, you can export the report and open the report with another application. It can be Excel or can be your own billing application. So you can import that report in your billing application and you can, for example, generate electronic bills or paper bills as you want. Perfect. Another way to use the metrics, it's with graphics. So we have created a new feature to create different kind of graphics in base of metrics. Those are for us, the charts. So we will create a new chart definition with the name of the chart, with a single description. And the chart is created in base of just one metric. It's not like the report. In the report you can choose several metrics. So far in the charts you can select just one metric. And then you have to select the same parameters. The first, sorry, the chart type, if you will use a pie or a column or wherever you want. Then the granularity and the time span of the chart. Then you will choose if you will show the measure or show the cost, you can choose between each one. And the agroupation, like the report, in this case we were grouped by project ID. And then we save this. So once you have all your charts generated with different graphics, we will create dashboards. The dashboards are the way to show, to use that charts. So we will create a new dashboard. We will select if we'll be able to see by a common user or by an administrator user. Then you have to add the charts that you have created. For example, in this case we will select a lot of charts. CPU Delta, CPU time cost, network, average, last month cloud, boom, done. So you have all your graphics there in your dashboard. This is a template, so you can reorder your graphics. Maybe if you have some more important graphic, you can put that graphic at the beginning. Then scale up or scale down your graphics. Those are like JavaScript based graphics so you can interact with the graphics, filtering by, in this case, it's a CPU that you can filter an entire project. Then you can add again of the project. You can interact with your graphics. Then we will put a name and then a description to our dashboard and we will save this dashboard. So these are really good way to show other people, to show other departments how they are spending their money in their cloud. Or maybe to show to a director what's happening in the cloud, how it's divided the cost of regarding the projects or the flavors or the instances. So then they can take better decisions. And it's a really quickly way to see what's happening. You can go over the different parts of the graphic and you will get the partial cost of every, for example, in that case, were flavors. And another functionality is that you can detect if you are having some issue. For example, in this case, this is a bandwidth usage. So if some instances, it's having peaks in the use of the bandwidth, you can just select a period of time, zoom in and see what's happening with that particular instance. So you have, as I say, different kind of graphics and all of them are interactive. And another thing that we can do with this is select this dashboard as our home dashboards. So for the admins and for the common users. So for example, you can select the dashboard as the full home of a new user. And when a user, a new user logging into our OpenStack dashboard, they can select the building home and they have our Picasso with all the graphics and all the charts, the selected charts that we choose to them to see. So that's all. Thank you to everyone to be here and we will respond to some questions. Yes, here we have our contacts, sorry. Just. I had a question on the graphics. Can those be embedded in other dashboarding technologies? For instance, is there a URL where you can call, get that graphic embedded somewhere else? Yes, of course. You can do it. Cool. Yes. We are using an engine, Java engine. It's really common. So you can use it in the way you want. Okay. We are just calling the, using the RESTful API from CloudKiddy and from... You can get a JSON document back and... We get the metrics and just show the metrics. Thank you. You're welcome. So for your backend SAP cluster, how hard does this metrics gathering hit that? Do you recommend a dedicated cluster or is this going to interfere with other uses of that SAP cluster? Well, that's depend of your architecture. I mean, the problem is not the size because the metrics are quite, also compressed, compressive. Yes, it's really indeed compressed. Yeah. So you don't have a lot of size but the performance is different. So the problem is the IO in your SAP cluster. So as you will not need a lot of space, we prefer to use, for example, a little cluster of SSDs or something like that with high performance and low space. Yeah, because basically in your key is slicing your data in small files and compressing them. So it uses your indexer to find where is your data and get it back and show it to you. So you need to access multiple files if you want to have a huge time span. You need to access multiple files so it can be IO intensive. So the key is the IO, the throughput, not the size in the cluster. So we have like 200 instances and all our self-cluster is about one gigabyte of metrics. Someone else? I have a question about the rate calculation. So is there any modeling? Actually you are doing like per server, per power consumption or like a space. So merge it together and say, okay, that's a recommended rate or you already know. No, you have all the possibilities. You can create your own combinations. We are working today in a capacity planning feature and a comparing feature to make comparisons between different metrics and to do some statistic operations, to have a capacity planning feature. But you can do whatever you want. Another question is what's the scale, actual limit right now? How many instance or user or host that you support right now? Well, I don't know the final size that New York will support. We have a cluster of 10 physical nodes with 20, 25, or 13 instances each one. And all the metrics that Ceylonter provides that has been pushed into our new ecosystem. But it's not a big cloud, we know. It's like a medium or small cloud. But we expect to test this in a bigger cloud in the next months. Do you have any plans to support collection analysis of say, public cloud providers like AWS is your Google or not? Perfect, so Nuke's support, Nuke it's a 10 series metric database. So you can push the metrics that you want. You can create the resources and push the metric that you want. Right now we are working in some agents. One for being aware and another one for public clouds to get measures from those clouds and push it into our dashboard. So in the next months we are working to create this kind of agents and try this new, it's like a new business because you will be getting information from other clouds and pushing into our dashboard and showing and do billing with that information. It's an idea for the next months. I don't know if there are official agents to... Now you can do it multiple ways. You can even create a driver for Cloud Kitty so you can pull data from a public cloud. You just create a driver that I get fetched from your public cloud and you apply calculation and you go back in the Cloud Kitty pipeline. Or you can create your polar for new key. So you fetch data, you store them in new key and we process new key data like we process every data in Cloud Kitty. It might be better to do with the new key polar because you're directly storing data and you can run Cloud Kitty when you need and when you want and you don't have to ensure consistency of your data in the input. You know that it's in new key and as soon as it's in new key stored then it will be always there. What kind of tools you guys use for performance, measuring performance, and what was your ideal architecture for measuring performance? Tools for... What was like, like you use a rally or anything like that to measure performance? How did you measure performance of your new key? Oh, okay. The performance in new key? Yeah. Okay. Well, you have different ways to do that. Basically, you have three parts in which the performance is important. The first one is in the storage backend, in SEF. So in SEF, SWIF, or the backend that you want. So there you have different tools like FIO or Rados benchmark or something like that. Then you have the part in the gravity MQ cluster. We know that gravity MQ could be a problem. So you can... You can monitoring your backlog, your message backlog. So you can see there if you have a message that is still are not processed and you maybe have to add more metric these or tune your Ravite MQ cluster. And the another part, it's all the APIs from then or the YPI spool and the metric D processors. So you can, in this case, add more processes to support more incoming metrics in your APIs. And in the case of metric D processors, you can add more processors and you have to use Redis to coordinate that metric D processors to process more amount of data. Because you have a backlog in Ravite MQ and you have a backlog also in SEF. The metric is pushed into SEF in a row format. So you will be a list of metrics in SEF. And that metrics, that row metrics should be processed by the metric D processors. So if the backlog is too big, it's not so good. So you have to add more metric Ds to process data in parallel more and more quickly. Yes. I have a question. The metric list retrieved from Celerometer as time goes on or in a very short time, it will be a long list, right? Included deleted resources with metrics and this list will be displayed in a drop-down list. Does this question, this buzzer is due? I didn't catch that. No. Do you mean when we process Celerometer data, when we collect Celerometer data to process them in Cloud Kitty? The metric list is displayed in the drop-down list. Actually, it's metric list from Noki because they only support Noki. Oh, Noki. Cloud Kitty, at the moment, you don't get directly the metric list. You know what you're supposed to collect. You can activate collection of some specific metrics in the configuration, but you don't have a dynamic list of metrics you can collect from Celerometer. We might plan on adding that in the future, but we are mostly focusing on Noki. We're doing Noki and Celerometer in parallel, but we want to have 100% support of Noki, which means collection and storage and full storage in Noki, and then we will go back to Celerometer because most people, when they have a big cloud, they want to transition from Celerometer to Noki storage because it will scale better and they have better performances and when you want to do building or graphs, you want some backend that will respond really fast to be able to graph it. Your user don't want to wait 20 minutes to get a graph, for example. So most people will directly use Noki API. That's why we want to have a full support for Noki in Newton, and then go back to Celerometer and try to improve the support. Is that answering your question? Okay, so we are running out of time. So thank you to everyone and if you have any other question, we will be right there to answer that. No, not this time.