2:31 Hello, and welcome back to the Rawkode Academy. This is another episode of Rawkode Live, the show where we take a look at cloud native and adjacent technologies to hopefully make your cloud native and microservice journey just that little bit easier. Today is no exception. We're taking a look at a fantastic project called Perseys. This allows us to do dashboarding as code, which has been a lifelong goal of mine for many, many years. Guiding us today on our journey is Nicholas. Hey, man. How are you doing? Hello. Hello. Doing great and great. How's it go how's it going, Dave?

3:06 Yeah. I just wanna say thank you so much for joining me. I'm very, very excited for today's episode. I can't wait to show people what Percy's could do. But before we talk about Percy's and what it is, could you just take a few moments to say hello? Tell us a little bit about Nicholas. Yeah. Sure. Sure. Thanks for having me. Hello, everyone. My name is Nikos Takash. I'm a software engineer working. I'm already working in different things. But on the last five years or six or more, maybe I've been working mostly with observability stuff around like CNCF ecosystem,

3:40 Prometheus, OpenTelemetry, and Persis on the last two years already. Like, I'm open source contributor, maintainer from Persis, maintainer from Prometheus operator, and pushing codes like around the community. And that's basically me. Awesome. Thank you so much for sharing. You're involved in quite a few projects. So obviously, source is what you're doing day in and day out, which is fantastic. But also, I mean, it must be hard trying to juggle all these responsibilities. Right? Yeah. Like, it's it's a little bit, you know, like, especially when you like, sometimes you you you're getting the maintainer role when you are mostly working

4:21 on the project on daily basis. And all of sudden, your spread suites, and then you need to kind of keep, like, maintaining the project, but you are not working with the project, like, on your daily basis. So sometimes, like, purses at the moment, I'm working in purses, like, by by the law, as I used to say. I'm not using purses on daily basis, but I like to contribute. So free time, a weird kid, instead of going play video game, I like to be on my my ops writing code. But, yeah, it's a very nice nice nice stuff, like learning

4:55 a lot of things, getting to know a lot of people in the community. So it's pretty amazing. Yeah. I mean, that's definitely one of the great things of open source. Right? You get to meet so many amazing people. You go to and you get to chat to everyone, have a coffee, have a beer, whatever. It's, yeah, such a great space to be. But then there's the hardships of I don't I'm very fortunate that I don't maintain anything with any adoption whatsoever. So, like, people don't open loads of issues and drive by pool requests and stuff like

5:22 that. But that is a real concern for for, you know, especially CNCF adopted projects. Right? There's a lot of people that just come along and Yeah. It must be hard for maintainers. I don't I don't envy them at all. Yeah. And especially because one of the things that I used to say to my friends is like, when they need an open source project, especially large open sources like Prometheus and OpenTelemetry, BERCES and so on, it's like you need to be very, like, thoughtful about what you're going to accept, you know, because any new code, it's like

5:52 a new thing to maintain. Like, the team is usually very, like, low amount of people maintaining the project. So you need to be very careful. And a lot of things is really funny. It's like, usually, you have a lot of people to write in codes, but maintaining open source projects much more than writing codes, like reviewing PRs, keep you keeping up with documentation and and and all those things. Yeah. Alright. I I know why I turned this into, you know, ethical conversation of maintainership, but it has its challenges. But let's we we can always get back to this.

6:27 Right? If the conversation takes us there. But I do want to just, like, get people acquainted with the Percy's project. Let's assume they have not heard about it before, maybe until they're watching the session, whether that be today or in six months time. And they're like, what is it? How how is that gonna benefit me? Can you get people to run down on what it is, why they should adopt it, what we're gonna be seen today? Yeah. Sure. Like, cool. So what is Persis? Persis is basically an observability dashboard project. Like, can build in dashboards

6:58 like you do with like other solutions like Grafana or maybe a posh. There's one a posh approach that I forgot the name, like you can build in dashboards, you can connect it to data sources, and you can create your dashboards like we do with Grafana, you know. But like, what is the main difference and reason like for for using Persis and adopting Persis? Like the first one, Persis is truly open source and vendor neutral. Like Persis is open source approach under the CMCF landscape. It's maintained by different engineers in different companies. We have people like you have me at

7:35 CoreLogic, you have people in Ramadill's, you have people in Red Hat, you have people like in other companies maintaining the project. So the project is not focused on any single company to solve a single company problem. We are here to solve a community problem, you know. One of the biggest advantages of Persis is the how easy and how, like like, how can I say that? Like, how easy and how, like, integrating the ecosystem, the dashboard as code concept is is implemented. So Persis since the day one was developed to be developer friendly. So developers can view

8:16 the dashboards as code easily through the SDK. They can look to the dashboard definition or to the data source definition and be familiar with the spec. The spec will not that much, you know. And one of the very, like, the one of the biggest wishes is like versus data model, like the API's and the dashboard scheme and data sources scheme and become the, like a crawl community adopted schema. So other vendors can adopt the schema and use Persis schema for dashboards and people can just migrate their dashboards from one vendor to another. What is really nice because we already have

