Release#4(2)-Road.

I’m working on the integration between Telescope and Telescope’s slack channel.

The goal is to monitor our servers, and if something is wrong with them, a message is sent to our slack channel. David Humphrey indicated to me the auto-deployment server to implement the bot.

Follow a picture to illustrate how one of the bot features should work:

Part one — Hello, Einstein.

So my first step was to jump into some research about how slack bots operate; it was a pretty good journey. YouTube tutorials, Slack documentation, node community articles; But Slack upgraded their bots, so what we use to call a bot now is called “Legacy bot”. And at this moment, we can’t create a legacy bot anymore(not sure if it’s related to my slack account or not). Then I made a Slack App with permission to write into channels and receive commands from the user.

I present you EinsteinBot:

He is a simple man, but I could test the basic structure to build a slack bot app with him. Yes, I coded Einstein on 20.11.2020 at 4:31 AM and, yes I like the idea of a bot have a name and an image cart. With Einstein, I could test user interactions and direct messages into the channel.

I forgot to mention that I had read about Bolt.js and some npm tools to manage slack APIs, but I decided to write it just using Node.js. Einstein is controlled by a NodeJs server(requests and responses). So Einstein has two commands. He says “hey” followed by the username of who sent the command; the second one is time. I’m using a free and straightforward time API, so when the user sends the command, Einstein's server uses this API to fetch the current time and send it to Einstein that writes it on the slack channel.

Part two — A zoom on Telescope Architecture.

After testing the basics of what the Slack app should do, it was time to understand the Telescope’s architecture better. So I contact Josue Quilon, who gave me many directions on how Telescope is built on the CDOT machine.

After gathering information, it was time to start the coding. A code running inside the auto-deployment server performs a fetch to check if Telescope’s backend is working every 5 secs. I knew that It wasn't the best approach, but at this time, I needed to deliver some code and ideas to be discussed. So I sent a PR.

I present to you the first Telescope_Bot working on a slack test workspace:

Every time our back end is not working, the node server sends a message to the target channel. This is not the user interaction like we saw in Einstein. I decided to start developing the direct message first because I believe that is the feature that we need more.

Once it is finished, it will be named Telescope_Bot? I hope no. I already have the name(s?). But let’s wait to name it later(no spoiler).

Part Three — Let’s talk(again).

After the review of my PR, everything changed. With David and Josue’s feedback, some options appeared.

Let’s go back and talk with Josue Quilon again; we discussed many ideas like should we use a cron? Should we use pm2? Should we listen to docker events?

So I had noticed on the auto-deployment server an npm package called ShellJs, a “Portable Unix shell commands for Node.js” and this thing was knocking on my head.

For me would be crazy; for him, easy.

So at this time, Josue Quilon already taught me how to use PM2 and play inside a Docker container. David Humphrey had mentioned docker events, so we were playing around with it too.

So for now, I had to figure out which events I need to listen to; a little bit of research and I found this chart on stack overflow:

Docker Events

Yes, my friends, if we can communicate in the right way, the ideas are polished.

Part four — Hello Bash, I miss you.

So I decided to go with the Bash Script approach. There had been a while that I didn’t code in Bash. Hundreds of opens tabs…

The right line would be: “I remembered how to code in Bash.”

After writing the bash scripts, I learned how to use ShellJs to run them inside a Node App.

But let’s pause for a moment and remember something: Everything started with a slack bot idea, and then I had to learn about PM2, docker-events, bolt.js. And I’m using just Node and Docker Events. So don’t ever think it’s just a bot unless you already know the path; because I was researching, learning and choosing the best way to do it simultaneously.

Part five — Dear Node…

Two weeks ago, I changed the way I see Node. Node is so powerful. We could launch a spaceship to the moon using Node(Don’t get surprised if David Humphrey sent some links to our slack channel about a project like this). The Node community is so amazing. The packages that you find on npm are so good. And if you don’t want to use them, okay, you have Node where you can write your own program in JS and run it in every place with Node installed.

So I always want to try to use node events, and guess what? I think that was the right time to do it. So now we have a node app running bash and managing the flow control using events.

Whenever a docker container stop/paused/crash and restart/start again, we will be notified on our slack channel. It’s still missing a lot of details, but I think the structure is done.

So I pushed this proposal for review. If it gets approved, I will continue to implement the feature.

I’m grateful for all the attention and support that I received from David Humphrey and Josue Quilon. And I’m happy to be learning new things every day.

Post soundtrack: Rival Consoles-Persona (Full Album)