Hello everyone, and welcome to today's webinar. My name is Katelyn Croft, and I'm joined today by Zoe Steinkamp, who's gonna be talking about getting better observability with open telemetry and inflex CB. Please post any questions you may have in the chat or Zoom Q&A, and we'll answer them at the end, the session's being recorded. And without further ado, I'm gonna hand things off to Ms. Zoe. All right, awesome. So today we're gonna be going over how to gain better observability with open telemetry and inflex CB. My name is Zoe Steinkamp. I'm a developer advocate here at Inflex Data. Let's see, there we go. If you wanna reach out to me on LinkedIn or add me, feel free, but basically as a developer advocate, part of my job is to advocate, not only for our company, but also for some of the other open source tech that we work in, like the open telemetry project, as well as just in general to get feedback and such. So first things first, our agenda. So we're gonna first go over an introduction to open telemetry, which is going to include logs, traces and metrics, an overview of the inflex DB cloud powered by IOC. So that's the new version that we just released. We're gonna go over a few of the key features that make it useful for open telemetry data. And finally, we have a project that you can actually pull from GitHub and follow along or you can just kinda watch my slides. And then we're also gonna do a live demo at the end of it. But basically this will allow you to hook up Jaeger, Grafana, Hot Rod, which I'll go into later, but basically it creates traces, like it creates like fake traces. If you're like us, you don't have like a server to pull from and then telegraph. And finally, more learning resources at the end. So first things first, an introduction to open telemetry. So logs, traces and metrics. So logs or records or events or messages generated by applications or systems during their execution. And one thing to note here is for the longest time inflex DB has been what we call a TSM, been more of a time series metrics database. But now with our new IOC's engine, we will be able to store logs and traces. Now the project that we're gonna be going over later here, it mainly focuses a lot more on the tracing side, but we will be also getting logs and metrics as well. So basically this is the, I guess you could say the circles of where these all come from, but metrics are more like, sorry guys, agreeable events and logging is more like every type of events and tracing is request scoped. That means that like when somebody clicks a button on your website, you're more likely to get a trace about it, whether or not they got a 400 or a 200. You know, whether things went well or things went bad. Logging can still be that button press, but it's more likely to be just in general, more what's the word, like a trace can be uneven. It could take hours for another person to press that button. You know, it might not be consistent, but logs and metrics are normally a lot more consistent in that they are tracking constantly throughout the day. So these are the three big things that the open telemetry is currently working on tracking. And these are very, very important metrics, especially in things like deployments and DevOps. This is kind of a nice architecture diagram of how this ends up looking. So I'll go over the key points of the open telemetry project to the next slide, but basically what they're trying to do is create everything in one space for you. So it used to be that it was kind of play at yourself game of, hey, pick whatever you want to do your traces, your metrics and your logging and maybe some other stuff too while you're at it. And you can just use all of these different types of collectors and where you stored stuff. And it was very much everybody builds it how they want to build it, maybe by the tools they already knew or whatever tool was popular. But basically people were kind of spread out into the tech that they used for this. The idea with open telemetry is that you use one type of collector, which will grab all of the three different types of data and it's more streamlined. So you also know what data to expect because in open telemetry they normally tend to define what parts of logs and traces of metrics are going to be storing. Now that being said, you can store obviously larger amounts of data points if you have them. More things normally that go to things like location-based data and such, but overall what they're trying to do is just streamline this process because it can be very frustrating as the DevOps engineer to, I don't know maybe change a job or when you change different possibly cloud providers or something, it can be frustrating to now have to use brand new tooling for all the same problems. That's not super fun. So the idea with the open telemetry project is it's all just wrapped up into this service. So it's a single vendor neutral collector binary and a vendor agnostic instrumentation library. So basically what these wonderful words mean is that there are many different types of collector binaries and they're vendor agnostic. It doesn't really care if you store your data in Influx CB or if you're storing it in something like a SQL database, depending on what you're planning to do, it is relatively agnostic. The only big thing I would say is that the vendor neutral collector is technically accurate in that any vendor can create a collector like we have, but you do have to like follow their docs and stuff. So not every single vendor is going to be, is going to have an open telemetry collector just because they have to create it themselves. It's going to have end-to-end implementation to generate and make, collect, process and export. So that's like what I was talking about before. The whole idea here with open telemetry is that it starts from the beginning of that collection process all the way to storage and it's all streamlined so you don't have to do it yourself to an extent. But it's still full control of your data with the ability to send to multiple destinations in parallel, like I was saying before, it doesn't care if you're sending it to Influx or to somewhere else or as it is actually quite common to multiple places. Open standards, semantic conventions, that's basically just saying that the vendors can easily build up the data collection agent. It's not necessarily difficult. It's just something that they have to do. And obviously a path forward no matter where you are in your observability journey. So one thing to note is why I'm talking a lot about this is obviously this project is using an open telemetry collector that we built ourselves, but also because we've been working side by side with the open telemetry project for about, wanna say two-ish years now, it's been more intensely working together in the past six months I would say, but we've been following the project and some of our engineers have been making commits and such for over the past year. So now we're gonna go into an overview of Influx DB Cloud. And this isn't gonna be like a massive overview or anything like that. Like I said, we're gonna be focusing on those key features that make it relevant for this type of data. So first things first, the new engine is built on top of Rust, Apache Arrow, Apache Parquet, Arrow Flight and Data Fusion. So what these allow us to do is Apache Parquet is a Parquet file format and Apache Arrow allows us to be built with a SQL in mind. So the idea here is that we're storing files in that Parquet file and it allows us to be able to integrate with more connectors and it also allows us to store in a more efficient file format. And with Arrow Flight and Data Fusion, it allows us to have SQL connectors. So going forward, you'll be able to call Influx DB instead of with Flux, you'll be able to call it with, sorry, you'll be able to query it, not call. You'll be able to query it with SQL. The calling feature is part of Arrow Flight though. Those are, I'll go into it when we get into the project but basically these are the key technologies that the new engine is built on top of. And you can read a ton of blogs that go into, Paul especially loves to talk about why he built with all of these and all the features that they offer. So this is also our new architecture and deployment. So some of you guys probably haven't seen the old version of this, so that's okay. But basically the idea is that now your data sources, it's all time stamp data. So it doesn't matter, like I said, if it's a metric or if an event or a log or a trace, we can accept it all as long as it's still that time stamp data. The data collection is pretty much the same I would say. It's mainly just telegraph from the client libraries. Those are the big two. The client libraries are also being currently revamped because not all of them currently can do SQL curing but going forward in the next couple of months, most of our top five will be able to and I think in the next year, almost all of them will be able to. Finally, data storage and transformation. So this has kind of changed a bit. We've focused a lot more on the collection and the storage and then the SQL queries, which can't do quite as much yet as what capacitor used to offer. But we are planning to bring back certain features that capacitor offered. And we're in general building out a lot more documentation and working on the data fusion library to allow our SQL queries to be able to do things like down sampling and such. And finally, data visualization and analysis. So this one, especially we've been focusing a lot more on the integrations. So when I do visualizations in this project, I'll be showing you on the Yeager UI as well as Grafana. So we focused a little bit less on our own visualization library because a lot of people just tend to use these outside tools. So unlimited cardinality is the first, I suppose you could say big piece here. So what cardinality means is that back in the day, you would have a trace or something. And a trace can be pretty large. It has approximately 30 to like 100 plus like tags, you could call it on it, like data points on that value. So it would say things like where the trace came from. It might say even like the server it was going to, it would just have a lot of information basically. And the problem with our old DB is that we would kind of max out at about 30 or so tags before things started to get a little hairy, I suppose you could say. But now we have unlimited cardinality, which allows, I'm calling it unlimited, but it's really up to about 200 tags, which is still a huge amount more and will encompass most data. Like it will deal with traces and logs perfectly fine, no problem whatsoever. So we've solved this cardinality problem where now you can have a much larger amount of fields and tags on your data source. So that means that you can have more data basically on it, you can have more things like locations or metadata, et cetera. So that was a big piece, obviously. The native SQL support. So I will say that SQL is not necessarily a requirement for dealing with open telemetry data. I'm just gonna put that forward. But SQL is really nice and that a lot of people like to use SQL, a lot of people, I don't really like say coding in it, but they do, for lack of a better term, they query with it, they code in it, they work with it a lot. And so this allows a lot more people to be able to use this platform and be able to query it back out. And actually a lot of integrations that we're working on, things like Power BI and Tableau, they expect the data to come back via a SQL. Like they expect to be able to query in SQL to get data out of DBs in general. So that's another key thing that will help in the future is that now that you can query with SQL, you will be able to integrate with more features, more integrations, more vendors. High performance data ingestion. So this has always been kind of the case, I would say actually, which is that we've always been pretty good at handling high writes and query loads. But it's gotten even better and we're going to have in the next couple of months a lot of data coming out about this where we're showing off basically the capabilities of the new engine and where it, we're gonna basically do a comparison of it versus the old one. So we can kind of show where it shines and how it's making things a lot faster. And in general, this is a good thing because again, open telemetry data tends to be a pretty high ingest rate. Like I said, traces are not always necessarily consistent metric, but logs and metrics are definitely very much like they're noisy. Like you're gonna get them every single second kind of deal. And sometimes traces can be the same, especially on a very busy website. Seamless integration with observability tools. So this is also what I was kind of already talking about, which is the SQL allows us to integrate more, but we're also working on more integration. So this one is the one we're already talking about, open telemetry. And I would say that's the biggest integration that we're working with outside of pandas and a few other data science tools that we're also working on. But we also have integrations with Grafana as well as we work with tools like Yeager, but we don't necessarily have what I would consider a full integration. We don't work with them as closely, but we do work with like, it's easy to work with the technology. So now I'm gonna go ahead and get into the project. So first things first, for those of you guys who want to grab it and I would just grab it now. I'm trying to remember if it's linked at the end of this and I cannot recall. So I would grab this link now just to make life easy. But basically what this is is a GitHub project where we are storing open telemetry data within Influx TV. We're running this on a Docker server. So, and as I said before, hot rod basically allows you to create traces like fake for lack of a better term, it creates fake traces for us to use, a kind of show how it works. And then after the open telemetry data is up into Influx CB, we go ahead and show it off in the Yeager UI. We'll also show it off in the Grafana UI as well. Parts of this can technically be replaced with Telegraph. And one thing to note is that we are currently in the process of getting our open telemetry collector on the official open telemetry collector list. We've been working on this for a while. It hasn't been necessarily the most straightforward thing, but our engineers are working out, I suppose you could say the minor kinks of this and then they're gonna finally put it up on the open telemetry project. So as I mentioned before, hot rod basically creates as it calls it rides on demand, it's creating traces and other such data. So basically what you do, and we'll see this when I actually pull the project up, but you basically click on these buttons at the top and it's creating traces for you. And the idea here is that these are different, you know, like websites, different services. So you can basically compare traces from multiple different sources. So Yeager is where you can actually start to see these traces. So Yeager is a completely open source library that allows you to visualize trace data for like a better term. And it also gives you some pretty awesome features like these kind of trees and such that can tell where your traces are coming from, where you're getting the most common amount, et cetera. I'm not gonna go in depth on the Yeager UI just because honestly it's just not my forte, but for those of you guys who wanna check it out, obviously this project is using it and we will go over it briefly as well during the demo. But basically Yeager is a super awesome open source library for trace visualization. Grafana. So we also built our own Grafana dashboard for this project. So with this, you'll be able to see, again, a lot of traces data. We also have a table or two, I think, dedicated to logs and metrics as well. But again, like I said before, this project does focus a little bit more heavy on the traces, but it's not a super big deal to just start building out some Grafana dashboards about the logs and metrics as well. I would say if anything, that's probably the very much straightforward thing to do. And we have a brand new plugin with Grafana actually, which will allow you to query in SQL. So that's a super fun and exciting thing. And in the docs for this project, we talk about how you actually hook up with Grafana using our new, we call it the FlightSQL integration. And you'll also be able to see your data within InfluxDB Cloud. So this is where you're actually storing that data. So you go ahead and you, for those of you guys who haven't actually checked out the new Cloud product, you haven't seen this before, basically what we're doing here is we're getting into our hotel bucket, which by the way is in the project with the dashboard, sorry, the database is called, it's called a bucket and we called it hotel. From there, we're asking for the measurement of logs. You can see all the different measurement options that we have here. Again, this is all based on how open telemetry tends to like your data to be stored. And also I think we've done a little bit of editing on our side as well, but basically you can see those results here in this table. So you can see all the logs that are available. And this is a very small screenshot of this, but basically these kinda, what's the word? You can like scroll right on this and you'll be able to see more data. Again, when we actually get into the demo, it'll kind of all wrap itself together. So this is a very wordy slide that basically goes over everything inside of the readme for the project, but I'm just gonna kind of walk us through this. So obviously you'll need an Influx DB cloud account because that's where you, that's where Influx DB three is currently living. You create two buckets, hotel and hotel archival. Now, one thing to note here is the hotel archival is optional. You don't have to do that. Basically the idea with that is to show a cold storage options that one was supposed to have like a longer retention policy. Personally, I just do the hotel bucket. You create an environment file with authentication credentials. You install FlightSQL as per the readme. So FlightSQL will be what allows you to query your data. You build and run the Docker images as per the readme. You import your dashboard with the JSON that we have provided inside the demo, Grafana dashboards. So I've already done this in my project, but I'll show you guys in the readme. And basically from there, you can create your fake traces by clicking on a customer on the hot rod application. So Grafana setup details. So this is gonna be best just read in the readme, but basically when you set up Grafana because you're setting up a local host version of it, or sorry, an open source local host version of Grafana basically, just make sure when you set your credentials you make them nice and easy because these are not public. And also when you go ahead you'll want to import this dashboard. And again, this is best explained within the readme, but basically what you're gonna be doing is you're going to pick the flight sequel integration that is now offered as well as a Yeager as well. You're gonna name it open telemetry and then you're gonna need to upload that JSON file. So let's go into the demo. So either way you kind of take a better look at this. And we're gonna do some live coding, all right. So give it a second here. It's gonna go ahead and get Docker up and running. Great. You can see obviously we've got some Yeager, some Grafana. Great. I'm gonna move this zoom thing out of my way. All right. So this is the project. Well, specifically this is a version of the project that my coworker built up. We have the main one, which is forked from InfluxDB observability. But basically what this does is this is the project that hopefully you're following. If not now is a great time to grab that link. Basically here it talks about the credentials inside the environment file that you're gonna wanna add. It's pretty straightforward. It's basically just your, I'll show this where you actually get this from. But basically it's within your URL inside of cloud.  And then finally, build the needed Docker images which I've already done. That's why I only had to run the Docker compose file. And then finally you'll be able to see traces are generated by hot rod, browse to hot rod at the local host 8080, query the traces here. And Grafana is available on local host 3000. So let's go ahead and check this out. So I'll probably have to refresh some of these because I'm almost certain they're yeah a little bit on the old side. All right, so we're gonna go ahead and get Rachel's floral designs. We're gonna refresh all of these pages. So let's go ahead and find some traces here. So it's found us two traces. Awesome. We'll go back to hot rod and maybe get one more. And we've got three traces. I guess maybe it actually did keep my old traces. It's interesting. Let's see, see if on the front end what we can find. Yeah, like I said, this is not my per se forte. Let's see here. That's weird. I thought it would actually do it for me. Oh, there we go. But as you can see, we're getting some traces on the front end. A lot of them are going currently through Redis and a few through MySQL. So this is a nice little system architecture here. You can also compare traces as well if you can actually find them in here. Let's see. I don't wanna necessarily wanna deal with grabbing trace IDs and such. But basically this is how the Yeager UI will look once it's all up and running. It's pretty straightforward. For those of you guys who are a lot more comfortable using this, I'm sure you guys know exactly how this would work and how you would want to find your data and such and sort through it. But let's go ahead and load into Grafana. Okay, let's see here. Yeah, there's my open telemetry one. Oh dear. Oh, oh. Looks like my data might be loading in a little bit. Give it a couple of seconds. Looks like it might be having issues with the data source. Well, this is life coding for you guys. It was working 30 minutes ago. Of course, now it's not as happy. But as you can see, we've got some of our traces down here. Yeah, I'm not quite sure why this is not finding its data. I'm gonna refresh this page one more time. You never know. Okay, maybe not. Sorry guys, I don't necessarily wanna do a bunch of debugging while we're looking at this. But normally with this dashboard, you would be able to see all these wonderful graphs as I showed in the screenshot. I am trying to figure out why they are not working. Let's see if we change it to anger if it's happier. No, that did not help at all. But yeah, so we can see our disturbance latency histogram and we can see the traces that we've already created. And we'll go ahead and create a few more traces while we're at it. Cause yeah, I'm hoping that maybe eventually, yeah, go ahead and reload it. Yeah, we're getting more traces, but unfortunately these are not loading in. I don't know if maybe I need to reload in my dashboard since I've restarted this now, but obviously my dashboard did reload in just fine. I'll take a look at this. It's probably me. It's probably less to do with the project and probably more to do with me doing something wrong possibly. And then we'll go ahead and go to cloud. We're gonna go ahead and log in here. So in here, we should be able to view from my hotel bucket some of the data that I've got. Yeah, there we go. Go ahead and look at logs. And we can do things like by fields, like their attributes and their names. But for right now, we'll just go ahead and run with this. So as you can see, I have my logs here. I have quite a few rows of them actually, and I'm only getting it for the past hours. These have all been created in roughly the past like five minutes or so. And as I was trying to say before, you can scroll this over a bit. So you can see the trace ID that goes with the log. And this really can't be visualized. You have the option of visualization here, but for example, this doesn't really work for visualization. We can see maybe if calls total, some might work. Yeah, no. Most of these are, I would say that most open telemetry data is a little bit more, what's the word here, specific. And the visualization libraries, you're gonna need to use for it. Things like Yeager or Grafana are much better options than just the graphing that we offer. Our graphing is more to make sure that you actually have data inside your DB, which I would say the table does a pretty good job of showing that, yes, clearly we have some data here. Yeah, it sucks that unfortunately our open telemetry is just not quite working as it was 20 minutes ago. Yeah, I think it wants to be in Grafana. I don't know why it's so upset. That's okay. Yay, by me clicking on it, it worked. I didn't do anything. See, guys, this is magical. So, yeah, so this is all of our services running. So you can see the scrolls quite a bit down because even in this past like two minutes, we've got quite a bit of services. See, if you just click around enough, you can fix everything. That's how this works, right? Well, maybe not everything. Well, now it's the same color field not found. I don't even know what that means. Maybe a color field not found. I don't know what this is. I do not think this is what I wanted, but that's okay. We'll allow it. Let's see if we can get this one fixed. It's funny in that I don't even necessarily apply things and it still manages to fix itself. No, no data found in the response. I was hoping the traces of all things would work. Oh, well, I at least fixed two things by just screwing around with them. But yeah, I like I said, I'm not gonna, this is just part of life coding. It's occasionally things don't quite work as expected. But again, over here, you will find that you can find the dashboard to import under this file up here. So it's pretty straightforward. It's just this demo folder and then Grafana. And from there, you'll be able to find all of the charts to grab. You can already tell that Docker is having a adverse effects on my computer. If you would like to access the trace notary that makes sure it's enabled with the Yeager data source, which as far as I know, I've done. The images are automatically built and pushed. Yes, that's right. So these images, this hotel collector, it's automatically being built and pushed to Docker. You can check these two out if you want, but basically they're just talking about where the file is being held. And then this is talking more about the hotel infox collector, which like I said, we're currently working on making this a more, what's the word, widely applicable I guess is the right word for this. Like I said, eventually this collector and receiver are both going to be available on the open telemetry project. We're just wrapping them up and putting a bow on them so they're all ready to go. The Yeager query plugin for infox DB, which obviously enables querying traces stored via the Yeager UI. And if you wanna go ahead and do some tests, you can also run those as well. So like I said before, this is a fork off this original project here, done by one of our engineers, Jacob Marble, who has been working a lot on the hotel projects. So you can also check this out as well. It goes, it builds the files a little bit differently, the way he's doing his authentication and such. Oh, speaking of which actually, real quick. So here is where you get your URL.  So you're like US East is where I'm currently working out of. If you wanna get your bucket ID, that is available right here. So that's your bucket ID. And then, really quick, I'm gonna see what the final piece of the thing is just the token, infox org, okay, token. So your organization is this one right here. You can also find it within, let me see here. Let's see settings, orgs. So yeah, you can also find it in here. Sorry, I'm like looking for it, but basically you can find it in there or just grab it out of the URL. And then when it comes to the API tokens, you're gonna wanna generate them over here. Quick note, if you create an all access token, it gives somebody access to everything within the UI, or sorry, all of your buckets. Like it just gives them access to absolutely everything. So we do warn against doing this. Otherwise you can do a custom API token. So with that, you're gonna want to, for example, the hotel one, do make sure that when you do this, you give your bucket both read and write permissions because otherwise we can't write the data in and you can't get it back out to send it onward to Grafana or Yeager or anything like that. So just make sure that when you create your token, you give it both access. And yeah, as far as creating buckets, it's pretty straightforward.  And then you put in your preferences for when it would be deleted. And then from there, you just create it. So it's very straightforward. So really quick, I'm going to turn off Docker just cause it seems to mess sometimes with my slides.  There we go. I'm gonna put that down at the bottom. So learning resources. So this is a try it yourself. So the Influx community is where that project lives. That's where the observability, both observability projects live. The one that Jacob created and the one that my coworker Jay created, which allows that Grafana dashboarding. And then influxdata.com is obviously our main website. It's where you can sign up for the cloud account as well as just in general, find more information about us, the things we offer, what we're used for, et cetera. Further resources here. So that would be things like getting started influxdata.com slash cloud, always a good start. The community forms in Slack are both places where you can come to us for questions and answers. Our GitHub is, this is again a link to the Influx community. In general on GitHub, you can also find, obviously all of our open source, all of other libraries, et cetera. Our book and documentation, talk more about how to get stuff up and running, why we do what we do. Blogs are a great resource to see new features that are coming up, as well as user use cases and such. Blogs like to talk about like what our customers are doing and such. And finally, InfluxDB University is a great learn at your own pace resource. So that's completely free. So you can pick up a class there on something that you wanna learn about and take your time doing it and it's completely free. And that is the end of my presentation. So really quick, I'm just gonna put us on that QR code. And then we can go ahead and take some questions. All right, there we go. Perfect. And also, Zoe, I threw in that GitHub link into the Zoom chat. So if you guys don't have your phone ready to scan it or you want it on your computer, the link is there. And also I threw in a link to an upcoming webinar that I mentioned earlier. It's with Gary, a product manager. And so you can come and learn all things InfluxDB 3.0. I'm sure you guys have lots of questions around that. So, all right, now let's jump into the questions. Could open telemetry be a replacement or an enhancement to my current telegraph setup? So they're not per se replacements or enhancements. So telegraph itself is an open source ingestion agent, which means it's pretty wide as to the use cases it can be used for versus the open telemetry collector that we're currently working on is just for the open telemetry project. So it focuses entirely on those traces, logs and metrics. Now you can get that data with telegraph, kind of like how it says here, parts of the collector could be replaced with telegraph. They're not technically a part of the, telegraph is not a part of the official hotel collector list. And I don't think it technically ever would be, maybe one day it will. But so if you're using telegraph for something, the open telemetry collector might just be the, might be the replacement if you're dealing with open telemetry data, but it would probably never necessarily be like an enhancement per se, if that makes sense. They're just different use cases for the most part. Regarding cardinality, what was the previous limit and what is the new limit for this same influx DB 3.0? So in previous, what the limit was is you could have, you could have a, basically it was based off the way that we queried our data back out. So normally you would have a timestamp, a value, a field and a tag. So fields would be, I think fields are the one that you would run into problems specifically if you had a bunch of fields because we would query off those fields. So if you had like 30 plus fields attached to this value and this timestamp, the problem would be that the queries would be really slow because we were querying them on the backside basically. Like we were pre querying them to take into effect that you had all these. I think tags, you could have a lot more because we weren't querying them in general, but that wasn't helpful then if you actually needed to query off the data. Like it's not helpful to just throw all your data basically in a tag and be like, okay, well, it's all tagged but now I can't search via those tags. I needed this data in a field so I could actually search it back. So I could be like, I only want the location of my server in the Netherlands. I don't want all the server information from Sweden kind of deal. So now with the new limits, it's more like 200 rows. So now you can have like 200 fields basically. So, and I think nowadays when we, I still am learning a little bit more about how we redo our schemas nowadays, but basically it's less separated between fields and tags and more just in general timestamp value, everything else. And that everything else category can have over 200 values before things start to get a little hazy. I suppose you could say, and even then I think you could push it, you could go above 200. I think it might just have some effect on the query ability, that speed. Will IOX and therefore support for open telemetry ever be added to InfluencedDB OSS? We would like to use cloud but have certain dev and production development use cases which makes cloud unattainable in about 10% of our deployments. So with that, we are currently as a company as a whole I would say we're figuring out what we're going to be doing as far as OSS with IOX. So with that I can't really tell you unfortunately I do believe that it will eventually reach open source honestly but when it comes to support for open telemetry the open telemetry collector itself will be open sourced because that's what open telemetry is in general it's all an open source project. Now if the collector and from what I understand because the collector is just something that pushes data into InfluencedDB OSS it shouldn't have an issue where you could still use it for the OSS. Now don't quote me on that I'd have to actually go and test it and determine that that's the case but in my mind it makes sense that that shouldn't be an issue because the only issue that you currently might run into really between version three and the open source two is the fact that we have that sequel and that's more of a problem when you're getting the data back out less of a problem of the data in and this hotel collector is going to be for the most part all about streaming the data in. Obviously we do also have the hotel, what's the word? It's like receiver and the one that goes the opposite direction and that'll have to be kind of figured out basically but unfortunately I don't have a great answer for this right now. We should have an answer though for this question and in general questions around open source in the next month or two I would say. Yeah I would definitely say keep an eye on our blogs and everything as we are continuing to roll out. We have a lot planned for the rest of this year as far as the rollout of all these new features so I know this sounds vague but stay tuned. And what about Influx CB Enterprise on-prem version? Will it have open telemetry support? I have absolutely no idea. I want to say hopefully yes it will but I know less about the on-prem like plan for the engineering for on-premise unfortunately. I'm not quite sure what will be added from Influx IOX. I know there's been definite talks about yes that IOX will basically be integrated on top of Enterprise to an extent and so it will it will reap most of the benefits I guess you could say. And so I think that's the hope is that on-prem Enterprise will still receive a lot of these great benefits that IOX has to offer including things obviously like open telemetry. What is the protocol used by open telemetry? Is it GRPC? Yes it is. I actually I have to admit I have a second laptop here and I looked this up because I saw this question so it says here the specification defines OTL is implemented over GRPC and HTTP 1.1 transports. You can go and check out their docs which are quite large about the protocol details. That would be my suggestion but yes it does appear to be built over GRPC. What is the difference between AWS Timestream and Influx DB? So the big difference between us and I do have to admit I don't look at AWS Timestream super often is that we do have a lot more, what's the word here? Availability options, features, there we go. That's the right word features. We tend to have a little bit more features than Timestream and because we are more focused on being more friendly I suppose you could say to the open source community and environment, we tend to hook up to things a little bit better like we have a dedicated Grafana integration, we have dedicated integrations with lots of different open source vendors and non open source obviously Grafana as a closed source too. And so that is one thing. And other thing is that we're actively obviously working on this project. We wouldn't have IOX here today if we weren't actively working on things. And from what I understand Timestream is a lot more of for good or for worse a consistent product. It's not necessarily being actively improved or doing lots of fun new things with it but it stays consistent. That's the best I can do because I haven't looked at it recently. And I will say this, Amazon they have so many products under their suite under their umbrella that it's always mind boggling to me personally when I look at AWS and realize all the new products that they've come out with. So obviously I'm biased towards Influx DB and so is Zoe but we like to say that Influx DB is purpose built for time series data. That is all we do. All we do is work on our time series database and all the different components to the platform. So it takes a lot to build a database and we have an entire engineering team working on it. And I will say this, there's also other time series tools or other tools out there that you can use time series for but they weren't necessarily engineered for that. So it can't handle the really high ingestion that is natural with time series data especially when you're starting off. And also we don't have any external dependencies. There's other time series tools out there that are built on top of Postgres and other platforms. So it can slow it down a little bit. And on that, someone just asked how does Influx DB compare with Prometheus? And Prometheus is great. I know a lot of people who love Prometheus as an observability or DevOps monitoring tool. However, it can't scale out. From what I've seen, it's really great for smaller scale projects. Zoe, is there anything else you'd like to add to that question? So the big thing with us versus Prometheus is we also offer that cloud offering. And from what I understand, Prometheus has an enterprise offering which can scale out quite well. But I think that's more of an on-prem solution for them and then they have their open source but they don't really yet have that middle in between where there's the cloud option. Is it possible to use Flux with Influx DB IOX or do we need to switch to SQL? So this is my fault and I'm sorry guys for not saying this a little bit better. Here, let me go back here. So yes, Influx DB IOX also supports InfluxQL and Flux. We are taking backwards compatibility very seriously. We're actually currently working on InfluxQL with that backwards compatibility. Apparently the Flux wasn't such a big deal to do it but InfluxQL is proving a little trickier but our engineers are currently working on it. So yes, you can still use Flux if that's your preference. The only thing that we're currently kind of working on is if you're already using Flux, don't worry, don't be afraid, don't run away but we are trying to have possibly newer users will rely a little bit more on the SQL. But yes, if you're using Flux, don't worry about it, you can still use it. So there's another question around this Zoe. Does open telemetry replace telegraph for network observability or monitoring? Let me really like, one sec, I'm looking something up. So the answer is possibly, if you're currently using telegraph to get your network observability monitoring data and obviously telegraph has a lot of different options like you could be doing something like you're getting it from like, I'm trying to remember the one telegraph one but like we have like ones that connect to like AWS and such where you can get all of your cloud data as well as a few other integrations that we offer. Yes, it might be a replacement, but it might not be because do remember that the open telemetry collector and receiver and all that, that is within the open telemetry project. And although I think it's super great and the project's super great, just remember it does mean that you're tying your horse to that open telemetry project and you're now within that ecosystem and that might not be okay for your company or honestly, if you've already done the work and you like what telegraph is doing for you like telegraph is working perfectly fine, do not feel the need to like go make yourself extra work if telegraph's doing what you need. Like that's, this is meant for people who always wanted this connector or looking for this connector as they're building out their observability, I'm gonna call it platform as they're building up their observability solution, they might be able to use this collector but if you're perfectly content with what you have don't worry about it. Can you talk a little bit more about the client library support for Influx DB 3.0? We've already seen cases in the past where the client libraries for Influx DB are moving to community only support. So I can tell you right now because I have this answer in my back pocket is that we will be building flight sequel support for Go, Python, C-Sharp, Java and JavaScript. Those are the five we are actively working on the Python one and the Go one I think are actually both technically done, they're just being I think extra tested basically but those will always be supported by us for sure, they're going forward into the future we're working on them right now and we would like to get all of our current 12 client libraries. Those five are the first ones to get done especially the Python and Go ones but after that because they're the most to be honest, they're the most popular like we have the data to support that those are the ones people use the most but after that we are going to be looking at building out the other I guess we currently offer 12 so the other seven that we would currently be offering and I think in all fairness, some of those client libraries aren't as straightforward as others like some of them are not language specific I'm trying to remember what they all are but yes, we are looking to support all of them. Will the influx DB ecosystem with telegraph and capacitor be updated as a whole? Telegraph to be honest lives in its own world. Telegraph is always being updated because it's open source and again because I mean the output agents are definitely being updated because they're being updated for SQL or we're just making new ones as well because it's one of those things where you can just keep creating output and input agents capacitor is in a state of flux, I suppose you could say and I have to admit I don't really know the answer for that one. I think the team, you know, we if people have been following along with the company for a while you know that we've been really putting a lot of our engineering time and effort into making influx DB cloud even more robust especially with the new storage engine which we've called IOX and everything else so I don't think capacitor has been worked on. It's still there but it just hasn't been a focus of the team. How do you agree with that? Oh, sorry, sorry Zoe. That being said, you know there's so many other ways that you can do real-time learning. I wouldn't be too worried that there's plenty of other options out there. How can you monitor SMP devices with open telemetry? Let me look this up really quick. I actually think we might have a I have an SMP telegraph plugin, weirdly enough. I think we do. I know it's come up in the past. Yeah, so currently open telemetry doesn't have anything in particular about SNMP. There are some people who are writing blogs about how to do it though. It looks like open telemetry has a receiver that you can use for this. So that would probably be your best bet. I'm really quick looking something up here. I did throw in the SNMP agent protocol monitoring integration. That's what I was about to say. Yeah, so that's a telegraph plugin and that would be a great way to do this. It doesn't really look like the open telemetry project is really focused on SNMP in particular. It looks like you can do it for sure because it's agnostic technically so it can fit anywhere. But if you want something that's a little more specific I would check out the telegraph SNMP agent that is available. The bit of a mouthful having the N and M next to each other. I always miss one of the letters. Yeah, when I searched it I missed the N but it still came up with what I wanted but I was like, oh, I think there's an N missing here. It's like neither of them are silent. Okay, how would I use open telemetry? Or sorry, how does open telemetry use telegraph on Inflex DB network while observability and monitoring functionalities? So just to clarify here, open telemetry doesn't use telegraph. They're not the same. Like I said, you could see them as competing in the fact that they do similar things but they won either one of them make any money so they don't really compete against anything but they are not working together. The open telemetry collector might remind you a lot of telegraph collectors to be honest, like that's kind of what it reminds me of at least but telegraph is one normally more specific about the, what's the word here? The product, the agent, the thing that it's worth like the fact that we have a SNMP agent in particular that's all it does. It just collects data from that device or when you're monitoring your cloud stuff it's specific to AWS. It's specific to GCP. It's very specific and what it works with. Now there's 300 plus plugins so the options are quite large but the auto collector is meant to work on anything.  They actually have a lot of architecture diagrams based on whether or not you're building out like a data science platform or a front end shopping platform. So they're a lot more agnostic in that way versus telegraph which is a lot more specific for what the plugin's gonna do. And but one thing they do share in common is they both define the type of data that you're gonna get back. So telegraph normally tells you all the data points you're gonna receive and normally you can kind of edit it and say like I don't want these things or I want these things or whatever. OpenTelemetry does a similar thing where it says this is what you're going to get back for your Chase's logs and metrics. This is the standard that we have set for you to receive this data. So in that way they are similar. How does Hotel handle NetFlow data? Let's see. Sorry, I'm looking it up on my other computer. Let's see, what do we get? They don't have anything. Let's see. They don't have anything in particular for it. Again, I think because OpenTelemetry is so broad in its use, they don't have anything in particular for NetFlow data. So yeah, so also for those of you guys who don't know, NetFlow stands for network flow data. So it's, I mean, it's kind of similar I suppose in the logs and traces, but I don't think, I have to admit, I don't think the OpenTelemetry project is necessarily for NetFlow data. I don't want to say that though, because in all fairness, I don't work for OpenTelemetry. Like I'm not, I'm very familiar with the project. Don't get me wrong, but I'm not a part of like their board meetings or anything. So I don't know necessarily what they're focused on use case-wise, but I don't think that's really what they would be for. But you could explore a little bit further, maybe ask a question in their community and they might be able to get back to you. Awesome. Wow, well, that was a lot of questions for Zoe. So if anyone has any other questions, we'll just keep everything open here for another minute. Zoe, thank you for that awesome presentation and handling all those questions.