9:00 some vendors on the industry adopting the Persis schema, you can basically eventually move your dashboards from one side to another without working very much on the dashboards. Again, it's very beautiful. Like when you're talking like that, we know the challenge because each vendor has its own, plugin system panels and configurations that eventually, like one panel will work in one vendor and not working on the other. But the idea is to reduce this friction friction as as much much as as we we can. Can. Nice. Awesome. So, I mean, I can only imagine the amount of work that goes into building the dashboarding

9:45 thing must be I mean, it must be quite a lot. Right? Because I unfortunately, I don't know. Unfortunately or unfortunate, you can take it whatever you want. Right? But I used to work for InfluxData, the people behind the InfluxDB. And this is something that they struggled with a lot. It's like they had a really great and they still do, like, fantastic database. And they tried for a while. Like, influx DB one, I think, relied on Grafana. Influx DB two, they decided, oh, we're gonna ship our own. And they had, like, a project a project called Chronograph,

10:16 which also worked with Infox d b one. But maintaining that was such a time sink away from their core business model that with Infox d b three, which is now the Rust rewrite that's now out now, they don't have a UI at all. And now it's just like, you know, use anything off of the shelf because it's not a simple thing to build. You have to work with different they only have to work with one data type. You're gonna have to work with Prometheus, OpenTelemetry. There's once you get past all the different disparate data sources, there's a visualizations. Are you gonna

10:46 show a line graph, a bar graph? Are you gonna show time series correlation? Do you have shared cursors before sales? Do you have definite rules? Do you want to show donut graphs? Like, I mean, it's infinitely complex, and it doesn't really seem to have there's not, like, a fixed scope. So I didn't mean to scare you away from being an open source contributor. I'd like, oh, shit. It's like, let's just leave and and call it. Right? But it's such it's a huge undertaking. Grafana has been building their product for over a decade. And so I

11:15 love that Persis exists and has taken up this mantle of being the open government CNCF, completely open source approach. But damn, that's a lot of work. Like, I mean, there's a lot to do. So maybe you can give us a bit of a rundown on what can people do with Percy's today. Let's start with that. Yeah. Sure. Like, basically, today, we already have support. Like like, before I talk what we can do, I need to give a overview about, like, basics architecture of Persis. Persis is like a React application with a Golang backend. And, like and all the deep

11:53 work is on the React side on the front end side, because like it's a dashboard solution, you know, it's like it's mostly front end. And the architecture of process is based on plugins. It's like looking system. So everything inside processes of plugin, data sources of plugin, panels are plugins, and many other things are plugins in process. And we can load all those plugins in runtime. So this is like a very TLDR thing about Persis. Okay. So based on that, like the native and ready plugin that we have from very long time is Persis plugin. So you

12:33 can connect Persis into a Prometheus compatible API, like Prometheus, Thanos, Mimir, Cortex, whatever. And you can query your time series, you can building time series panel, bar charts, all those things, tables, and so on. As time passed, I think last year, maybe we had Grafana tempo data source where you can query your traces in Grafana tempo and and handle them in a a panel as well. During Cubicle, we were finishing the creation of the plugin system to make it more easy to creating new plugins to new contributors, because we start to getting a lot of

13:22 interesting on the project and say, okay, but I want to my logs are on Elasticsearch, how I can connect the Elasticsearch on purses, how I can connect to click the house of purses and so on. Like you did this, how to connect it, like, influx DB in purses. So we we finished the migration in March or April, if I'm not wrong, like that allows we community to extend Persis to adding new panels, add new data source types or any kind of plugins that we can see. Like for example, we have a colleague sharing on the Persis dev

13:55 channel at on this like CNCF channel, where he's ending up looking to have a chat LLM chatting side versus so, of course, we need to have something like that. So you can you can extend process based on plugins. So this is what you can do today. You can query Prometheus and time series and Grafana tempo, and we started having other contributions to provide the peak house data service and all other data services as well. Sweet. So is that a really good position to be in? Right? Because the plug in system is now in a position where companies can contribute. I guess there's

14:41 and because it's a CNCF official project now. Right? Like, hopefully, these other data space database companies come forward and start contributing as well to have their database support. I think, you know, if you're working at, you know, Reddit, Mongo, DuckDB, I don't know. Yeah. I mean, if we've got someone from Polar Signals and a shot at him at this, you know, it would be really nice just to see these different databases work with Percy because it really is, I think, the only option right now for a truly open source and well established dashboard in tool.

15:14 Yeah. Alright. Cool. So I'll ask you where the project is going later, but I think what we should do is share our screens and and show people how they can get started. Because, you know, I said this at the top of the stream, but dashboards of code has been something. I mean, I I literally think I've dreamed about it at some point. Right? I've always wanted that. I don't like this click ops point and click and then just hope that it's there forever and I'm doing database backups and stuff. Like, we want to bring it

15:42 into the full development life cycle. We wanted to get pushes. We wanna see deaths. We want pull requests. We wanna track changes. And Percy's delivers on this. And this is the thing that caught my eye. And I was like, this is it. This is the finally, we have what we want. So I'm hoping we can show people all the good stuff today. Yeah. I hope too. So let's go. No pressure. I don't mean to just hop on on. Good luck today. But if you could share your screen, we'll move over, and we'll show people how to

