 Hi, I'm Sanj. I'll be talking on bug you. That's a project I've been working on for last few months and it basically reports message from our infrastructure Fedra message, that's the Fedra infrastructure message bus. So who am I? I work as a senior software engineer with the Fedra infrastructure team and that's my Twitter handle, GitHub and my email ID. So before moving to bug you, I'd like to like emphasize on what is Fed message because it's completely built on top of Fed message. So Fed message is a Python package that is built on top of ZMQ, Z0MQ. So it is used within the infrastructure to receive and publish message across different applications. So all the applications within the Fedra infrastructure basically communicates with using this Fed message, Fedra infrastructure message bus. So this is kind of old picture but this gives an overview of what happens inside the Fed message. So we have all the different applications pushing messages to the Fed message bus. It uses a public subscribe model of the Fed message and then we have a list of different applications that uses this messages to do various operations. So suppose if you know of data gripper, so whenever Fed message pushes any message to Fed message, so data gripper listens to all the messages and stores. So it provides a JSON API so that you can fetch all the messages and do any analytics over that. So this message bus is publicly subscribeable so you can subscribe, listen messages and build applications on top of it but you cannot push messages to it. So we have a flat file of which applications can actually push messages to the message bus but you can actually subscribe to it and consume messages. So now that you have some kind of an idea of what actually Fed message is, so we can now move over to Buggy. So yeah, so Buggy is a service that is built on top of Fed message and it listens to all the messages from Fed message and it is a combination of different plugins and those plugins are actually doing the job of pushing, creating issues in different issue tracking services like GitHub, Pegior, we are thinking to implement track, Bugsy, etc. So what was the motivation? So around last day in October we were building a project called AutoCloud which does automatic testing of cloud images. So we have like a nightly compose that runs every day. So AutoCloud basically each compose sends a message that there has been a compose build. So AutoCloud basically listens to that particular message and it tries to test that particular image. Now the problem was that like even though tests were getting failed so AutoCloud does not have a notification system of its own. So it was very difficult to know when the test was failed and which are test failed and if suppose you lose track for two or three days, so if that test passed or not. So that's when we came with this idea that we should actually build a Fed message, kind of a Fed message issue tracking tool so that actually we can create issues using this. So initially we only had Buggy listen to AutoCloud messages and create issues into Pegior. But later down the line we thought this should be a generic application so that more and more plugins should can be added in the future. So like Buggy is divided into five parts, mainly five parts and this is the basic flow of Buggy. So Buggy has Buggy consumer then it has a plugin queue then it has different plugins that is called the Buggy plugins and then we have Buggy services and finally the Buggy controller. So I'll go through each of this. So first the Buggy consumer. So in the beginning in the starting you can see the Buggy consumer the Fed message is listening to Fed message and consuming all the messages and then it's what it does is that it consumes the messages and then does a filtering on it. So we have a message filter. So it actually checks which all plugins are actually registered to Buggy and based on that so each plugin has so each of the plugin has its own topic filter and so that consumer actually checks is that particular topic is matching the message topic or not and if it's not matching it simply discuss that message and if it's matching then it sends that particular message to the plugin queue. So each of the plugin has its own plugin queue which is there in redis and whenever there is a new message so after the message passes through the message filter it sends that particular message to each of the plugin queue and it does not do any modification to the message it simply passes that message to the message queue plugin queue and then we have our this complete Buggy plugin. So these are different plugins that we have for now we have just have the autocloth plugin migrated to this complete new structure. So each plugin has its own plugin queue. So what it does is that it listens to its own plugin queue and whenever there is a new message it takes that particular message and starts processing it. So whenever it receives a message so we have concept of services. So services are basically like the different issue tracking tools that we have. So suppose there is a Paneo service, GitHub service, track service, bugzilla service. So we have methods like do peggio, do github, do bugzilla etc. So whenever you are writing a new plugin you need to overwrite that particular method and it basically the main plugin what it does is sends to all of the different services method. So suppose you need to handle different message separately. So suppose in peggio you need to have a different title in github you need to add more information regarding that issue. So you can have different logic implemented in that particular method. So this autocloth plugin basically does that particular job and next we have the buggy services. So what we did was that we built an API on top of all the services like the peggio or github. GitHub is on progress. So basically this idea came from me when I was working on Libcloud and it had something like provider. So you change the provider the API kind of the same but you just need to like change the provider and the methods are just the same. So I try to implement the same thing that you just change the provider and you can use that particular method as it is. So like inside the peggio, do peggio, do github methods you can actually use those API and interact with your issue tracking services and then using this peggio service you can push to peggio or github service you can push to github. So this is kind of the flow which the message goes through and finally the message are created in peggio. So the thing was that like now that autocloth has this complete feature. So since the issues are in public, so the issues can be directly like if you watch the particular repo. So you get notifications and whenever there is a comment. So there is an option that if that issue is already created so it directly creates another comment that this failed again or this message had been issued earlier. So the admins can actually see like if it has been failing for like two, three days so actions can be taken. Or since the issues are public, so new contributors or people who are managing it can actually comment over there directly and see why this is failing and why things are going wrong. So this is why so this was another reason why we built buggy for that. So the main thing that we have is the buggy controller which actually kicks in the complete process. So the fed message consumer is actually started by a fed message demon that we have is known as the fed message hub which actually kicks the process for consuming all the messages. But then this autocloth buggy plugin stuff which is a separate repository we have with list of all the plugins. This actually escaped by this buggy controller demon we have written. So what it does is that whenever you start this particular service so it pushes all the plugins registered to the an instruction queue and this message filter the buggy consumer actually keeps listening to this instruction queue and whenever there is a new message there is a bunch of new plugins that have came. So it updates its filter so the next time when the filter the messages are coming so it can actually check those new plugins and push the message accordingly. So one thing another benefit of having this was that even though you have to like whenever you are updating your plugins directory so you can directly shut this off but your queue will so this will not get shut down so it will keep pushing to your plugin queue and whenever the message when the this buggy controller kicks in so it will again start consuming the messages. So to add new buggy plugins you so there is a clg file we have so it has it lists all the services you need to activate so suppose you need to access peg your github add or track so it's comma separated so services use to peg your comma github comma track and then you have the topics which you need to listen to so it's these are the famous topics you need to listen so these are currently comma separated and within the clg file but I am planning to move it to the plugin source code itself so that you don't need to maintain a separate clg file for this and then we have this services so basically so to communicate with different issue tracking you generally need to create a new app application and have access token to it so there is a clg file for buggy services where you need to name the auto the plugin name underscore the service name and you can write all the repo name all the access token and the peg your the buggy services which actually internally handle this use this particular configuration and handle it's in its code itself so I'll go through the quick walkthrough so that you can see like like this is the buggy consumer main consumer code so if you see every fed message is inherited by the fed message consumer so each fed message consumer has a topic which you listen to so here I am listening to all the topics so that I can in the later step I can actually do all the filtering and then we have this in this line that topic itself dot serve topic that if this particular this is basically a filtering process where the messages are getting filtered and then we have a list of all the plugins it sends the message to so it includes all the messages to different plugins and and so this is the auto cloud plugin so this is within the buggy plugins that we report that we maintain so this is sample code lot of code has been truncated because I could not take a screenshot and show it in the same slide so this is sample it mostly contains all the things so we have the plugin name in the top which which is actually used to get the data from the services configuration file and then we have a process file which actually sends to all the services and then here the method is do figure that actually uses the uses those per year per year services and sends creates all the issues into per year so so this is the basic this is not a very big project and relatively very new project so we have been building on it and so are like in the future we are planning to like add get a like github is in progress track bugzilla and so if you have any ideas like you can suggest so this is kind of the end of the talk these are the links which I can go through like the buggy read buggy read the docs is like it's not the latest one the latest doc is not pushed yet but because the current work is still in staging so we need to push it to production so that we can make it to the latest documentation and the source code are like buggy which contains the consumer part and the buggy plugins which contains all the list of plugins and one more thing is that to separate the services buggy services out of buggy plugins right now it's inside the buggy plugins repo so we can directly move out of buggy plugins and provide us a separate api so that people who are not using buggy plugins can also use that buggy services thing and finally fed message uh fed message really good project so if you want to go through that's the link documentation uh I think that was the quickest in the one that's not bad that's a good comfort to review yeah okay so so now you're you're starting with figure yeah right so is there any way and then you're going to build out a sort of a framework now for everyone to just be able to subscribe their service via the plugins yeah so uh whenever you need to add a plugin so suppose you want to suppose koji wants to interact with any figure or github services so they directly write a plugin for it and the plugins structure is the same it should have a like a do figure or do github method and it will do all the process on its own yeah so uh this is kind of like uh still in very near state and I'm still it was like starting in the starting I build it for autocloud typically buggy was built for autocloud then it was to separate the complete thing so that people can reuse so so that it can be used in the future yeah so uh let me show you yeah so the thing was that like uh autocloud also took a major change so we worked on it like from april to june itself I was working on that autocloud thing completely so uh maybe I should mirror the screen so this is the thing the autocloud project that we have so each day you have the bills and then if you go to the results so this is related to each of the images that are tested so this is yesterday or today yeah so today one thing failed so you can directly visit the output yeah we worked on it it's completely new yeah the thing was like whenever the test fails autocloud does not have a notification of its own so we worked on buggyu and so that we can we have a depot which is kind of outdated now because the api so it feels uh so it's clear messages like this that uh a cloud background based background image field so yeah so then if you've got something one you want more specific after you in your tree office you can just fix the yeah right by description and that yeah but you got everything that was recorded from the from the test yeah so this one actually is a bug into need this one so so you know exactly which test fail yeah yeah and then uh I guess there's a page night yeah so this actually queries the autocloud to get the messages and you can have all the latest details about yeah this is actually Adams Adams person so he has done a redirect yeah yeah why what did you this code is is inspired by status right but you were not really a status uh no so uh status like uh uh yeah the code is inspired by status cast but uh this has this uh services thing right so services thing cannot be integrated at that point of time we did not integrate stats like status is basically built to like do all the antique stuff and give a nice dashboard like which all things failed and beautiful graphs but and this is a completely different issue because we here we are dealing with bugs and issue tracking system so we kept status cast and so we have a different uh project called status cast which actually is also uh fed message consumer built on top of fed message and it does all the analytics stuff for us so not this is not a basically so what you should do is that we should have script that needs to hold the record and very soon too much huge amount of rights happening yeah what it is that like will keep the data really uh be normalized and part of uh very original so there's a plugin that allows you to listen to the library and keeps on generating capital analytics on top of that so that that data is uh always updated and it is read really fast so we can easily use it for chatting and all yeah so so we have the uh I think we can have so we can have the because status and buggy has a lot of common patterns right basically the how do you extend plugins and all we can have that in the common library so that that uh logic of processing fed message message would be common yeah so that's why like uh pingu last day told about that uh that python plugin right so python plugin yeah there's a package to manage plugins so maybe we can leverage that too yeah in that case also we have a stat status plugin directory and repo and we do the same thing like almost same almost same thing yeah yeah but you're but you got it it's why the different yeah purpose yeah it's like your goals yeah okay maybe I should turn off this