Hello and welcome to this session. This is Professor Farhad and which would look at an examples that illustrate the single index stock market model, specifically interpreted in a regression line. This topic is covered on the CFA as well as the CPA exam because on the CPA exam, you will need to know how to read your regression line. It's also covered in an essentials of investment scores, whether graduate or undergraduate. As always, I would like to remind you to connect with me on LinkedIn if you haven't done so. YouTube is where you would need to subscribe. I have 1800 plus accounting, auditing, tax, finance, as well as Excel tutorial. If you like my lectures, please like them, share them, put them in playlists. If they benefit you, it means they might benefit other people. Connect with me on Instagram. On my website, farhadlectures.com, you will find additional resources to complement and supplement this course as well as your accounting, finance, CPA exam and other professional certification. So in this session, we're going to try to interpret the eight scattered diagram in terms of systematic risk, diversifiable risk and the intercept. So we're going to look at each one of them and just look at the, let's look at their systematic risk. Now what is systematic risk? Basically systematic risk is the market risk and it's, it is shown as beta. It's shown as beta in our regression formula. So let's take a look at those and what can we say about beta? What can we say about the, the systematic risk for these graphs? So let's take a look at them. First, you want to make sure you know how to, what are you looking for? You're looking at the x-axis and you're looking at the y-axis. On the x-axis, we have the market return. Let's assume the S&P 500 and on the x, on the y-axis, we have the individual stock return, whatever that stock is. And now we're computing the beta. Now, before we compute the beta, let me go back to the prior session and show you the beta. When we talked about the beta, we said a beta of one. If you remember when we talked about the beta, we said a beta of one. It means that's the market beta. Then I showed you two other betas. I showed you the beta for Amazon and I told you Amazon has a beta of 1.33. 1.33 means, and this was a five-year monthly data. 1.33, it means Amazon moves for every 1% that the market moves, it moves 1.33. That's the beta for Amazon. The beta for a company like Walmart is 0.32. Well, it means it moves less. Actually, it moves less than one. So we'd say Walmart is a defensive stock and Amazon is an aggressive stock. But now in relationship to the market, which has a beta of one. So one has one above one and one below one. So let's take a look at this graph to see how we interpret these betas. So how do we interpret the beta? So the steeper the line, the larger is the beta. But let's take a look at whether the beta is positive or negative. Well, if we notice here, this line right here for R1, if we look at R1 graph, we notice as the market rate goes up, as the market rate goes up, the stock price goes up. It means they are positive relationship. Same thing with R2, positive relationship. R3, positive relationship. It means beta is positive, positive, positive, positive. Now if we go to R7, we notice that beta is negative. What does that mean? It means there's a negative relationship between the market and this price. It's not positive, it's negative. Now, how else can we talk about the beta? So whether it's positive or negative. We want to know how large is the beta. How do we know how large is the beta by looking at the graph? Well, the steeper is the graph, I'm sorry, not the graph. The steeper is the line, the larger is the beta. So what do I mean by the steeper is the line? Let's take a look at R1 versus R4, just to illustrate the point. What do we say between R1 and R4? Look, let's assume this is 1, 2, 3, 4, and this is 1, 2, 3, 4. So as the market moves one point, this moves too. As the market moves, it moves higher. As the market moves, it moves higher. Notice here, if this is 1, 2, 3, 4, notice where they meet. Now, the stock does not move faster than the market. It means they move in tandem, so beta is lower. So when the line is steeper, notice here in R1, is the line a steeper, it means the stock moves faster than the market. Notice there is a big gap versus a small gap. So the steeper this line, so if this line was this much steeper, it moves way faster than the market. So as the market moves one point, if it moves this steep, the other move will be here. The stock market, the stock price moves faster. It has a high beta. So what we can say is this. If we notice 1, I would say 2 is a steep, 3 is not as much, and 6 is steep. So we'd say 1, 2, and 3, they have a larger beta. Larger beta means more systematic risk. There is more market risk. If we can see that R3, let's change the color, R3, 4, and 5, they're flatter. What does that mean? It means beta is not high. It means they are defensive stock. In a sense, they are defensive stock. Okay? When the market moves, they don't move as fast as the market. The beta is less than 1. If you move exactly like the market, you'll be 1. If you move less, you are considered defensive, defensive stock. And how do you know you're a defensive stock?  So this is the beta. This is the systematic risk. By looking at this, you need to understand how we interpret this. Now let's take a look at alpha. So we looked at beta. Let's look at alpha since we're going to go. We should have started with alpha, then beta, but it doesn't matter. Alpha is the intercept. What is the intercept? Is where the line hits the y-axis. Is where the line hits the y-axis. Where does the line hits the y-axis? Let's look at this. The line hits the y-axis here. The line hits the y-axis here, here, here, here, here, and here. This is the intercept of the line. What is the intercept of the line? what is the expected return when the market is neutral? When you have no risk premium in the market, what do you expect to earn? When there is no risk premium, what do you expect to earn? Now, even if there is no risk premium, you want to expect positive. You want to have a positive y-intercept. So here, y-intercept is positive. Here, y-intercept is negative. Positive. I'm sorry, negative here for R3. Positive. Negative. Negative. Negative. And positive. So you want the y-intercept to be positive. Now, why? If you remember the regression line formula, it's alpha plus beta times the risk premium plus the EI, the risk that's specific to the firm. So this is the line. This is the regression line. So you want this to be plus to have a higher return. You want alpha to be plus. So that's why. So the y-intercept, the intercept is alpha is where the regression line crosses the y-axis. And you want to cross the y-axis on the positive and not negative end. So that's the intercept. Let's take a look at the diversifiable risk. So what can we tell from these graphs about what we call the diversifiable risk? What is the diversifiable risk? Is the risk that you can get rid of by diversifying. Well, how do you know if you can get rid of the risk by diversifying? The more the points are clustered to the line. So notice here, those points are clustered to the line, to the single line. It means the risk can be diversified. The risk if we have enough stocks, if we combine them all together, we can diversify the risk. We can diversify the risk. So let's take a look at R2 right here. I would say R3 and R7. R7. So what can we say about those? They have a low residual value. They have a low residual value. Why? Because notice the performance of the stock is close to the line. The closer it is, the low is the residual value. If we look at other stocks like R4, let's see if there's one that's worse. Let's look at R1. Notice R1, the points, the return are a little bit further from the line. Notice R8, same thing. There's a lot of residual value. Residual value means there's a lot of risk that's specific to the company. That's specific to the company. For R2, R3 and R7, the more we diversify, the closer we're going to get to the line. Why? Because the return of the stock is affected mainly by the market, not by the residual value, not by the firm specific. This is what we can say. So what can we say overall about the total variance just from the graph? What can we say? Well, let's take a look at each one separately. Let's take a look at each one separately. If we look at R1, if we look at R1, R1 and R6 are very similar. If we look at R1 and R6, they look very similar. Positive, positive beta, obviously positive, and it's a high beta. High beta, one has a Y-intercept. One has a positive Y-intercept. One is negative and one is positive. That's fine. They both have a high beta and notice they both have a high residual value. High beta and high residual value. What does that mean? If you have high beta and high residual value, if you have both, it means you have high beta and your risk is not diversifiable. What does that mean? It means you have total variance that's high because the variance is based on your company, your company risk and the market risk. Here, both your company risk is high and the market risk is high. So one and six is kind of basically driskiest. One and six are driskiest because they have both. High beta, the line is steep and the returns are varied across. So that's one and six. Let's look at three. Three I will have to say definitely residual value is low. Residual value is low. Notice the points are scattered closer to the line and it's not that steep. It's not as steep. It's steep, but it's not as steep. I would say it's not bad from terms of variability. We have a low beta. Now let's say two. Let's see. Now if I'll have to say I would say three will have a low beta. Three will have a low beta and low variance. Yes, low residual value over all low variance, low residual value. Three, not two because two, I see two still have a high beta. So let's go back to two. So two, definitely low, low residual value, low residual value, but high beta. Two has a high beta. I misspoke. I just, it looks, yeah, two has a high beta. So one, two, three, four. What can we say about four? Definitely four is a low beta because the line is is kind of, line is flat, but high residual value. And we're going to talk a little bit more about the residual value in the next session when I look more at the regression equation specifically about R square. We'll look at R square. So basically we looked at, we looked at them all. Hopefully this gives you an idea about how to interpret this regression line. So a few things you want to remember. Where does it cross the y-axis? That's the intercept. How steep it is. The steeper it is, the higher is the beta. It means the higher the systematic risk. And how much the points are scattered across tells you about the residual, whether the residual value is high or low. High means they're scattered all over. It means the risk of this company is dependent upon the company itself, not upon market condition, market condition. In the next session, again, maybe I'll work a regression line just kind of to work a little bit more with the formula. As always, I'm going to remind you to connect with me and like this recording, share it. And if you want additional resources about this course, please visit my website. Study hard, stay safe, and good luck.