16:09 get started. Yeah. For sure. So If anyone watching has any questions, please feel free to drop them into the comment box. We will tackle them as we move through the session. Alright. I can see cursor. I see us in the corner. I think we are good to go. Take it away, man. Okay. Cool. Cool. Cool. So I have a pretty empty Git repo that you you guys can access later. Should I zoom in a little bit or no? It's it's fine. Yeah. Zoom in is always appreciated. Yes. Okay. So another one. First thing that I will start doing here, like,

16:50 you process, you can, like, run for your for your computer, like, where is browser? Okay. Like, this is official person's website. Okay. You have, like, under docs section, we have some we have some user docs and and installation and configuration and so on. So you can basically install Persis from the source, you can ditch clone and you can build in Persis on your machine. You're gonna need like go, note and NDPM. Or you can use an existing Persis Docker image if you want to run it quickly, you know. So what I'm gonna do here, like just

17:32 to get some time is like, I will run from from Docker container. So it's pretty pretty fast. I will create a Docker Compose file. We will need to configure some some some code here. So just copy and paste, like what we have here, persist image. This config file is where we are going to define, like, how persisting the distance will work, like, what is the kind of data store that we're going to use? We can use file season or you we can use my SQL, if I'm not wrong, to be our data store. You can configure, like, where your dashboards are

18:13 available, where the data sources are are available. In this case, like data sources and projects. And you're gonna you're we are going to understand better what is project here. So let me get the config files here. So purses, and then the first thing is going to config dot yaml. Here we have a base configuration. This is for local development. So I'm telling, like, it's the only files. I don't have any kind of authentication or authorization configured. Okay? The database, I choose to run ads file, and I'm like Persis allows you publish your resources like data service projects dashboards,

19:05 like, in two different extensions. You can choose YAML or JSON, like you, whatever you prefer. I personally prefer YAML. So we're going to use YAML. What is the folder where we're going to to like store the the resources, you know, and the provisioning folder where we processes keep watching for new data services, new projects and reload the UI. So with that configuration, I think we can already see Persys running. Let me see Docker Compose up. For people using Kubernetes, we also offer a Helm chart that you can easily install Helm install, and you're gonna getting all the configuration

19:54 out of the bot with minimal setup requirement. So if we're gonna local host eight eighty, like, this is Persis UI. Okay? Like, of course, we do have dark theme because it's a dev tool, so you you must have this is the first feature. You know? Obviously. And what you can see here, you can see admin with some global variables, and we're gonna getting on these concepts soon. Global data source, global variables, and global secrets. You can also see live config. And you can start interacting with the UI if you want. We can, for example, creating

20:34 Rawkode project. Like, every dashboard in process is attached to a project. And I like to think projects as Kubernetes namespaces. Okay? And then you can create in dashboards, you can define variables, you can define data sources and like all those configurations, they are attached to this single project, which means that other projects cannot see variables and data sources that are inside this project. Okay. We also have the notion of global variables and global data sources and global secrets. As the name suggests, it's global. Any project can use the resources that you define as global. So what is nice, especially especially about the

21:24 global variables like like probably everybody using Grafana already have this use case. You have a variable that's every dashboard in your company should be using, like cluster name. And every dashboard is defining cluster name over and over again. And one day you are changing the label values, you are loading the cluster name variable, and you need to change all your dashboards. Using global variables, you can create in the cluster name variable here and all the dashboards will be out of the box getting this variable as well. So if someday you need to change anything on this variable, you change

22:04 it on the global variables and it will be automatically implicated to all dashboards because they are inheriting it from the global configuration. Okay. And this is very useful because like changing all the dashboards all the time sometimes is pretty tough, especially if you're not using dashboard as code. Okay, cool. So let's move back to Corsair. Let it running here. Let's add in more few other configurations. Like, I will add the project configuration under this folder, pro. Yaml. And I will add a data source as well. Data source dot yaml. So if you look to this spec, like like

23:01 project and data source, let me put that side by side, if I could. Yeah. Is it familiar? Right? Like, this is Kubernetes spec mostly. Like even if you're not running in Kubernetes, Persense API speaks Kubernetes API. You can read here and can easily identify the kind of resource you're creating, the name, and you are pretty familiar with spec, you know, that from users to users, you expect a different spec. And this is very, very interesting because we also offer process operator and there is minimal translation here because process API is speaks Kubernetes like manifest, we can easily make this a CR under

23:52 the cluster without translating later between CR and the actual API call. Do not mention this is easier to read. So we create a project. This is the minimum information we need for project. And this is a data source, a global data source we are using from lab. So thank you, Julius. And yeah. That's it. Like, we are going to update the Docker Compose. I pretty sure need to restart container. And that is the end. Let me see. Let's go back to UI. We already have the default approach here as we created, and we also have

24:41 global data services. We have it here. We can have some configurations like adding display labels, data sources, they have two methods to of working the like these permits data source, you can use direct access. So it's basically browser doing HTTP requests, like fetching requests to the to the data source address, or you can use a proxy and like in production environments, we usually suggest you using proxy because it goes from purses UI and who's go who's making the the HTTP request is purses back end. So if you need to have those secrets, if you need

