search

litaio / lita

ChatOps for Ruby.
https://www.lita.io
MIT License
1.68k stars 179 forks source link

Lita bot status #221

Closed sumanthkulkarni13 closed 4 years ago

sumanthkulkarni13 commented 4 years ago

Is Lita still under active development? Does the community still use and continue to support Lita?

jimmycuadra commented 4 years ago

Lita is stable and hasn't needed any active work for a while. There are still many people and organizations that use it!

sumanthkulkarni13 commented 4 years ago

Thanks @jimmycuadra, another question - do we have a working redundancy solution built into lita-bot?

jimmycuadra commented 4 years ago

Redundancy for what?

sumanthkulkarni13 commented 4 years ago

For availability of litabot, I'm exploring options to run a cluster of litabot do minimize downtime, outage etc.,

dpritchett commented 4 years ago

I've never tried to run a multinode lita setup but we do run a single node on a Kubernetes cluster at work (EKS) and it's stayed up pretty well thus far (better part of 1 year, a few dozen users).

If you're really focused on high availability you might want to consider a multi-tier approach where the chatbot isn't the alpha and omega of user interaction.

Alternately you could separate out your Lita bot's handler implementations so that all of the captured user "intents" (aka lita's chat routes) were sent off to an external message queue and then the handler code can run on a ticker that pulls intents off of the queue and executes and responds appropriately.

A redis-backed queue provides the beginnings of a simple semaphore for preventing redundant event handlings. If you need guaranteed-once delivery you'll want to look further than Redis though.

Here's a rudimentary example from one of the libraries I put together for my Lita book: https://github.com/dpritchett/lita-task-scheduler/blob/master/lib/lita/handlers/task_scheduler.rb#L124

On Thu, Jan 2, 2020 at 6:09 AM sumanthkulkarni13 notifications@github.com wrote:

For availability of litabot, I'm exploring options to run a cluster of litabot do minimize downtime, outage etc.,

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/litaio/lita/issues/221?email_source=notifications&email_token=AABEEDNVUXGBHCQMX2KFVO3Q3XKO3A5CNFSM4KBTESHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH6GR5Q#issuecomment-570190070, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABEEDLGH7U7GJ6IWHI3E7TQ3XKO3ANCNFSM4KBTESHA .

--

Daniel Pritchett

📨 daniel@dpritchett.net |📱 901-871-0139 | ✍🏻 dpritchett.net | 🐦 @dpritchett https://dpritchett.net/

🤖 Author of Build Chatbot Interactions https://pragprog.com/book/dpchat/build-chatbot-interactions

👨🏻‍🏫 Continuing Education Lead for #VetsWhoCode https://vetswhocode.io/

💥 Infrastructure Engineer for Gremlin https://www.gremlin.com/

sumanthkulkarni13 commented 4 years ago

Thanks a lot @dpritchett, this helps...

jimmycuadra commented 4 years ago

I would emphasize the idea of keeping Lita itself from being a critical component. Important business logic should live elsewhere, and Lita should simply be a chat-based interface for triggering those operations. If you're familiar with Ruby on Rails-style MVC, think of Lita as the controller layer. Its job is to take incoming messages from chat, extract the meaningful data from them, and call external APIs, and return a response based on the response of the external API. That way if Lita is ever down, it doesn't prevent you from accessing your services completely—it just limits your ability to trigger them via a chat interface.