Developing Enterprise and Community Distributions at the same time. Impossible? Please welcome Fr. So just to make sure the recording is working, my wood password is star, star, star, star, star. Now everybody knows about it. Okay, so my name is Frédéric Rosa. I'm working at SUSE as one of the SUSE Linux Enterprise Release Manager. And today I will talk to you about how we try to develop our Enterprise distribution alongside with the community distribution in open SUSE. And some people think it can't be done, and we are trying our best to make it possible. And I'll use a tumbleweed, leap and sleigh as an example. So first, just a quick guess. How many people know the difference between tumbleweed, leap and sleigh? Okay. Quarter or third of the room. So that's good because I did a slide just to make sure everybody knows what I will be talking about if you are not used to open SUSE. So I will use very often the term sleigh, which is SUSE Linux Enterprise. This is our SUSE product, so a set of products, like sleigh, the server product, sleigh, the desktop product, and among others. So this is an Enterprise distro, long-term support, et cetera, et cetera, et cetera, which is developed by SUSE. Then we have what we call open SUSE factory, which is our development repository. So for people used to federalize, this is equivalent of Rohide, mostly. And for Debian, I don't remember the name of the development repo, but you get the idea. We have also now, on open SUSE, we have two distribution, not just one. We were a bit crazy. We thought, yeah, why do just one distribution? Let's do two. We have what we call open SUSE tumbleweed, which was initially created by Greco Hartman. And then the focus was changed a little bit. And that's open SUSE rolling release, a bit like Gen2, Arch, et cetera. Except that it's based on open SUSE factory or development repo, but it has to be fully tested and it has to pass our automated tests powered by OpenQA to be released. So on a good week, you get one release every day. On a very, on a slow week, you might get two release per week. It depends. And usually you get one kernel every week. Or on heavy weeks, you get a lot of kernel changes, et cetera. So this is a very fast rolling release. And on the other side, we have now what we call open SUSE leap, which is our stable distribution, which is based on the SUSE Linux Enterprise code base plus some part which are coming from factory or some specific repose, but most of the things are coming from factory. So we have a mix of something very stable as a base and something more fancy or more recent on the top. So I hope you can see the slides because there is a lot of light. But mostly you can see how we create the various product. So we have open SUSE tumbleweed on the top, which is St. Richard. We have open SUSE tumbleweed, which is always rolling. And we have our SLEE code base, SLEE 12 service pack 2, SP3, and then SLEE 15. And then Leap is based on top of the shared code. And when we do a new service pack on the enterprise level, we usually either we backboard things from upstream or from tumbleweed or we just grab packages from tumbleweed. So this is the theory. Now let's talk about the reality. First, what we learned from our past. So I usually use the same example. So sorry for people who attended the open SUSE conference previously. So I'm going to use the desktop that we ship on SLEE, which is GNOME. And for our last major code base of SLEE 12, which was done three to four years ago, something like that. We decided, oh, we'll take GNOME 3.10, which was at that time the release which was available upstream, more or less. And then we patched it. We fixed bugs. We added new feature for customers, et cetera, et cetera. The only thing is that we just kept our patches in our SLEE repo and we didn't push them on open or we tried to push them upstream, of course. But we don't always push them to open SUSE factory. So to our development repo. And we always said, oh yeah, we are on a hurry. We'll do that later. And then we released SLEE 12. And then one year later we released SLEE 12 SP1. But we had so many bugs to fix that, okay, yeah, we'll upstream later. And so basically nothing happened for SLEE 12 SP1. So we had two code base, not completely, but really diverging. So the stable GNOME for the enterprise customer and for people on open SUSE, something more recent, directly from upstream, at losing some time fixes which were done for customers. So it was really not great. So we realized that, okay, we have to take action there. We really need to fix this mess because otherwise it will be unmaintainable on the long term. Just as a reminder, the code base for SLEE product, we have to maintain it for 13 years. So you really want to make sure that you don't, you have something which is sustainable. So what we say that, okay, for the next service back, what we'll do is we want to think our GNOME version in SLEE and the one we have in open SUSE. So we took the chance to update the version of GNOME from 3.10 to 3.20. And at the same time we said, okay, can we make this source package exactly the same for both projects? And we did it. It was 300 packages. We had people discussing between the SUSE desktop teams and the open SUSE desktop teams, which were completely different people. The open SUSE desktop teams or the open SUSE GNOME team is known to be very picky at documenting changes. Richard is part of it. Now these days I'm also part of it, but at that point in time, and it's still ongoing, you have to make sure your change log are really verbose, well-written. All the patches has to be properly documented with a bug number, et cetera. So it's really something that sometimes in the SLEE products on the desktop side, people were a bit sloppy. So they have to cope with the rule of the open SUSE guy, okay? And we made sure to help the developers that they could see how much they were diverging between the SLEE product and the open SUSE packages. And so far when there were changes which were really, this seems to be just useful for enterprise customers. If we do that for the open SUSE people, there will be a set, et cetera. So let's add the patch, but we only build it for SLEE. So we made sure that we were not breaking the open SUSE side of the world. And we also discovered that sometimes the open SUSE people were suffering from bugs that we had fixed in SLEE, but we forgot to enable the patch. So they had the patch, it was not just enabled. But we did it. The point was that we were able to work internally and then push to open SUSE. We made sure that we had checked in place to make sure that packages, this is a requirement for the SLEE people, we should always never lose a bug number in change logs or feature number, as Richard talked about in the change log or CV number, because we want to be sure that we never have a regression in the code base when we upgrade a package. And this is something that sometimes the open SUSE project was not that concerned about. So this is something we kind of enforced. But the open SUSE people were very helpful in accepting that we injected bug numbers, which were kind of fixed, but the code never showed up in the open SUSE code base, because it was just fixed by upstream, but we just had a way to tag that, okay, this bug, it has been fixed in the code base. And so far, these days, the bugs which are found on the SLEE package, but where the SLEE package is coming from the SLEE, it's pushed to the SLEE people. So in short, it means that packages and users using packages which are inherited from SLEE get basically the SLEE quality or at least what we sell to customers, but they get it in open SUSE. So best of both worlds. So this was the past. And now, let's see what we have currently, what we are working on, which is SLEE 15, our next major release, and SLEE 15, which is the equivalent on the open SUSE side of things. So first, let me show you how we get things into our project, how we get changes in our project. So how many people are familiar with the open build service or OBS? Oh, that's good. And not only open SUSE and SUSE people, that's even better. So this is roughly what's happening when people want to do a change on the code base, either on SLEE, so we have our own copy of the build service, we have an internal build service, and on factory, so on table with the open SUSE side of things. So I use the term developer. You can replace that with a contributor if you prefer, but volunteer. I'm fine with that. So developer is going to create what we call a submit request, basically a change, a patch with a change log, a new version, a new target, whatever. He's going to send that, so he's going to build that in his own branch, and he's going to send that to a specific distribution, so it can be SLEE 15, it can be factory, et cetera. Then this change is going to be staged, and a small subset of the distribution is going to be regenerated. So basically, we recreate the entire distro based on this change, and we are going to test it with OpenQA. We are not going to run a full test suit, but we just want to make sure that basically, we can still install the distribution, the desktop still starts, and the icons are still in the proper place, et cetera, et cetera, et cetera. So this takes about 20 minutes to one hour these days. And the change is blocked at that point. Then at the same time, we have a review team, which is going to check the change. So the review team can be on the SLEE side, it's usually a release manager, and other people who are used to the code. On the OpenSuser side, it's going to be also a release manager from OpenSuser, and very often, before that, there will be the people responsible for the set of packages, let's say the GNOME OpenSuser team, they are going to first review the change and say, yeah, it looks fine. So we have the four eyes review principle in effect on both side. And if the change is fine on the OpenQA side, and if the reviewer say, yeah, it looks okay, fine, then we accept the change. It's going to be integrated into this role, which is going to be rebuilt. And then we are going to rerun the test suite, but this time we are going to run the test suite with all the tests. So you have an idea of how we integrate changes in the distro. So we decided to put at that level here a lot of automated reviews. And a policy to make sure that we don't diverge, or at least we don't diverge too much. I forgot, if you have questions, you don't have to wait until the end. So we have what we call internally at Suser. We have what we call the factory first policy now in place, since it was already kind of in place since our previous service pack, but now it's really fully in place for our new cut base. This states that the development of the distribution has to be done on factory. People should not do the change on our internal build service. They should do their development on the open build service, and they have to push everything on the open source factory, so basically on a tumble with the rolling release, which can be released almost every day. And then once it's merged in the open source factory, we then take it back and push it in our SLEE 15 code base. So the idea is really to do the development in the open. There are always some caveats. Sometimes we have some features which are developed with some partners which are in the NDA until specific date, so we cannot release a code base until the NDA has ended, et cetera. But for most of the things, that's what we do. And to make things easier for developers, we said, okay, since we are asking you to do the development on tumble with, or factories, it's the same, you don't have to even take care of SLEE 15, at least for now. We have a bot which is going to look at all the changes which are accepted in the development distro, and it's going to retrofit such those changes in the SLEE code base. So it's really something like you are working on an enterprise product, the next enterprise product, but in fact you are working on the open source tumbleweed, and we just generate the enterprise product based on that. So really, this is to prevent forks or unwanted forks. And, yeah, because I'm not following exactly my slides. Did I say everything I had? Yeah. So those submissions from this bot, when something is accepted on factory and pushed back to SLEE 15, they are still reviewed by the same four eyes principles. They are still reviewed by the release manager on the SUSE site. And sometimes we find mistakes, or we find something, yeah, but this might fly on open SUSE, but it won't fly on SLEE for that, that, that reason. And then you have two solutions. First, either you say, I'm going to fix that just for SLEE. This is an easy way. No. Usually what we do is we reject the change for SLEE, and then we notify whoever did the change saying, okay, what you did, it's not great. Could you please fix it and make sure that you fix it on factory. And then when it's accepted, we'll get the proper change. Funny thing is, often sometimes we detect things, even if it was reviewed by four different eyes in factory, we detect issues with our own four different eyes on SLEE, and then we just fix it. And so far, it has been in place since we have started to work on SLEE 15, and it's still in place until this week. So we are still in beta phase, but we had this update crawler, what we call the update crawler bot, which is just crawling the factory system and making sure that all the changes are pushed back to the SLEE product. Yes. You mentioned that there are some, what are the main reasons for such occurrences? Is that something working for OpenSUSE apart but won't work for SLEE? I'm repeating the question, so why something would work on OpenSUSE and would not work on SLEE? What are the main reasons? The main reasons. I'll go there a bit later, but an enterprise product is always much smaller than an OpenSUSE version, usually compare Fedora and RAIL or SLEE and OpenSUSE. So we focus on less things, and sometimes a package might enable things like, oh, we want to build for 200 language bindings or that we don't ship on the SLEE side, so we want to disable that. We don't want to have build requirements on that. Or it can be that they want to support something which we don't ship on the enterprise product. Or sometimes there are a few cases where we are on purpose diverging from the OpenSUSE side of things and then we have to say, yeah, but it won't work, so we have to handle this slightly different. But this is, I would say, a conscious decision. It's just not happening like that. So basically the factory first policy is your submission won't pass unless it has good reason to pass. So we have, as I said, we have put a lot of bots in place to check all the submissions which are done. We have a legal bot. What it's going to do is check each submission and compare that with our legal database which contains all the source codes, did an analysis on the source code and checked the license of each files, did a report and gave that to our legal team who have said, yeah, looks okay, or there is proprietary in the source code. I don't think that's good and they're going to reject it. But there is a lot of automation to make sure that we don't end up filling our lawyer desk with that of, no, it's not on paper, but you get the image of reviews. But it's still catching a few things here and there. So that's always good. Then we have what we call the maintenance bot. It's trivial, but it just makes sure that the submission that has been sent already builds in the branch from the developer because sometimes people send something and it doesn't even build for them. It happens. It can be, it's not always there for, it's just that they did something, they sent the submit request and then basically things change under their feet and it doesn't build anymore and no. We don't bother even reviewing the change because we know it's going to break if we accept it. So it's automatically rejected. We have, I talked about that earlier, we have what we call the change of checker. So this is a requirement for SLEE. Any change has to have a bug number or a feature number or a CV number. So during the development phase, it's not really enforced, but once we enter the RC phase or once we have our product shipped and we work on service pack, we want to make sure that each change is properly documented and we know why we are doing some changes, not just doing changes at random. And then the last bot, which is the one that people complain a lot internally, is what we call the leaper bots. This bot is going to check, is going to enforce that the factory first policy is properly done or followed. So if the package has been directly submitted from the found factory, everything will be fine because it's already upstream in our upstream, which is the open source. But sometimes people are in a hurry or they want to get a change in the distro, in the SLEE distribution very early before it's even accepted on the open source side of things. So there the bot is going to check, is this submission accepted on factory? If not, is it accepted in the development project on open source? And if not, rejection. And that's when you start seeing people complaining. Because, yeah, but I did exactly the same change on both sides and it's, yeah, but you didn't really do the same change because you did the work twice at 10 minutes of interval and your change log entry doesn't have the same timestamp. So basically, you put the bot on yourself because you did the work twice. You could have done it just once and it would have been accepted. So it's really, we are really trying to change the mindset of people to contribute directly to our upstream, which is open source. Reduce their own work. And if they don't do that, the process is going to reject. And there are cases where we decide, okay, this package, we accept to not follow any more factory, so our development. We want to branch because this is still an enterprise distribution and we at some point know that we are going to freeze the version of things or we are not going to take every last changes or every new version of everything. So for instance, we have branch or kernel. We are based on kernel 4.12. It has been decided a long time ago. So the kernel is not going to be submitted from Tumbleweed to Slee but the bot is still going to check if there is something which is a similar change which has been pushed to factory. So this is still good because the kernel is here and not a good example but let's take a package, I don't know, Firefox or whatever. You want still when there is just a change to make sure that we have the same change as it been pushed to factory or not. Sometimes it's not relevant because it's a backboard from a new release which is already in factory but sometimes it's just a patch with a fix just for one thing and you just want to be sure that this patch has been pushed in both code base because if you don't do that then the next time we rebase this distribution on Tumbleweed so for Slee 16 in three, four years, I don't know exactly people will have to do the work again they will have to push their change again to factory. As an example when we did this entire process for Slee 15 we checked, we compared everything in the latest Slee 12 code base and factory and we found some time patches which has been pushed since Slee 8 or Slee 9 so that's something like 10 years so the guy 14 for 14 years a guy was doing a change every major code stream release so let's say every four years every four years he was pushing the same change the same patch it still applied on the enterprise code base it never went to the open source side of things so the guys were redoing the work every four years for 14 years so some people might say yeah that's a way to make sure you still have a job but if he would have done that in the first place he would have saved a lot of effort and because we now enforcing this rule we don't want these kind of ugly things to happen so it was like submission, factory first we won't take it in Slee you have to fix it but factory first and now it's in factory so in four years or three, four, five years the job won't have to be done again and again and again this is a leaper bot as I said and Richard already said it because we had a lot of discussion on that if you want to do this kind of policy use automation really because people will be frustrated by the policy but they will be less frustrated if the rejection is coming from a bot rather than a human we saw it in addition make sure you give your bot a name the mentioned bot you make the statement naming a bot after your people yes so repeating the the comment from Richard make sure your bot name contains the name bot in it because we tend to have you know, internal service every count has to be binded at first to somebody and basically the mail was sent by somebody and people didn't realize it was not somebody rejecting it was a bot which was just impersonating somebody but really, really it's helping a lot because people tend to be less frustrated when they get a rejection by a bot they would say ok, I'll fix it and then they comply with the rule especially it was really visible on the changelog checker rejecting when there was no changelog entry not a bug number entry was really something we were enforcing before manually and people didn't they would argue when it's a bot, they submit one minute later the mail that it has been rejected and then one minute later we get another submission fixing the damn thing yes, exactly, mission accomplished of course you will always get people arguing sometimes for good reason but that's fine when you reject something don't just say reject make sure to say why you reject or leap a bot is making sure to give URLs to why it was rejected like the diff between the package which is submitted and the package which is on factory so people can see that yeah, you have trailing spaces your bot is sometimes a bit dumb it's not going to do semantic difference between patch set it's going to do a plain diff and then if something is slightly different a human would say yeah, that's fine the bot is going to be very dumb now but if you can give enough information in the rejection people will fix it themselves they won't have to ask you why was it rejected very often we see that it's automatically rejected and then we get a submission 5 minutes later again time saved for all the people doing the reviews all the infrastructure because we don't have to accept a submission which then is going to be fixed again and again and even for the developers because basically they are being taught that yeah, you did something wrong here is how you can fix it and they are going to fix it themselves yeah, that's basically that and make sure that you can still override the bot so yeah I will not say that we are the release manager of our JDAIS but sometimes we are, we use our powers to make sure that things go through because this is still a bot and sometimes the bot is really wrong so we talked about the policies that we are enforcing and how we are enforcing but you might wonder, yeah, but does it work, is it give me numbers so first on SLEED 12 so the old codebase not all in the sense that it's released, it's shipped but it's not a brand new that we are working on so we have the concept of service pack, so we layer things on top of other things so we have a codebase, a SLEED 12 codebase which is mostly 3,000 packages 290, etc then on top of that one year later we did service pack one where we only changed 550 source packages the rest was not even rebuilt so the source is the same the binary is the same unless there is something which is changed in between which needs to be rebuilt and on top of that we did service pack 2 we used some kind of tiktok semantic for our service pack so one service pack is the first service pack is stability fixes not too much feature service pack is let's update the kernel and update the desktop and all the things and then again a stability service pack so one year we fix things together you break things thank you Dodgy for saying what I was about to say but it's best that I don't say that so one year we stabilize things and one year we bring new feature let's put it in enterprise nice way and on sly12 sp3 which was the first distribution where we really enforced the factory first policy we had rosly 500 source packages 300 were forks like we were diverging from factory but we made sure that those changes were still pushed on open source and still we had 20% of packages which were directly imported from the development distro from factory which saved a lot of time and effort for everybody so this was sly12 this is a process we put in the middle of the development now switching to sly15 we are currently at beta6 which was released on Friday we have 300 3000 and 300 source packages which is compared to sly15 about 10% more about the same number of packages so on those 3300 packages we have only currently when I did the extract on Friday we have 7.4% of packages which are forks so we have more than 92% of the distro which is already tumbleweed which is factory so our enterprise distribution is basically 90% open to the tumbleweed as a date of last Friday of course so when I say it's identical it's identical at the source package level so SRPM are the same what might we decide to patch things in we apply a patch which is only irrelevant for sly or for open to the in some case but that's more the exception than the rule for reasons that we discussed earlier we don't ship KDE for instance on sly so sometimes there are packages which are going to build things or requires KDE so we are going to disable that on sly etc but that's not bad so this is about sly let's switch yes question so how our salespeople are going to sell the fact that our enterprise distro is basically the open to tumbleweed with distro so first they don't yet know it that's why you came here right? yeah yeah to make sure they won't know about it more seriously we we still are going to tumbleweed is a rolling distro so in one month it will be farther away from sly 15 so it's going to drift and but we will make sure that our sly code base has to be rock stable etc insert all the thing about that and yeah we at this moment in time yes we are at 90% we will go lower on that I have two questions in the back yeah I was wondering when you start freezing packages have a situation where things will differ shouldn't you have then a leap second way to say ok if we do the back port fixes we back port it first to leap and then it goes into sly so the question was yeah you are going to freeze the versions so what about the back ports all the fixes are you going to do in sly or what do you do you push them to open so yes this part of the policies or factory first policy mentioned that people should still submit their change to the open source side of things if it's a back port often you don't have to do it because the version will be just updated in autumbleweed and that's it if it's just a patch it has to be pushed so we are still making sure that all changes our stabilization effort benefit to open source just for the sake of in 3-4 years when we base our enterprise product we just want to have those fixes already in we just don't want to redo the work again and again and again you had a question that's good ok yep so I talked about sly let's talk about leap so leap as a reminder is the distribution which is using the core of the sly source package and then on top of that a lot of more packages which are not cheap on sly or that open source community things we want something more recent than which is on sly so it's very small but I have some graphs after which are a bit more readable but raw sly for the latest leap release so 42.3 we had 10,000 source packages compared to 3,000 source packages in sly from those 10,000 2000 raw sly were coming from sly so 20% open source leap is 20% sly all the rest is either coming from factory 22% and the rest is 42 because we use the same concept I should have put my slides in the order 42.1 42.2 42.3 so 42.3 is done on top of 42.2 which is done on top of 42.1 so the changes which are only in 42.3 they are coming from 20% sly 22% factory a few things which are specific to this version so KDE5 LTS release that's a KDE people did nicely for they made sure that their release schedule was a bit following the open source leap schedule which was very nice from them and then we inherit half of the packages from the previous release and then again and again you have to think remember that open source leap is thought as a stable open source distro so long term support or whatever you want to call it for people who want something which is going very fast we have another answer which is called open source tumbleweed and we have leap 15 which is in beta which is in beta for about one or two weeks it's following, it's based on Sly 15 it has mostly the same number of packages than leap 42.3 so 10,000 packages source packages on those you have 27% coming from Sly 15 so Sly 15 remember 3,300 source packages and from that we are able to reuse in leap 2,800 packages but you should have done the math of how many percent of the Sly 15 entire code base is in leap but that's not bad and the rest is coming directly from factory and we have bits, a few bits from the devil project so if you put that in a nice graph you see that when we did the first leap release 42.1 there was a bit chunk which was coming from Sly and all the rest were coming from factory and then over time we reuse the packages from, so the percentage of packages used from Sly increased which is good because it means that what I forgot to say that opens through the leap being based on Sly packages packages which are coming from Sly are maintained by the through the people so when there are bug fixes they have to be done by the through the people so the community at large benefit from the work that the through the employee are doing and fixes which are done for paying customer on Sly they end up once maintenance update is to the Sly people while after a few weeks or things like that it's going to end up automatically in leap so leap benefit from the fixes that people are paying through the to fix on Sly so the more packages which are coming from Sly means the less pressure work the community has to take care directly they benefit from paying customer so that's nice and yeah, leap 15 as you see 30 about 30% from leap and the rest is from factory that's nice and with that just to make sure that we are always improving as Richard mentioned we are agile we learn over time things which works things which doesn't work and we are trying to improve smooth our process we have a lot of discussion internally but I'm really hoping that you have also questions suggestions so I'm open to that yes, yes so you said you're using open Q8 to test the data I'm referring to the program so you have a small open Q8 that runs a few tests and then you've got other open Q8 that runs all the tests for the first one does it mean that the free I mean for open Q8 works with screenshot so I'm repeating the question for the recording so we have open Q8 which is testing first when there is a new change a small subset for the entire test suite once the change is accepted the entire test suite open Q8 is based on a screenshot but it's NCRL and the thing is that once you have a distro which is installed by open Q8 you can run anything in it and you can run a different test suite inside and just check the results in open Q8 that either is the result of the test suite internally is going to be pushed to the serial console or just display OK and then the screenshot tool is OK appearing or not but you didn't finish your question so the question was since we are open QA based our package from community contributing to open QA so yes and even more than that we are making sure that our test suite between the sleep product and the open souser product are shared as much as possible I don't think we are at 100% but so it's all on github other questions remark no? OK thanks and if this is a kind of challenge or I'm interested in souser has a lot of job openings