25:20 to handle all other kind of sensitive data, like proxy is the way to go. In proxy, we also have ability to control what are the paths that we want to fetch, you know, like, imagine that you own your API, you have a different path to handle query hinges, you have a query hinge ever altogether without the underscoring, separating, splitting the words, you know. Cool. So this is the bare minimum. We already create dashboards. We can come here and like Rawkode live. And then we can add a group. First group. Groups are basically roles in Grafana, and every

26:11 panel in process must be inside a group. You cannot have panels not being part of a group. Okay? And you can start adding, like, let me see default. We mark the data sources default. Like, you have more data sources, we could probably select the others here. Let me try I don't know nodes, node, CPU, seconds, total. Yes. Seems pretty nice. We also have variables. You're missing an r and interval. Oh, that's true. Interval. And no, not a four anymore. You see, we also have variables. We have interval. We have eight rating interval. All the the special variables we are using to to

27:07 using Grafana. And let me see. Oh, no way. I copied the wrong. Byte mode. So maybe yeah. What I'm missing? Do you mean by node or mode? I'm missing a I forgot how to write in from expressions. So node, CPUs, age, total. You can do a lot of configurations in terms of settings. You know? You can, like, oh, bottom, table, main max, main. I think it's average, maybe. Yeah. Average. All the configurations regarding thresholds, regarding all the things that we are used to doing your file as well. You know? You can add it here. You can resize.

28:11 And like, that's it. This is a this is a person's dashboard. You know? Like, if you come here and look to the spec, where is spec? Okay. This is the spec. We can see again, this is Kubernetes like spec. And you can see like, okay, I have panels, I have layouts. It's basically defining the grid system, the grid system size, how many panels I will have on each row and so on. Details about the panels. Like, let me see. Remember I mentioned that everything in Processor is uploading. So as we can see, the time series chart we are using is

28:53 also a plugin. So as we can see plugin, the kind, this time series, and then we have the spec of plugin. So every other panel inside PERCES is also a plugin, which makes Persis super extensible. You can we can create new plugins and sheet as part of the core project. Or if you're in your company, you're doing something and you need a very crazy plugin panel that shows you, I don't know, some weird data formats, you can write in your plugins and build your own Docker image, editing this plugin in there. Cool. So far so good. Questions?

29:35 Yeah. I guess I I'm curious about a couple of things. So currently, we're creating in Prometheus. We're using PromQL. We've got access to variables. Like, these are all the kind of bare essentials I would expect to see in a dashboard and tool, which is very nice. You mentioned that all the different visualizations are plug in. So I guess, I'm curious what visualizations or panel types do we have available just now. What is the process of adding new plug ins? Is there a plan for, like, some sort of package manager, like MPM or something to bring these in, or do you build

30:09 your own container image? Let's let's start with one question at a time. Right? What type of panel visualizations do we have? Sure. Like, at the moment, those are the type of panels we have available. We have scattershot, time series, trace Gantt chart, Gauge chart, stats table, time series table, trace table, bar chart, markdown, pie chart, and stats history chart. Nice. Those are the panels. We have a lot of, like, development recently on the table panel to allow us join series, transform, and do all the magics that we we we can do with tables. And we constantly having new issues asking for

30:53 new tables and so on. Since the new plugin system is available, we are mostly open for contributions for new panels as well. I remember seeing some pool requests under review to have flame graphs because we already have people looking forward to have profiles in process as well. Yeah. Cool. Regarding the other process for creating new plugins, basically, like, issue on the repository and, like, we're going we are discussing between within the community. Like, there is no formal process yet. Like, last time I remember we talking about that at cubicle, need to figure out, like, what's going to

31:41 be core plugins that will be maintained and shipped maintained by the purses, maintainers and shipped with the core, purses image with the per docker image we are bringing right now. And what are gonna be clue community plugins that we can even ship with the same Docker image, but not being maintained by the official Persis teams, you know. For example, I don't know. Maybe someone say, oh, I need SQLite plugin. Like community loves the idea, but we don't have anyone using SQLite on the team member. We don't have like like power to maintain the plugin as it

32:23 should be like but someone in community wants to do that, that wants to offer, donate the plugin and like, they can publish in viewership as part of the the core if it makes sense. Okay. So what's the failure mode then? So, you know, we're we're talking about doing something here that is is as code. So if and my YAML, I am seeing that this panel needs to be a time series v seven panel, and that plug in isn't available. Does the apply fail and everything whether is it just isolate that single panel and that becomes a failure? Like, how does this cascade

32:58 done? Only this single panel will fail. Okay. That's good. That's exactly what I wanted to hear. Now Yeah. Side quest time because I don't think this is anything you wanted to talk about, but my curiosity was piqued. When you were in cursor, I realized in the Docker Compose remote and then those three different YAML files, and the database is disabled because I think we're using local file for for state. Is that right? Yeah. Yeah. Yeah. Here, we are using local file system for for persistence. Yeah. You're right. So does this mean that our slash Percy's is just

