 Okay, now recording is working. Excellent. Hello, everybody. Looks like a good crew. You pull the agenda up. It is as I left it. People wouldn't mind filling out the attending section which I'm about to add. Great. Post the notes. I feel like I mostly see familiar faces on the call, but a couple people look a little new to me or sorry if I've forgotten you. MBL looks like a room full of people. Who's all that? Everybody from Facebook want to introduce yourselves real quick? Hello, we're part of the tracing team here. Welcome, everybody. Arabic carrier. This is the big chunk of our tracing team here. I'm glad to have you all on the call. Also, hello to BHS from LightStep. I see he's on the phone. We've got Joe Farrow here from Uber slash Jaeger. Austin Parker from LightStep. Erica Arnold. Good to see you, Erica. Erica's from New Relic. Tyler Benson, Java agent specialist over at Datadog. Just Chris with no last name. Not sure which Chris that is. We've got Matt Weir also from New Relic. Ananya Garwal. I'm not sure who that is. Would you like to introduce yourself? Ananya, sorry if I mispronounce your name. Hey, it's Ananya. Sorry about that. Yeah, that's no problem. I'm working in a startup in India. We work on ad tech. Yeah, recently started contributing to Jaeger. Okay, great. Nice to meet you. Thank you. Who's Chris? I'm curious. I'm just going to assume Chris is China. Hi, China. Okay. So on that note, I threw a couple items onto the agenda today. One was an update around open census. There's been a sort of exploratory working group looking at seeing what emerging the APIs for these two projects would look like. So I'd like to give just a quick update on that. As well as room for questions because I'm sure there are some. And then just a quick update and more of a shield for special agent. So unless we have a big open census talk, it will probably be a short meeting. Feel free to add things to the calendar if you'd like to discuss something else. And on that note, yeah, the big ticket item, I think for this meeting is just to give people kind of an update on where things have been going with open census. So a while back, maybe December, a sort of exploratory technical working group started getting together because these projects are so similar, their APIs are very similar. But on one hand you've got a project that's more like an implementation and that doesn't have a really abstracted API. And then on the other side, you've got an abstracted API, but no reference implementation. And so for a while we've been like, man, if we could just bridge these APIs and share one, then we could have a bigger project where it was just as abstracted so people can still continue to plug their own agents into the instrumentation without necessarily having a whole bunch of hardware in the middle that they may or may not want. By hardware I mean software, sorry. And at the same time we could have a really, really awesome reference implementation that people were willing to invest money into and kind of hold down. So that seemed like a big win if we could bring these two projects together. Also everyone has been bothering us since the beginning of these two projects and we've been trying to reach them. So we finally started exploring what that would look like. And the responses were very positive. There is a branch of code. I can post this. If you want to look at our spike. So it's a branch Bogdan drew to if you don't know Bogdan Bogdans, it's a lead maintainer for open census. So we've been working a branch. And I will also put in just some notes. Our doc too many tabs. I'm linking here a doc that represents the API discussion up to this point. Just basically we looked at the places where these APIs diverged from each other and tried to see if we could come up with a bridge. Some solution that would make both sides happy. None of this is final. We just have gotten to the point where Bogdan feels really comfortable. From the open tracing side, Carlos Alberto has been holding it down a lot because we've mostly been focusing on Java. And so there will be probably something more like a real API that people could bind to and play with. That will be coming soon for review. And there's also now some movement from the founders. Ben Siegelman on one side. I believe Preetam who's in charge of the open census project on the Google side. Looking to found a kind of like governance bootstrapping group to figure out what a governance model would look like for the merge projects. Last but not least, we're also really interested in a new name. If we are going to merge these projects, the scope will be increased beyond what's in open tracing to include metrics. At the same time, open tracing is like a large existing project. We don't want to lose the name, open census didn't want to lose their name. So we decided everyone would lose a name and we'll come up with a new name for the merge project if we do it. Of course, no one has this new merge name. We have no idea what to call this damn thing. So that'll probably be the hardest part of this whole process if we do it. And on that note, I would like to open up the floor for questions because I'm sure there are many. And also please tell me what we should call this project. Thank you. I see Ben joined. Is there any more updates that Ben can add or on the governance side? Immuted. You muted. Ben, you muted. Is that better? Yeah. Ted said most of it already. I would maybe it's not like this is like literally done. I mean, I think there's the, I would maybe add to everything Ted said that there's overall a feeling like both these projects really exist in order to accelerate the adoption of tracing metrics, observability technologies and so on and so forth. And that having two projects out there, even if both of them were great, having two projects inside of one actually decelerates the adoption or at least a suboptimal. So that's really like the biggest problem. I think it's true. It'd be great to have reference implementation and an API and all that, but really like fundamentally the biggest problem is that having both these projects is creating confusion. And tax in terms of adoption and like that's really like the biggest problem we're trying to solve. I think the, the governance discussion I think is like pretty good in that it's the alignment in terms of what we're trying to achieve is really clear and obvious, but it's not actually done. And I think like this in my mind, the presentation of this update should be more like everyone wants this to happen versus this is definitely going to happen. This will definitely happen once it's actually happening, but it's not quite there yet. And I think we fall like it'd be good to give people heads up that the discussion is happening. So we don't want to feel like some kind of closed door thing, but it's not actually done yet. And until this, I don't want to say, okay, great, like let's publish a campaign, et cetera. Although I think everyone recognizes that continuing in the current parallel track is pretty wasteful and confusing for end users. So that that's like the really concerning part of it. I would say like the next month or something like that, we should probably be able to say that this is actually happening, but I don't want to, you know, call it before it's done or something. Yeah, I think that the moment that that prompted bringing it up for me is that we did have an exploratory committee just to be like, is it worth it to get everyone's hopes up and bring, bring everyone in and that group this past week hit a point where we felt like we had managed to address everything that's different between the two projects. And it seemed like there was a pretty obvious way to like solve those differences in a way where you could, we could put out a new API and just simply say this is like the next version of the API for each project and wouldn't feel like, like a huge record scratch or something that would be very difficult, you know, to continue to maintain the kind of like backwards compatibility and bridging that we always like to do and open tracing from version to version. And since we, again, we don't have a new API, but we have enough of a spike that that feels good. It feels like the right time to be starting to ring the bell about this project. But seriously, we need suggestions for names. Oh my God, definitely. So is this going to encompass the stats, capabilities inherent in census as well? Yeah. Yeah. Sort of, I would say that, I mean, this is, I mean, anything about like the technical details, I think does like a little bit more discussion, but I have been arguing for whatever this merge thing is to try and be more decoupled about things than census has been. I think the open tracing scope is probably a little bit too narrow in retrospect and that people don't want to have like many different nouns they have to deal with. They want to have like one now. But like having all of the different pieces coupled together any more than is necessary. Like weakens the whole, I think if for something like this, that could get kind of sprawling where it's like, well, now let's add stat traces. Now it's that logging. It just, it could get really big very quickly. So I think like it should have, I would argue if, I mean, I'm not saying it will, but I will argue that. Yes, it'd be great to have stats capabilities and yes, they should be as decoupled from anything else as possible in that, in that like converged project. If that makes sense to people. Thank you. Yeah, I can definitely say that one of the things that we've been kind of talking a lot about from the open tracing side is making sure that there is a clean separation. Like of abstractions and interfaces from implementation. So we focused on the tracing piece for now, but I don't see a reason that we couldn't also do the same for the metrics piece. So here's a bad name, but it's just something to throw out there, which is open observability or something along those lines. Obviously use. Well, it's, it's super ultra broad, but it's a, you know, it's a name to suggest you. Yeah, it's very long to type. Yeah. I do like that the, the initials are OO or it could be OOBS. OBS also an overloaded acronym, or you could just go O and then however many letters this and another O. Oh, true. That's that's your traditional way to handle that. Right. We could do the startup play and just do open tracing, but remove all the vowels. Or we could just move all the consonants. I like that idea, Joe. Yes. Projects is called shiny, spooky, shiny from everyone. Yeah. I tried to figure out because it's CNCF, I looked up the Greek word for telescope and discovered that it was telescope. What about the Latin word? That telescope thing is still like the faith. What's the sextant? How about sextant? I'm sure that's already a project. It's probably already a project. It's also, you know, a L-Lab. Was that a, you found that word? I would propose that we will not determine the answer to this on this call. People should send names to Ted or me or whatever. I don't know, or someone, but this is not the right way to do this. We need to have a contest or something. Anyways. Yeah. Do people have, you know, If you have concerns you feel are more private, you know, absolutely reach out to me, reach out to Ben, we're happy to address it and get you up to speed on what's going on. And as far as governance and other things, that's still a big question mark, though I know Ben's been talking to at least some people on that trend. So I'm just looking at the outline on the OTOC merge topics and actually I haven't read it yet, I guess. I was going to ask about span references but I guess I'll read it first. Yeah and it's fine talking about this stuff in Gitter as well. I would encourage people to read this and just ask questions in Gitter basically. It's probably the easiest way to get answers. Cool. I would say the biggest change we might want to make as part of this from the open tracing side is this general feeling that, you know, especially just separate in open tracing, perhaps for convenience, the tracing API and the context propagation API are the same. So, you know, the spans are the context and they're propagating the context and in open tracing there is a lower, sorry, an open census, there's a lower level kind of context propagation mechanism and then tracing and metrics and these other things are all writing on top of that. It's kind of a feeling like that's a better model. That's just a cleaner separation. So I would say from the open tracing side, trying to move over to that model in this next version of the API is probably the biggest change we would see from our end. All right. I'll leave a couple minutes for questions. One thing that would be very interesting to me to see in evolution in the API is a bridging span model with more of an event-based model that our Facebook has because I don't know how Michael feels about this whole open census and open tracing in the first place. I doubt that they are going to be like, I mean, organizationally it's very hard to adopt when you already have an instrumentation like that but even from the modeling perspective there is currently like significant mismatches between what Facebook is doing and open tracing. I mean, I'd definitely be more than willing to help with those discussions and sort of look into them. I think one observation is that we actually do have sort of partial open tracing bindings for our stuff internally that some folks who want to open source their things are using. The span model is sort of more constrained but so we just have to be a little bit opinionated about how we sort of do that mapping from our things into spans but it's doable. But anyway, yeah, I'd be super interested in being a part of those conversations and sort of seeing if there's anything that makes sense there. I think the real thing is that the data model we have with Canopy is inherently more flexible but also inherently more complicated and people are super familiar with spans and things like that and the language and terminology around it. So I sort of get that from an external point of view. It's like, do you really want to really want to try and go with another data model when there's sort of one that's been around for a couple decades that works for most people. But anyway, yeah, if people are interested in that, yeah, let's figure out something. We can talk through it. Yeah, I definitely be interested for feedback. I would be nervous. I, you know, this opportunity to merge these projects and there's an opportunity to fix things while we're at it. But I also want to be wary that, you know, we don't, if we stray too, too far away from what either, like the other thing this project has to do is make sure we've got a bridge so we don't, we don't pull a, you know, Python 3000 or a Perl 6 in the process of doing this. But I think the number one thing we forward is to make sure, yeah, everyone who is binding agents or complicated things or people like Chris Urway or y'all at Facebook who have some evented model that's just like totally different from spans but would still like to, you know, play making sure there hasn't been something that makes that worse or if there's some easy way to make it better, this will be a good opportunity to get that kind of feedback. Yeah, I can jump in the getter and then we can sort of, you know, start talking through it there. But yeah, I mean, to the extent that we can provide sort of like useful feedback here, you know, I think we definitely be interested in doing it, you know, but also sort of definitely understand the, if you really think about the events are interesting, but what's really interesting is just very different sort of data models, right? A tree of spans versus a data model that's composed of x and y blocks. At the end of the day, you know, both systems still sending events, right? It's what's in them, right? And how they get put back together into a data model that's interesting and the language are on that data. Yeah, that's a lot of words. I always love updates from Facebook and Canopy. I think that you guys are doing super great and can feed into this project as far as guidance in the future, especially if there are certain kinds, not just fancy graphs, but data analysis, you can do this very tricky to do with this model. Yeah. Yeah, situations that are hard to grapple with this that are easier in Canopy. We want to understand what those are so we can improve. For what it's worth, I'd say we're also about to kick off an effort. This has to get more generalized context prop as well. Very similar observation that that should be at a lower layer, right? Other things other than tracing can ride on top of, right? You know, things like, you know, screw data sets, metrics, right? Log correlation. So I think that's sort of another place for people with conversations, right? And sort of compare design notes. You've come up with an amazing, efficient security model for baggage. Please let us know. Yeah. Yeah, baggage is fun. Great. Cool. Well, I had one other project I wanted to talk about on this meeting. So why don't we just segue into that since it's 30 minutes and then we can talk about whatever. I just wanted to give a shout out to the Java special agent project that's been kind of humming along in the background, but it's kind of reached a good stage for people to start playing around with it. So I kind of wanted to remind people of its existence and just sort of pitch it again. Just to quickly explain the idea behind special agent is it's like an agent, but really it just has one job, which is to install manual instrumentation. So rather than having the agent in sight of it have all the instrumentation bundled up and a lot of tricky ways of inserting everything, it has a more generalized model where you have a program that at boot has a jar of jars that contain all possible instrumentations. Each instrumentation has a way of basically identifying whether it could bind to something and rules for how it might get injected. And so the agent's job is just to go down that list and try to install everything. So it's sort of like, when I say it's an open source agent, I don't just mean like the code is open source, but we're hoping that it's a more extensible agent. In particular, we don't want a world where open tracing as a project is providing some kind of like agent thing for installing instrumentation. But then the instrumentation you get is somehow different than the instrumentation you would get if you manually install the plugin. So that's one, I think the reason why we're doing the extra effort to keep things decoupled is, you know, if we have a plugin for OK HTTP, just because you're instrumenting HTTP with something like an agent that installs that for you versus I installed the OK HTTP instrumentation myself from Open Tracing Contrib. Ideally, that's like the same piece of instrumentation. And if you update that manual instrumentation in Contrib, then special agent would just consume the latest version of that. So it's a way of having an agent, but still having all of the instrumentation being developed and managed by the community and by the ecosystem, rather having to centralize it all into one group that's trying to manage all of the instrumentation because it's baked into the agent. That was like the big nut we wanted to crack. And we feel like we've got something that probably works pretty well. And the final piece was the final two pieces we're working on right now are getting it to install tracers and allowing you to configure your instrumentation and your tracers. And so for, I imagine there's a number of people who are in groups that are involved with Open Tracing who already have their own agent because they work for some observability company that has an APM thing. And I imagine those people are a little less interested in the Open Tracing agent, but I would still encourage them to take a look at it, think about how they might make use of it for groups that don't have an agent and would just like their tracing client to be bundled in this thing so that if someone is running using this agent to install instrumentation for them, they can also use it to install their tracing client. I'm not sure about this agent installing other agents or how all of that would work. That sounds crazy, but that's also potentially possible if people are interested in that. So on that note, if people have questions about Special Agent, like what the point is, or where it's going, this might be a good opportunity to get some feedback on that project before it gets too far out the door. Has there been anyone using it yet in an environment like staging or production? Not quite. We're just now getting up into a place where we feel like someone could use it. What it's been able to do so far is take some amount of Java instrumentation, and if you install it, that will install it, and that seems fine. But to really get feedback, we feel like it needs to also install the tracing clients and be a little configurable before we could really get that kind of feedback of like, if you just throw this agent at your jar, do you now get traces coming out of it? So that we're just kind of launching into that. So I think in this next month, we're going to be hoping to start trying to run with it, explain to us how they're deploying things, you know, how they're, how as like from a deployment standpoint and an operational standpoint, they would want to be combining something like this agent with, with the software that they're running. Yeah. Tyler, I imagine you know way more about the ups and downs of people installing and operating agents than I do. So I would certainly love to pick your brain about this at some point. Sure. This is probably not the right place for it though. Yeah. Yeah, I'll hit you up on Gitter. I would be interested in like some opinions from vendors as to what is different about their engines versus this one. And because obviously data dog and elastic went after their own ones. And so like, is there anything that we're missing in it? Or why can't we just converge on this thing? Yeah. I guess from my perspective, I think that there's going to be some challenges around the different styles of instrumentation. So early on, I guess, when I first started looking at doing the data dog one, I kind of started around this model of of using a lot of the open tracing instrumentation and just using the agent to automatically apply it. But I guess it's a it's a different style that there's some problems that an agent runs into in terms of like having to inject things dynamically rather than being compiled with the customer's code. I don't really have any specific examples off the top of my head, but I do remember that there were some problems that I ran into. What one thing we are concerned about with this approach is we think it's a harder approach because we want to have a kind of standardized generic mechanism where someone, in addition, they write their manual plugin and then they add a file there. This used to be sort of like bite man rules, but we've actually moved away from bite man over to bite buddy, at least for Java, just for reasons. But you would add, you know, your little set of rules for how this plugin wants to be detected and wants to be installed. But, you know, run times are notoriously cranky. Agents traditionally end up with like lots and lots of special tricks and, you know, all kinds of like there's all kinds of shortcuts and special tricks and like horrible kitchen sink garbage you would never want people to see that you could stuff inside an agent if you were just doing it all. It's all one big black box. And by doing it, it's not a black box where we're saying here's the official mechanism for how it works and here's how you can plug into it. I assume that makes certain edge cases and certain forms of instrumentation like harder, honest to figure out how we're going to, you know, pull that off, basically. We've got less room to do some sleight of hand. I think the biggest trickiness around agents is around, or at least for Java, is the class path, dealing with the class path. Oh my goodness. Yeah. So, on the plus side, there's now two distinct implementations of commercial agents that you can look to to see how that's being figured out, both us and Elastic. So, yeah. Yeah. I know we've definitely been blasting at the data. For sure. That was part of what prompted us to move over to BiteBuddy from BiteMan. We were having some trouble with BiteMan and we noticed you were using BiteBuddy instead and then we were like, oh yeah, this is way better. We actually started that. So, the folks that did the very, very first POC with Datadog kind of started with the Open Tracings Java agent as a template and so they were also based off of BiteMan. And yeah, very early on we made that to BiteBuddy and it was a significant improvement in in our life. Yeah. Well, I'm going to just paste, this is in the agenda. I'm just going to paste a link to the repo in the chat so people have it. We'll probably be doing a blog post about this the next week or two. But yeah, this is just a heads up. And also just a reminder, Open Tracing is 100% focused on an abstract API and manual instrumentation and not somehow getting people glued onto any one particular vendor implementation. And so we see this special agent is the beginning of we've got this solid manual instrumentation API. How can you build the rest of like an open source open ecosystem on top of that? That's helping the community but also part of the community effort. And we see this special agent as filling that role. Installing the, I think we still have room to grow in terms of coming up with a simpler instrumentation pattern for the simpler cases, like easier APIs for manual instrumentation. There's also very clear that just installing the preexisting instrumentation gives people a huge boost, which doesn't come as a shock to anyone who writes or sells an agent. But that's the point of the project. Just can we install preexisting instrumentation for people so they don't have to. And that's my pitch on special agent. Please check out the repo. So please start poking around with it if you are interested in Java. And if you are interested in this project, you think this is a cool idea and we are interested in starting a similar special agent for other languages where this might be possible, that would be super awesome. So please contact us if you're interested in Ruby or Python or some other language in working on this project. Yeah, I would also just say about the project in general, in addition to everything that Ted has said. What am I trying to say? It would be interesting to have other vendors poking at it, I guess, sort of for mutual interest. I'm not sure how folks feel about this, but generally speaking, my impression is that smart agents are not that differentiating. I don't want LightStep to build one. It's a waste of time not to just contribute it. So this is, in some ways, for LightStep, the beginnings of an effort to improve the integration experience for anyone adopting anything related to tracing, whether it's Yeager, LightStep, or New Relic, frankly, I don't care, but it's just whether they're adopting something. And it would be interesting to hear, maybe this is not the time people are going to say it, but if people actually want to differentiate through this stuff, it's kind of surprising to me. And if this is not the right approach to do it, it would be great to hear what is the right approach. So I feel like we would all benefit anyone who's trying to implement tracing from a backend standpoint. We would benefit by making adoption a lot easier. And it would probably, we'd probably get there faster and basically kind of accelerate adoption of things like this if there was a really solid like zero touch pure open source option. And that's really what this project is attempting to accomplish is to be a lightweight layer between, you know, the application end user and all this, you know, diaspora of instrumentation. So if this approach seems totally wrong, and that's the reason people don't want to get involved with it, it would be great to hear that feedback too. We will eventually build some like this and, you know, at least that regardless, but we'd rather do it in an open in a way that's portable. So I think that will basically make it more popular and adopted by more people. Question around open census. For those that are more familiar with that, I'm not particularly, but what I know that early on, they had started their their project with a little bit of instrumentation and I actually took some insight from that when I built the datadog one. You know what their current plans are? I do have a sense. Yeah, I attached them about that because I felt like it was really tempting to throw all that into the same repo and jar or whatever as the thing itself for just, you know, verticalization reasons, but it also can get really nasty because there's a lot of software out there. And it seemed like the direction they wanted to take was, and this is, you know, I could be off, but last I spoke to them about it, I think they felt like they wanted things that were really in their mind kind of elevated to like core status be part of the main repo, like something like gRPC would be on that list. But if there is some random framework or something, I don't think that their intention was to put that into the open census main repo. And I think they wanted to take a path similar to what open tracing has done, whether they had a contrib repo or a contrib organization or not, that things that were outside of like the, you know, fully embraced core projects would not live in open census repo. What I mean though is do they have their own Java agent or something that does the automatic instrumentation? Oh, sort of. Yeah. But not, but not as much, I mean, since we're talking, you know, with you, like nothing as complete as what you've done with Datadog. Yeah. And just FYI, if you go looking around over there, they do have something called an open census agent, but it's not what you think it's not an APM, it's more like a side car or a daemon. So if you're looking in their project, that's what their agent is. Probably more like the Datadog agent. Yeah. Yeah, it's more like a... I battle that terminology every day just because Datadog started with their own agent, and then here comes the tracing that has, like, it's very common to have that terminology used as an agent too. So yeah. They've also got the open census... Sorry, go ahead, Austin. Yeah. I was going to say the open census service is the thing that kind of corresponds more to the Datadog agent, I think. Yeah. Yeah. They've got a service and an agent. That part I haven't fully kept track of. The agent is a side car or some sort of host-based proxy, and then the service is an aggregator. But I think the agent also does some host metric stuff. So it's all very confusing. I do think the long-term plan in open tracing, and I believe it was for open census, was the way to have automatically installed instrumentation would be if this could reach a point of standard, being standard and stable, that people would start natively instrumenting their libraries with something like open tracing. So you would need something like special agent to install software, but it would only be the things that didn't have native instrumentation. And so if you're looking at big core projects, the goal for those core projects would be to convince them to just come with instrumentation pre-baked so that they can, so that the people writing the software are the people thinking about tracing it. They're the people thinking about shipping you a playbook explaining, you know, what does it mean when you see these values show up as tags in your trace, like what should you do about that? I would really, as like the next stage of this project, I would love to see convincing people who ship libraries and frameworks to like really think about their end users having to operate their software and thinking about how they're going to ship them playbooks and assist them in understanding how to operate their software. And that if we can get people into that mindset, then stuff like this tracing API will seem a lot more useful to them. So I hope you get there. So I guess going back to my question around OpenCensus, I think they originally started out with ByteBuddy and that was one of the reasons that inspired me to explore ByteBuddy as well. So that might be worth considering like since we're talking about kind of merging in a per se the projects to a degree, maybe this could be a good starting point to kind of work closer together with them on a particular project rather than trying to build it separately. Good point. I will make a note to reach out to them. Yeah. And that way it can be like a point of collaboration that isn't so separate, I guess. I mean they've obviously got a lot of expertise in this area too. So one thing I do like about building these more advanced these kinds of value on top of the standards that feels good is like we all have to agree on the standards and that has to move very slow. And I would like us all to pile in and make something like Special Agent great. But one thing I do think that is nice is if once you're building on top of that platform it becomes like less important. Like that's the realm where you know there can be multiple projects. There can be multiple stabs at something. There can be multiple opinions up there. And so there's more room at that layer. And so for my mind it's like keeping things out of core is actually to Ben's point around trying to shove the agents and everything down into core. I've been like opposed to that in this project because I want to keep that core part where we have to really hash it out and all agree like as small as possible. Which doesn't mean I don't want OpenCensus involved in this project. I actually do because I think they're small. Yeah I'm not suggesting that you architect it like them. I'm just saying that they would probably be good collaborators. I do think they were hoping to bake every version of Spring into OpenCensus at one point and we were like I don't think that's going to work. All right well that's all I got on Special Agent and all I got on OpenCensus. And do we have a or just like some housekeeping stuff about the registry? Yeah. Yeah just so I don't know if everyone pays attention to all the minute of the OpenTracing repos but last month we I took everything so there had been this OpenCensus meta repo that had just a huge list of tracers and plugins and instrumentation and whatnot. So I went through last month for the ones that weren't already in the OpenTracing registry which is at opentracing.io slash registry. I made entries for those and put them there so that includes all like the data dog agents and stuff like that. And so now the meta repo is just kind of a pointer to the website. So if you have internal links or if you go looking for something and it's not there that's why it's all migrated to the registry. And just as a general note if you have instrumentation plugins, tracers, libraries, other open tracing related things that you would like to put into the registry please feel free to make a pull request on opentracing.io repo or you can ask me for help if you need it. I'm on Gitter. And yeah we've had a lot of really good growth of the registry over the past. And how long has it been now? Three months, four months. Last time I counted it we're up to like 140 odd pieces of flare in there. And yeah it's nice. People seem to like it. Yeah. I would do a quick shout out. You know that I'm super stoked about the registry. There's plenty of front-end work that could still be done on it. Things like searching and filtering and all of that jazz could just use some elbow grease. So if people have front-end skills and are looking for you know a way to show some open tracing love, working on the registry interface is definitely a place people can plug in. Yeah I think there might actually be some issues open in the repo for counter-desire for stuff that we wanted to do and didn't have a chance to but I might go through and add some if there isn't. So that was all I had about the registry in the meta. Well I don't actually see where the backing GitHub repo for that is. You link to the meta but that seems to be mostly empty. It's just it's the opentracing.io repo. Yeah okay the registry all the registry is it's you add a markdown file to one of the content directories and it shows up. It gets indexed or it gets turned in. Yeah it gets converted when we build the site. There's more explicit instructions on the web page too about exactly where you need to put the markdown file. And there's no like back-end database or anything. Right it's a fun little Hugo feature that lets you make JSON out of arbitrary documents. Another thing for people to maybe think about there's no API or anything. We just have like a Hugo site but or sorry yes Hugo site but if people do have thoughts about how the registry could be like actually useful as part of operations in some way if there would be some way to make it useful if it had an API of some kind that you could query that would be interesting thoughts. We haven't put too much thought into people doing anything with it other than you know looking through it on the website but I imagine there's other ways this could potentially be useful. Yeah technically you can there's an endpoint you can curl to get the JSON that makes up that registry back or back-end so if you really wanted to you could do something with it but you know pit me up on Gitter if you want to if anyone's on the call and wants to talk about it and would love to chat more about registry stuff. All right I think we're coming to a close final comments questions before we get out of here well it's good seeing you all I'll see you all on the Gitters and yeah new name we need a name everyone dream one up happy Friday happy Friday everyone