Caribbean Nutrition Day is observed annually on June 1, followed by a month-long observance. During this period, the Ministry of Health, Wellness and Early Affairs focuses on educating and informing the public on healthy eating and active living. This year's activities being observed under the theme, Let's Norish to Flourish, Your Mental Health Matters. Nutritionist Fadia Campbell informs that the first celebration of Caribbean Nutrition Day was held in 2004 in response to the growing recognition of nutrition in disease prevention and health promotion. The theme draws from the past three years of experiencing the COVID-19 pandemic and focused the attention and the needs to return on the health and mental wellbeing of the population. The objective of today, and beyond, is to promote increased consumption of fruits and vegetables and to encourage people to be more active in their lives, whether it's by walking or some form of sporting activities. Research has shown that foods can have different effects on a person's mental health. Manager for the Department of the Public Service Employee Assistance Program, Sasha Jopya James says mental health is essential for wellbeing and happiness. Unfortunately, mental health and wellbeing are often overlooked or taken for granted. This leads many people at risk for developing mental health problems such as anxiety, depression and post-traumatic stress disorder. If left untreated, these issues can become increasingly severe and lead to serious consequences such as physical injuries, impaired functioning and productivity, substance abuse and suicide. Speaking ahead of the proposed ban of sugary substance in schools, Chief Nutritionist Lisa Hunt, in her address, encouraged students to avoid foods with excessive sugars which, according to her, can affect the thought process and alertness. Eating poorly can make us tired and fatigued and sluggish and we may not be able to focus well and that can lead to stress and depression. Most times when people have stress and depression they think of taking antidepressants but sometimes it's all in what you eat or your lack of physical activity. I am focusing on nutrition but physical activity, being active, plays a very key role as well. The Wholesome Food Exhibition and Demonstration included a health education component which provided the enthusiastic students with an opportunity to quiz ministry officials. The Nutrition Department of the Ministry of Health, Wellness and Early Affairs will be hosting proper nutrition promotional activities in other parts of the island. For the Ministry of Health, Wellness and Early Affairs, I'm Sant Justin.