33:32 now full of YAML files describing the entire state of this Percy's configuration? Yep. Wow. Nice. I like that. Yeah. Good. So you had another question regarding CLI and MPM packages and so on. I might not 100% sure, but, like, because I'm not into deep looking systems development. But from what I saw, what our colleague's talking about, it's like we have a CLI that we're gonna see in action as well, named Persis CLI. And if understood correctly, we're going to have a scaffolding command to to help people creating new plugins. So Persis team, sorry if I'm saying something

34:18 wrong, but this is what I briefly remember about this subject. Does that mean that in the same way we can go to the artifact hub and look at, you know, rules, rules, Helm charts, that we may just see a section for Percy's plugins in the future. Yeah. That's that's a really good idea. I didn't didn't talk about that. Like, we we already discussed ideas of having a marketplace to to be able to like find these plugins, dashboards, data sources in the future when, when the plugin system is more like adopted, adopted across the community. But that's really a nice

35:01 idea of publishing to some sort of history. Yeah. Alright. That's all my questions for now. I'll remind anyone watching, if you do have questions, drop them in the chat, and we'll do our best to get to them. Feeling that, we can move on and and take a look at something else. Amazing. So let's go let's see some dashboard as code in action. Just for now, let me start git. Like, initial commit. So what I'm gonna do here, like, we have to like, Persis allows you creating dashboards in, I would say, four different ways. K? Through the UI, as we just

35:55 did. You can write in your YAML or JSON definition by yourself if you are brave enough, or you can use one off of the SDKs that Persyst project is is providing at the moment. We have GoLang SDK and we have QLang SDK. So all the data model of Persis behind the scenes, the plugin system, the dashboards, models, and so on. They are based on QLANK. And we are generating other codes like TypeScript models from QLANK because it's just easier for us to commanding a single language and generating code for from there, you know. So you can create in dashboards using QLang

36:42 and you can create in dashboards using Golang. I'm not a QLang guy, so I'm going to show you right now how to do that using Golang. Okay? So it's pretty simple. Go mod mod init. Let me see. Perse wrong. Perse's back. Yeah. It's fine. And we need to add a few dependents that I need to, of course, look to another place to to take this because I don't remember by heart. Give me a second. We got a yeah for QLANG being mentioned. I'm equally fairly good. I am a a QLANG and a guy, and I I'm disappointed

37:27 for doing Go. But you know what? Maybe Sorry. Maybe I'll feel brave enough to take the the reins off you at some point and then try and do the QA example. Yeah. Let me see. You've gone yeah. Like, no. Not this one. Too many hippos. Where is that? Okay. I found it. I found it or not? No. Where is that? It was just with in front of me. Okay. Yeah. I do found it. I do find it. I would look to to the dashboard to the the Hippo I use in at KubeCon as a reference.

38:19 So, yeah, we need to add, like, go get process to add process as a dependence. This will allow us using the dashboard as code. So just create main.go package main and then main. Yeah. That's that's everything that we need. So how good is cursor, right, in go SDK and for the code dashboard? That's that's really good question. Never did that. So we we we can, like, we can try later. Like, that would be interesting. Yeah. I want that. I mean, let's not do it right now. Like, you do your demo, but I I've got a crazy idea.

39:07 So we'll we'll see. Yeah. So first thing that we need to do, like, it's a it's a go go program. Right? So we can leverage everything that we have on the go ecosystems, like flags. What else we can use, like, unit test to create your dashboards and test it. Like, it's it's a good program in the end. Yep. So first thing we're gonna do, it's, like, set up in the the new the newest the the SDK. Let me get a few things here. Couple of those imports. And then we can first create the dashboard. Like, the main thing to create the dashboard

40:03 is dashboard dot new. So what is missing? You have an extra a on dashboard. Dashboard dot new. Thank you. Like, you are really good by programming. It's it's easy when you're watching. Right? When you're typing, that's when your brain cells disappear on you. But Yeah. So dashboard dot duration, like, just define the duration. It's gonna be time dot hour. I can remove this 24, and then we can provide the dashboard name. It's gonna be this one. And dashboard, we can assign a data source with dashboard data a data source. The data source needs to be the name

41:03 of the data source we we created. So let me here. It's going to be Prometheus demo, if I'm not wrong. Are there lookup methods as well to make this more dynamic? Sorry? Could I do dashboard lookup and find one or get a list of data sources, like, if I wanted this to be dynamic? Right now, Prometheus demo is kind of you know, it's a hard coded string. So Oh, yeah. Yeah. Like, you could you could like, there is one option in person there's an option person's name source discover where you can provide an an endpoint where the process can

41:45 do like service discover for data sources, you know, so you don't need to hard code it. You can and also you can just assume eventually that's going to use the default data source for the for the project or for the for the entire instance. You know? Yeah. I'm assuming could I define the data source as part of this Go SDK as well? I don't think we have that yet, but let me check. Process model. I don't think so. No. No. No. Probably only the dashboards. Yeah. Oh, not yet. Request. Feature request. Not yet. So we're gonna do here. It's like let me

