 Hi Julien, this is Krishna Guram representing the product working group and thank you so much for agreeing to do this interview and to take a few questions and provide our community with your perspective as the PTL for telemetry. So tell us a bit about yourself to start. Yeah, so my name is Julien, I'm the PTL for telemetry for the next six months and I've been a PTL before for telemetry a long time ago like couple of years. I work on Apple stand for five years now, four years on telemetry. I work at Threlats for a couple of years now and yeah, that's all. Okay, lots of experience. So tell us a little bit about, yeah, tell us a little bit about the telemetry project itself. I can see it has had a lot of changes in the last two or one year or so. Yeah, it moved a lot. So when we started four years ago, we were on a single project, like it was a telemetry that everybody knows right now. Then since then we kind of rebranded ourselves to telemetry because we cover not necessarily a larger spectrum of things, but we do, we see things in a different way now. So we have three projects. We have a telemetry that everybody knows, which is responsible for gathering data from the cloud, from OpenStack and everything that runs and uses OpenStack. We also started another project a couple of years ago which is called Gnocchi, which is a replacement for the, for the, for the, for the iteration of the data that's pretty poor in terms of performance. Everybody knows that. I mean, we've been acknowledging that for a couple of years and, you know, Gnocchi, which is a better solution to store all of the data that the telemetry gather and generates. So that's our second project. And another project, which is a bit older, is A, that's AODH, but it pronounces A. It's a Gaelic word, which means higher. And it's the Cinometer alarm code that we split off of Cinometer last year. It's the same code base. We just moved the functionality out of Cinometer to build something which is more modular and installable in small parts. So it's easier to deploy Cinometer and different components depending on what we need. Okay, excellent. I think that summarizes the telemetry project. So tell us a little bit of what were the hot topics in Austin? Yeah, so we did discuss a bit about, I think we want to read the next cycle in, in telemetry. I think we'd like to add the benchmarks. We want to work a bit on profiling, improving our preferences in Cinometer and other projects like A and Gnocchi. So there's a walking group at the OSIC, OpenStack Information Center, working on benchmarks for Cinometer and probably Gnocchi and A2. So we did discuss a bit with the guys on that on the OSIC. We're going to work with them in the next cycle, fingers crossed, to have numbers, interesting things, feedback, profiling data, so we can improve our stack in this cycle or during the next cycle. We'll see. It depends on when the results are going to come back. A thing we want to, I think, improve a lot is documentation. Well, not the worst project in OpenStack right now, but we know that people struggle with a lot of things in Cinometer and A. We have a terrific documentation for Gnocchi. Everything is documented. We have a policy which is no documentation, no patch merge. So developers have to revise the documentation with the patch to have their features implemented in Gnocchi, which is awesome because everything is documented. There may be a few exceptions of that, but we want to do the same thing for Cinometer and A right now. So it's going to be one of our topics during this next cycle. The doc team from the OpenStack, and you all realize that we're not about to cover the 54, 55 projects of OpenStack. It's amazing number of projects we have in OpenStack right now. It's on scale. So we're bringing back our documentation from the manual team, the documentation team to our side, and applying a policy which makes sure that we continue to have a good doc and a better documentation in the next cycle. Excellent. I think you summarized that well, a lot of testing, a lot of documentation, and so on. What were some of the user needs that you're trying to solve? User needs or problems that you're trying to solve? Well, I already talked about documentation about Swan. We don't have any like feature requests. We used to have a lot of things in the last cycle, precise feature people wanted to see, but I think it's slowing down a little bit. We do have a lot of features already. So probably more stabilization, but also a need of being able to deploy more easily like something in OpenStack in general, which is a bit problematic, but it doesn't work by default. We did a lot of efforts and experiments, I would say, on Nuke on Black, so that you can just install it, and it works by default. But there's nothing to configure by default in Nuke, it just works. We're going to do that with our cinematometer and A2 to have more same default, but you can tweak our software to your needs obviously, but it just works, but if we don't have to read the whole documentation and the whole complete file, things like that, it's more too complicated to deploy. So we're going to improve that a lot. First, in telemetry, maybe we will bring some new ideas on the table for other projects to would like to do that. So we'll try that. Okay, excellent. You did mention there are not many features, but still what are some of the top two or three features you think will be worked on for the Newton release cycle? On the cinematometer side itself, I don't think, I think we have enough coverage of posters or data gathering in general, we have enough things covering all that. One of the features we want to finish, because we did start it during the last cycle, the pulling improvements we talked about. So we did a few improvements on the pulling side, we're defining all the pipeline steps are defined, et cetera. Things have been started, but not finished lack of time as usual. We'd like to finish that during this cycle. That's a big thing for our cinematometer. I think for my main concern right now is to bring the documentation very up to date, because when we started A a year ago, we just take the documentation that was in the cinematometer and was about the alarming code and it was like very few documentation. So it's badly documented. And it's one of the projects that we designed like the key to be able to work standalone, like without the rest of OpenStack. So there are people right now using new key and deploying it without OpenStack just as the time series database and being able to deploy A, the alarming part, we have new key set with all the rest of OpenStack is one of the goals we want to achieve too. But that goes through having good documentation because if you don't have any documentation, nobody's going to be able to install it and to deploy it. So that's one of the things. There's no big new feature in A. We want to stabilize the software a bit. We've done that in the last cycle. That's probably what you think we're going to improve to on that. The event part of A needs some work. We have at least one or two developers working on that too. There's not nothing new, but it's just stabilization, some small features there, this and that and things like that. And for new key, we don't have big features. A few people requested an OpenBurg on Lodgepad to request featuring the API, doing more computation of the metrics on the server side. So that's good ideas that are acceptable. Things we are going to implement in the next week. Yeah. There is one question though I wanted to ask you. It shows up on the product working groups roadmap for some improvements in telemetry and particularly in the area of NOVA polling reduction. So is there some work planned in this new cycle for that? So there's ideas, but there's no work plan. The big problem here is that we do our best on the similar side to poll NOVA, but we do have to poll NOVA with the API provides. And the API provides, it are not very good for what we need and what the people want to gather as data. So to do that, we need to change NOVA, which is very complicated in the next time. So that's not really, I think there's work on our side to propose something to NOVA that we didn't do so far because we are a bit reluctant to go to NOVA because it's not our project, it's different. But I think at some point we're going to need to say, but this is what we need as data. This is how we poll it right now. It's not very efficient. It's slow. It requests a lot of data in different ways from NOVA as of the week of request. We didn't provide the last cycle by adding caching, which adds, but it's not a correct solution. It's like, you know, it's peppering over is a problem. So we need to solve that at some point. Solving it is going to be done in NOVA partially. So we need to work with them. It's complicated to extend. We'd like to do that. We need people to help us on that. Okay. So yeah, you talked a lot about the testing and documentation. So what would you say are your key themes for Newton? I think one of the key things right now is going, is going to split a centimeter to continue what we started last year. So we started by splitting the alarming modules in A. So this cycle, we're going to start a new project. It's named Banco, P-I-N-K-L. We're splitting the event parts of the API of Cilometer in its own project. So we're going to same code base, same test, same documentation. We're not going to change anything. We're just moving the code in a new repository. So there's a lot of people using Cilometer, but not using this events part because it has been started a couple of years ago. It's not really finished. It's usable. You can store events, but the API is quite simple. I mean, we know there's not a lot of people deeply on it. So there's no need to having people deep-reading an event database each time they want to deploy Cilometer. So we're moving that the same way we did with A in a new repository. We're going to keep the code in Cilometer for one cycle. We'd like it as sometimes people to move on and to say, well, I want to use Banco because I'm using the events of Cilometer. So I'm going to install it. But if you don't want to care, it's just less code, less things to maintain. So it's good. We're really trying to, not every cycle because it takes time. And it's, it also was in fact downstream and I'm trying on. So we want to be nice in text, text time anyway, to do that. But we want to be nice to people who are consuming Cilometer. So if we do that, like once a year is good, it's a good speed to do this kind of moves. And it improves a lot our ability to as developers to maintain the code. Like we have different team right now for Ion Cilometer, because there are people very interested in mentioning the falling side of Cilometer. And there are people that knows a lot how to do iterator arms. It's different things, it's different projects. And we have module like that you can install that works very well together. They're easy to install together. But if you don't choose them, you don't choose them, you just don't have them. They work also. And that was one of the points. Composibility is one of our key team, I think, in this cycle again. And the ability to be able to install our piece very simply with good documentation. Simplicity and also like you mentioned modularity. So you have just like we did the A module for the alarming, you know, I have a separate banco module for the event coming out of Cilometer. So that's great. That's a very good summary there. So is there anything else you'd like to add? I mean, you've covered a lot in very short time. So yeah, yeah, we're a very small team. So I mean, I'm very interested in helping us in telemetry, but they very happy to have you joining us. You can join us on IRC. We use a lot of them in this distance or people problem where we have new contributors every cycle. We're very happy to have them joining us and helping us. It's a very interesting and broad topic. So what would you join? Absolutely. I'm sure a lot of people will be quite encouraged to join the team now that it's been so much of activity in so many areas. So thank you for your time, Julian, and wishing you all the best with the Cilometer release with the Newton cycle and for those cycles beyond and looking forward to meeting you in Barcelona. Yeah, sure. Okay.