42:30 get, like, all the configuration. I'm showing, like, how to define even the data source inside the project just to be easier and people be be aware of the capabilities. So let me copy the other import we need here. Because you are defining a data source. Right? Sorry? You are defining the data source. If you're Yeah. Yeah. I'm I'm definitely definitely defining it. Yeah. Alright. Okay. Definitely defining it inside the the dashboard instead of using the the existing one. So what's happening? Could not import. No. Think I already got it. Maybe we change the directory. Go

43:28 versus SDK. Yeah. Go SDK, and then we have the actors, we we do have dashboard. This is the part where we forgot where the things are. I'll let you work this out before I ask you the hard question then. Yeah. Yeah. Okay. Give me a moment. Let me look into a different source. Yeah. Take your time. Yeah. Like, person's niche community dashboards. Yeah. This is nice because I can even show you the community dashboards. Like, this is a repo where we ported a lot of Prometheus dashboard, like, dashboards from different CNCF projects to to Persons. So we can

44:33 everything is written using Golang SDK. If you need the Prometheus or Node exporter or tunnels or Kubernetes API server dashboard, you can just use it. What I want to see some example of the data source. Let me see here. Maybe you have this here. Go. That's it. Okay. Where's the path I need? That's Prometheus. Uh-oh. Okay. So seems not not existing anymore. I'm looking to a different place. Okay. We are gonna we are gonna manage. Ask cursor. Yeah. So, yeah, that's a good quest let's do let's see if cursor can help us. It's surprisingly good. Or, I mean, I'm pleasantly

45:54 surprised by how good AI is these days when you give it just enough information to be dangerous. Like, it it it can really help. Yeah. I think I'm expecting it will it will be be able to find the storage. It's gonna be able to go through the dependency tree much faster than Yeah. You will be able to. Remove is my dependent. Okay. Let me see. Vibe coding on on on the livestream. Nothing wrong with that whatsoever. Okay. No. Let me remove yours. Never mind. I while cursor is trying, let me see if I can figure it out to the dashboard as

47:22 well. Let me look into the documentation. Right? Data service. So the Prometheus structure is just an Yeah. A data source. It doesn't seem to be go SDK slash data source. Yep. Yeah. Okay, Chris. Thank you. Yeah. This is the data source. And then what do we have? We do have This is not what I want. Oh, I see that. Oh, no. Prompt oh, I see the end Prompts. This is what we want. Like, like, go back this one, this. And then yeah. Like, Doc's better than Coursera. Ah, there you go. A plug in. Course. Yeah.

48:28 We changed wasn't core, and now it's a plug in. That's probably the what changed here. Right? Yeah. Let me see. Maybe go more tie dye. Okay. So interior I is what the minimum structure we need for dashboard. Like, we are we as we can see, we don't have any panels. We don't have anything. We are just creating the the dashboard. Let me just see if we need to also assign the project because dashboard project name, and then we're gonna choose default. Okay? So this is where I introduce the, like, go stall, like, Let me just upgrade my Persis CLI for

49:25 the latest version. Like, this is the CLI, which allows us interact with the Persis instance. You can do a lot of things in there. You can like log in, you can you can list your project, you can creating a project data source and other things through the CLI. Those are the available comments. So let me do one thing. Docker Compose up. That process running. And then process CLI login h t p localhost 88. So I'm just logging with the CLI into the the Persis instance I have running local host. Yep. And then I can run Persis doc.

50:25 Doc is a stand stands for dashboard as code, build, and then provide the source where I have the dashboard defined. And then it will output this into the folder. Okay? So this is the the configuration. Let me do one thing. Okay. No. I would not do that. Like, one thing that we can do right now, we have the dashboard, and then we have process CLI linked. Linked command will basically apply a set of validation rules over the manifests to make sure this is a this is a compliance versus a schema. So we're going to look

51:10 of this is a data source, then it will do a set of validations. We'll look to the kind. This is a dashboard that will do a a lot set of validations. These sources look good because it was generated by the SDK. But, anyway, it's it's nice because eventually you can have some you can, by accident, changing the dashboard or changing something like or your data search. Another interesting capability of this process CLI, it's like you can extend the existing rules. So imagine that on your company, you allow that all dashboards you you you you agree that all dashboards

51:52 name will be snake case. K? You don't have, like, camel case. Every dashboard is snake case. So you can provide the rules file for Persia CLI linked command. And the rules file, it's based on JSON path and common expression language to run the assertions over the JSON dashboard definition, YAML or spec, you know. Oh, nice. There is also modes for this linked command. Could be the offline or online mode. Offline mode, we will apply the rules using the the available rules on the version you are running. And the online mode, we try to apply the rules based on the

52:36 person's server that you have signing it, you know. So for example, we are localhost right now, imagine that we're trying to use a plugin that's not available in this Persia's instance or version different than you can link against a specific Persia's version using the online mode. All right. Cool. So time like it's persist, you'll I apply. We can just apply the dashboard, and then we can come back to persist and go to the default, and we will see the dashboard here. Okay? So blank dashboard. We didn't create anything. Creating a panel, it's pretty similar with what we did so far. We can

53:26 just, for example, come here and say dashboard add panel group panel group. It's going to be panels, like, add panel group. In the panel group, we have a name, like, for example, CPU. And then we have some panel groups config, like, for panel group. We have panels per line. For something measure, I want one panel per line. And we can do the same. Like, me just copy and paste some code here to be a little bit quicker. We can adding a panel CPU usage, providing the the PromQL expression, some panels configuration as we saw on the UI. What's missing? Maybe yeah. This

54:25 one. And we need to add time series panel. Like, everything is a different Go module. So we need to adding as we need low. I need time series panel. Then I can add the dependence for time series panel. Now I need, like, don't know, bar charts, and then you include bar chart. Yeah. That was my my hard question is that when you push all of this panel visualizations to plug in, how do you give an as code approach, but you're relying on these plug ins being written and go and having their own go dependency I

55:01 can pull in. Right? Like, that's that's how it's but I'm assuming that quite might be quite tricky for the queue aspect of this then and that the queue support is as good as the plug in support as long as people generate the the types. So Yeah. Yeah. Yeah. Let me But if it has all gold, then, I mean, I can also just use queue get go. So, I mean, I guess it's not the end of the world. Let me add this one, and then we also have query query query one, this one. Thanks versus maintainers to keep the documentation updated.

55:53 Let me just change for time series panel. Sims Sims doable. Let me see again. Process CLI. That build. Process CLI linked and oops. Without the no. Apply. This will just apply to persons. Okay? And we can see hey. Yeah. And then this is the flow. You keep doing, you know, you keep doing like, you keep adding the the panels. And what is really nice here, like, example, it's like we like, let's imagine that you have the we have this working. Okay. Let me try to do something. Let me see if if if it will work.

56:39 Like you you have like the idea you're using your dashboard as codes, you're testing locally, everything is fine, but you won't eventually push it to to a real process instance, you know. You have CLI, you can basically on GitHub actions, you can go get go install the CLI and execute all the commands we are executing from our computer right now from from this from my computer right now to a process instance. Okay. But like we are like, we are using GitHub actions heavily on the process project. We like everybody in the community is mostly using GitHub actions.

57:18 We have other people using GitLab hundreds as well. But like for now, we did something which is providing a Persis dashboard as code GitHub action for people. So you can we can just now come here and say, okay. It's GitHub. It's the folder, like, GitHub slash workflows and then doc dot yaml. And we can just create it. Like, this is the workflow. Let me just make sure I'm using the latest version from the workflow. Let me look to where is this? Go link dashboard LinkedIn. Yep. This one. The yeah. This is exactly what I'm using.

58:23 Copy. Here, it's version. It's gonna be latest. And I think we can just remove it. And what we're gonna do is we're going to use demo dot persist. So we have a live demo if you want to watch. Super secure admin admin. Okay. Since this is not the admin admin anymore. Surprise. Okay. I think that means you've been fired. Yeah. Yeah. Yeah. So as we you mean, we can see it here. Okay. So let me try to do one thing as let me do I think we let's create a new project here, Rawkode live. And then

59:30 I will need to add to this repository that I created right now. Some credentials. What I think I won't be able to do it more because it changed the it's not a demeanor to me anymore. Let me see if I can. No. Okay. I think I would not be able to show what I want to show you. That's okay. Like, yeah, like, I I can even show show, like, the the git maybe only the yeah. Not even this. Like, yeah. Like, it's a very, shame. I would love to show you, like, GitHub in in action, but, like,

1:00:21 probably, I would need to share recording with you. We I do have a recording of this working. Well, I think we can imagine like, we've already seen the fact that you've got the purchase CLI. You can do the build and the and the apply. Right? The GitHub actions is really just automated in that one step. So, I mean, we're still you know, it's really I think everyone's gonna be clear about what that delivers and why that's important. So I think it's alright. With the with the GitHub action, there is one very, like, caveat that's really nice

1:00:52 is the concept of ephemeral dashboards that we have in Versus. Like when you are pushing your like if you're using Versus GitHub Action, whenever you open up PR, it will run the built in the linked comment. And then it will push the dashboard for the Versus instance, but it's not an usual dashboard. It's a dashboard with the kind he serves a femoral dashboard. So it's a dashboard with a TTL with a time to leave attached to it, which is really nice. And when you are doing that, the name of the dashboard is your the name of you defined it plus the PR

1:01:30 number. So you can create in dashboards, share with your teammates. They can review the code and even see how the dashboard is looking on on on like, when it's being used in in the UI, given their comments, you can iterate work again. It will push another version from the same dashboard. And after, I don't know, maybe one day, maybe eight hours, you can configure the time to leave off of ephemeral dashboard versus server will clean up the ephemeral dashboard. So it's really nice for this development life cycle. You know? Yeah. That's really cool, actually, being able to

1:02:07 do that, build and apply within the pull request. And, you know, even at that point, the people reviewing it can compare side by side with the PR dashboard and maybe the primary dashboard to see if the changes are actually doing what they suggest. So, yeah, they got completely. Very cool. And the the fact that you have the PR number on the on the dashboard sorry. On the femoral dashboard name, if you have two people working on the same dashboard, you can see side by side by the PR number and see the difference and so on.

1:02:38 And when you merge it to master the GitHub action, it's smart enough to identify, okay, I'm now merging to main or whatever you mean as main on your company, and then it will publish as a normal femoral dashboard to the person's instance, you know. Excellent. Yeah. I I think let let me see one thing. I think on these can you become the best? No. Let me see here. Yeah. No. We don't have we don't have it. Yeah. But, yeah, that's that's the idea. You you got it. Alright. So so Is there anything else you want to

1:03:16 show, or shall I put this back to to big face mode? No. I think it's mostly done. Like, around that you can write in the code as you show you. Again, as I mentioned, this is a Go program in the end. You can use whatever you want. You can use in flags to make your that your program more your dashboards more customizable. Like, for example, I hard coded the, like, the name of the data source, the name of the project. But you can either using some features like data source discovery or imagine that you want

1:03:50 to change the name of the dashboard based on some external inputs. Like you have a foregolden sign on dashboard that you are deploying for every team in the company. Whenever a new team is created, you can just build this dashboard with par pass passing a flag as team name and and think later, you know, like, it's it's Go program in the end. Alright. Awesome. Let's jump back over. And thank you so much for that demo. I mean, already, I really I don't know if it's general, but after you transition, your audio was a little bit, like, clunky

1:04:41 to me. Oh, no. Now it's better. How's that? Yeah. No. That's good now. But, like, right after the transition, I didn't release on you. I have no idea where that was, but I'll sit closer to the mic. So, I mean, I think it's it's such a great piece of software. Right? We've got this dashboard into where everything is as code. We could do queue. We could do we describe everything. We bake it to pull request process. The firewall dashboards was the ice on the cake. I did not know that was a thing, and I love it already. So that's

1:05:12 fantastic. Everything is a plug in. So, you know, if something doesn't work the way you want, you can just go and contribute that, whether it's open source or proprietary within your own organization, do whatever works for you. Something we didn't cover, but, you know, the dashboard that we spun up with Docker Compose didn't have any authentication. But as we've seen from the demo instance, Office authentication is right there, and I even seen an RBAC tab. Right? So if you need to expose and manage things in a more granular level, that all appears to be there too.

1:05:42 Yep. I would just go out and guess, but I'm assuming I could hook that up to any OIDC provider, whether that be my Google account, Zettadell, anything I want is just gonna work. So, like Exactly. What we have here is a complete ready to go dashboard system that's extensible, and I don't really think anyone could need any more than that. However, I will ask the question of we have seen where Percy's is today. What is on the road map of the project? Where do you plan on taking this? What he's working on? What yeah. What what

1:06:13 should people expect over the next twelve months? That's cool. That's cool. So we're expecting much more plugins. Now we have finished the plugin system. This is open for contributions. We already have people working on SQL plugin for connecting with SQL databases. We already have people working on profiles, visualization and profiles database data sources. We are heavily working to improving existing plugins that is still missing some capabilities like table plugin Grafana. This is very powerful. You can do a lot of things with Grafana tables for time series. We are constantly improving the data source and, like, adoption.

1:06:56 This is what we're expecting the most. Are we already have, like, in the last cubicle, we had a lot of tractions, people asking and so on. And one of the requests that we did, it's like, ask your vendor to supporting versus data model. We already have vendors doing that, like ask for a vendor for doing that. This is like, yet another step on your non vendor locking and observability. You know, we already have open telemetry. We are now trying to achieve the same with dashboards. Of course, this is not easy. There is always be translations

1:07:34 between solutions, but it's better than we definitely have until nowadays. Nice. Awesome. Alright. I'm assuming the project is also open to all sorts of contributions. So, you know, just go to the GitHub. Right? Look up Parseys. There's lots of issues there. You can start kicking the tires on even you know, it doesn't have to be code. If you're not a coder, you can do documentation. You can issues. There are lots of ways to get involved. And I'm assuming that there's a Percy's channel on the CNCF Slack that people can also join for questions and contributing.

1:08:11 Definitely. Definitely. Percy's dash dash dev on CNCF Slack channel. Please join us. Welcome community. Everybody is welcome to contribute any kind of contributions, issues, PR reviews, triage, documentation, you know, like feedback, especially if you're using and having troubles on using something that's also very valuable for us because we can only improve based on feedback, you know, because, you know, after you're using some software for a very long time, you start being biased by the way you are using that. So you can you as far what I always want. The blinkers come on in Yeah. Definitely. Hard you need to say perspective. So

1:08:54 Yeah. You're always to use it for the for the problem. You know? Yeah. Alright. Eddie, last words for the audience before we wrap this session up. Yeah. Thank you very much for having me, David. Very, really nice session. Like to talk about first, as I like I love to talk about observability and especially open source solutions. So I hope that you people got a little bit of excitement seeing Persis and like come to join us. It's been an amazing journey so far. Alright. Awesome. Well, thank you so much for your time for doing that demo, answering all

1:09:30 the questions, and hanging out with me. I'm sure we can do a follow-up in six months, twelve months, whenever to take a look at that new plug in ecosystem and hopefully see a blossoming CNCF project. That's all for today. Well, thank you all for watching as well. We'll see you all next time. And until then, have a great week. Thanks all. Thank you.