Proposal: Move away from JS-based st2chatops #8
Comments
|
I would throw out there that I might desire to see discussion around the js client and how to automate builds of it. Keeping that around would be a benefit for the front end, right? |
|
@blag Given the current constraint on resource and that the team is mostly python centric, let's go for it if this will continue to push the chatops feature forward in st2. I like to see RBAC, inquiries integration, and conversation/thread support in chatops. The only concerns here is the license scheme for these projects. As for @punkrokk feedback, let's delegate that to the st2web/st2flow UI discussion. I could be wrong but I don't think st2chatops, hubot-stackstorm and st2web are sharing the st2 client (at least from reviewing their package.json files). |
|
I'm in support of this! Also concerned about GPL with ErrBot as @m4dcoder said. Would love to get more python centric and make it easier to add new features to the bot framework! |
|
I think I wasn't fan of changing the chatops engine before as I'd care about full backwards-compatibility for existing ChatOps users and consequences when switching to the new platform. For years we built user experience around hubot that's stable enough and some of our users might tightly integrate with that. I also believe that Hubot community is overall more rich and popular comparing to others. I don't think there is a problem with how st2chops dependencies designed or work or if there is a problem with code duplication or sharing. For example, I don't see how https://github.com/nzlosh/err-stackstorm re-uses StackStorm python st2client code. It re-implements ST2 API consumption as well, same as current st2chatops + st2client.js does. The root problem here is that we don't have anyone who could drive the javascript-based Hubot st2chatops development (previously it was @emedvedev). That's the only real issue. Another important part is migration path for the users and potential consequences. Would it be possible to switch the platform with little to no bad impact or incompatibility, how would the new thing fit the current st2 picture, how much work is required for that and how that diff might look like for our community eventually? If switching the ChatOps wheels which already means making high stakes, I'd try to take all the best we can with the next-gen OpsDroid and NPL/NLU extensions blag was mentioning on top of what we already have in chatops syntax. After all, in 2020 you expect more from bots. |
|
I don't know the exact concerns @nmaludy and @m4dcoder have in regard to the GPL3 licence but I'll Disclaimer: I'm not a lawyer, this is my own understanding of how the GPL3 licencing applies. The two key issues identified were: Bundling errbot in chatops packageWill distrubuting GPL3 licenced software in the same package as non-GPL3 licenced software risk Bundling differently licenced software doesn't require them to accord their licences with each other.
errbot GPL3 licence transitivity on non-GPL3 errbot pluginsAccording to https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins the GPL3 considers errbot plugins to be "combined work". Despite this clause, the errbot project has explicitly included an exception to allow plugins, scripts and addons not bundled with errbot to use any licence they want. It is our opinion that this constitutes intent on the part of the errbot authors to allow plugins to not be considered "combined work" and would not be required to have the GPL3 licence imposed. Errbot's explicit allowance of non-GPL3 lincenceshttps://github.com/errbotio/errbot/blob/master/gplv3-exceptions.txt
To address the point @armab raised around err-stackstorm's lack of use of st2client, I'll explain why: err-stackstorm did use st2client for many years until st2client pinning the As a StackStorm user I have always considered the requirement of installing/maintaining nodejs with StackStorm abberant. Being able to debug issues, contribute patches and understand how StackStorm functions is important to me. Context switching between Python and Javascript is inefficient when not working with both languages on a regular basis. Keeping focused and reducing maintenance effort by using Python only is what err-stackstorm was about for me. I agree that the user experience will be impacted in transitioning away from hubot. This impact would be less significant than switching away from Mistral to Orquesta. Action-Aliases would remain unchanged, the only users that would be significantly impacted are those that wrote their own hubot plugins. It wouldn't be too difficult to provide both hubot and python-based bot packages during a transition period to ease user migration pain. Letting users decide which bot to use until hubot was phased out. |
|
I would like to see us move to a chat platform that allows for more interactive bot usage such as drop down or calendar selectors, text/numeric input fields, etc. Consider these slack features: https://api.slack.com/block-kit/interactivity. I was able to inject some parts by using Do ErrBot or OpsDroid offer more advanced interactivity/interface options? |
|
Glancing through the ErrBot docs, I see a "cards" feature that allows for using Slack's attachments (like with hubot), but not something for more interactive inquiries. edit to add relevant issue links issues related to getting this with errbot: Oh, and I filed this awhile back. Hmm. looks like I need to respond... This issue only addresses adding support for blocks which is a pre-requisite to interactivity. But, interactive prompts would still be beyond hubot to support. |
|
It looks like OpsDroid supports slack's interactive Blocks: https://docs.opsdroid.dev/en/stable/connectors/slack.html#interactive-actions So, unless ErrBot supports Plus the possibility of using NLP would be awesome! |
|
Errbot's cards are not intended for interactive inquiries. Errbot has the notion of flows https://errbot.readthedocs.io/en/latest/user_guide/flow_development/concepts.html which may be able to provide interactive actions without being tightly bound to Slack. While I think it'd be great to have more interactivity between the chat backend and StackStorm, I'm not a fan of tightly binding StackStorm functionality to Slacks feature set. I think there's room to review how chatops is done in StackStorm but drop down or calendar selectors, text/numeric input fields, etc. aren't bot features, they're chat backend features. Currently Errbot doesn't have Slack blocks support. Errbot was built with the philosophy that when the bot provided a feature it should be available and behave the same way regardless of chat backend. This allows the same bot behaviour to be maintained between, xmpp, slack, mattermost, rocketchat, gitter, and discord. This can be seen in the templating support https://errbot.readthedocs.io/en/latest/user_guide/plugin_development/messaging.html#templating that will emulate tables on backends that don't natively support them. (the formatting can be ugly but it works). |
|
Re: supporting MS Teams in OpsDroid - The OpsDroid folks seem open to a PR to add support for it. One person started trying to add support using the BotFramework but found that BotFramework and OpsDroid conflicted (surprise surprise). So, if this is something we would need to tackle, then the OpsDroid connector for Teams will need to use the underlying APIs (instead of BotFramework) described here: edit: |
Makes sense. Is there similar interactivity in other chat platforms? If there's something similar maybe we can find a good abstraction to enable more interactive inquiries via chatops. Then again, maybe a new chatops sensor could allow for more interactive flows in some platforms? The interactions are just "events". |
|
One of my issues is that I have designated a slack channel for a particular st2 workflow, but specifying the input parameters is unwieldy because it requires the Tier 1 Tech Support person type the (case sensitive) target customer's name. It would be so much nicer to run some action alias and then have an inquiry where the options are presented in a drop down. For other chat platforms, that could be done by sending a message (an ephemeral message for platforms that support that) with a list of the valid options that the user could copy/paste. If we could use ErrBot Flows to achieve that interactivity that would be cool, and then maybe the slack adapter could convert that into slack native action blocks where it makes sense. |
|
Quick comparison based on these docs (plus some googling):
|
|
I am observing MSTeams gaining significant market traction, in two ways: vs Slack and vs. Zoom. FWIW |
|
These platforms have some kind of interactivity (menus seems unique to slack and mattermost, buttons is more common, teams and facebook allow iframes to load just about anything):
An interesting survey from Rocket.Chat on what platforms have interactive components as they look to add the common interactive components: These platforms would require textual replacements for any interactive components:
Dead platforms:
|
|
The biggest roadblock with supporting MS Teams (at least when I looked into it) is that they only support webhooks for delivering messages to your bot, meaning that our users would have to open up a hole in their firewall, or do some networking magic, to securely use ChatOps with Teams. Literally every other chat provider that I'm aware of supports message delivery over websockets. I was not impressed with the MS Teams developer experience. They seem very top-down managed, and I don't think that interfaces well with how we do ChatOps. We support a bottom-up approach to ChatOps, since we let our users define their own custom ChatOps aliases/commands, as limited as they may be. And that's not something that I've really seen anybody else try to support. MS Teams ChatOps seems to be based around an app market where "send all of your chat data to this third party to enable them to work their own natural language processing magic" is the normal way of things. So when I was looking into it, MS Teams didn't integrate well. Due to that, and the fact that our current adapter is incredibly limited and just barely supported to begin with, I don't really care if we lose integration with MS Teams when we switch over to something else. I don't think we can reasonably consider it well supported by us at this point anyway. It is "officially supported", but it's not "well supported". |
@punkrokk No, I don't think it's worth it to automate that release workflow, for a few reasons:
|
|
I would also point out that MS Teams might be growing their userbase, but Slack and Webex already have large userbases, so comparing growth rates may not a valid approach when considering this. |
|
Regarding chat provider support, it looks like for the five that we actively care about:
All of those are more-or-less supported to the same extent by hubot, Errbot, and Opsdroid. All of the other chat providers are nice to have, but shouldn't sway us in one direction or the other. |
|
Regarding feature support, particularly support for rich or interactive cards or whatever, we will still have to build support for that into our adapter no matter what, as hubot-stackstorm does not explicitly support that yet either. |
Yes. And getting support into hubot is a much bigger reach than in Errbot and OpsDroid. Once we've switched to another chat framework, the development effort in the st2chatops layer should decrease compared to adding the same feature with Hubot. As far as features go that st2chatops uses and needs right now, a key feature in st2-hubot is keeping the list of aliases up-to-date. What err-stackstorm does is nicer in this regard as it doesn't have to poll ST2. Here is a brief comparison of implementations (or possible implementations for OpsDroid):
For the NLP/AI features of OpsDroid to make a difference we have to be able to pass our action-alias formats into OpsDroid somehow so that it can run relevant matchers. Maybe we could do something like this gist to pass all of the st2 action alias formats into OpsDroid. Continuing that line of thought, with both err-stackstorm and OpsDroid, it would be interesting to move some part (all?) of the action-alias recognition into the bot itself to reduce complexity. edit: to add additional links about OpsDroid as I find them
|
|
As I understand things, @Kami wanted to keep ChatOps logic in the st2 core so that bots could be kept as simple as possible (StackStorm/st2#3770 (comment)). This was the reason err-stackstorm uses the st2 api as much as possible without having a lot of decisional processing happening bot side. This is great for keeping StackStorm ChatOps features bot agnostic as much as possible but I think it comes at the cost of stifling ChatOps rate of evolution because the bar for entry to the St2 core is high. The only exception to the rule is err-stackstorm's chatops authentication mechanism that was developed to allow chat users to authenticate with their StackStorm credentials to run action-alias as an actual st2 user and not as the bot. (https://err-stackstorm.readthedocs.io/en/latest/authn.html#authentication) Errbot also comes with native ACL support. Opsdroid doesn't appear to have this functionality. If I remember correctly, hubot has a plugin to add acl support. Errbot's ACL features allows fine control over which user can execute which command in which channel. https://err-stackstorm.readthedocs.io/en/latest/authz.html#errbot-access-control-list I haven't seen a lot of demand for NLP in the Slack community channels and while errbot doesn't offer this out of the box, errbot does have command filters (https://errbot.readthedocs.io/en/latest/user_guide/administration.html?highlight=filter#command-filters) that are developed as plugins. The effort to add NLP support to errbot would be as trivial as adding a pack to StackStorm IMO. |
|
One of the old-era ChatOps limitations behind Hubot, - it's not possible to run it in HA mode. It's one of the features I'm also looking for when considering new platforms. There is a K8s Helm chart for OpsDroid (https://github.com/opsdroid/helm-chart) however it relies only on I'll keep the research going, but if anyone has more context about HA capabilities/workarounds/potential around Errbot and OpsDroid, - please share your findings. |
|
I asked the question in ealry 2019 around HA in errbot community and there were a few suggests (more or less what opsdroid's done for HA). Unfortunately, I didn't file an issue on github :
|
|
So far, in the matrix chat for opsdroid, the consensus is that connectors (things that connect with websockets to the chat services) make the HA story difficult. Once the message is received, it would be fairly simple to introduce HA for skills:
edit: add this OpsDroid response
|
|
An interesting post from lyft on Slack and HA:
https://eng.lyft.com/announcing-omnibot-a-slack-proxy-and-slack-bot-framework-d4e32dd85ee4 Lyft's solution for HA with Slack (yeah - slack only So with errbot or OpsDroid or whatever, the piece that connects with the chat service would need to say whether or not it supports HA and implement the HA connection to the chat service in whatever idiosyncratic method is required for that service. |
|
What is the technical limitation to realizing HA? Is this something that could be resolved with Network hot-cold, service-discovery or anything like that? Is it just a core design decision of all the different options? |
|
I'm not convinced that a ChatOps user survey would generate much actionable information for us when deciding on this particular proposal. Previous user surveys have largely focused on what features users would like to see, and this proposal is focused on what should be considered an implementation detail for our users. As such, I don't think it would be highly useful of us to create a ChatOps user survey to ask our users if/how they want ChatOps reimplemented. And if we're going to ask them about what features they would like to see, we already have the answer from the previous user survey: the most highly requested feature is RBAC for ChatOps 1. Other feature requests are support for inquiries 2 and conversation/thread support 3. So for this proposal, we should investigate whether any proposed alternatives can reasonably support the current features of hubot-stackstorm, and whether any of them can reasonably be extended to support those additional three features. Any and all other feature requests beyond what hubot-stackstorm currently supports are outside the scope of this discussion for now, in my opinion. The bulk of my proposal boils down to two points:
All other considerations - wider support for chat providers, improved support for user interactivity, etc. are all orthogonal to this proposal. One additional concern that I haven't yet addressed is our users who package their own ChatOps bots and use hubot-stackstorm directly. Even if we adopt my proposal to switch 100% to a Python-based bot framework, the existing st2client.js, hubot-stackstorm, and st2chatops repositories will remain open source. I believe that we can end further development of them immediately and put those projects into "maintenance mode", where we only accept bugfix pull requests. Those users can then switch to our new ChatOps functionality (whatever that is) when they reach end-of-support status, or they can fork and continue development themselves. 1 I have proposed a mechanism for ChatOps RBAC based on the implementation in err-stackstorm, but the decision was to use something more aligned with configuration-as-code and more tightly integrated with the RBAC plugin. ChatOps RBAC really boils down to ChatOps authentication + extending StackStorm's RBAC backend to handle ChatOps-specific roles for the chat user. ChatOps RBAC without ST2 RBAC would be exceptionally difficult to implement, so this feature would be restricted to EWC customers only. |
|
I don't think we decided yet whether we'll rely on old hubot-stackstorm, full-feature ErrBot or next-gen OpsDroid. If we make big decision like changing the engine behind the chatops framework I think it's best to have a better picture about the current chatops community. Who they are, how they actually consume chatops, what is the functionality they rely on, what are the blockers and biggest pain points in their adoption, what's missing, what they need, gather random ideas, opinions and so on. This will also generate more traffic and points of view in this thread. Every User Survey brings some surprising data we never thought of. I'm OK that chatops may require a change and I'd read it as a full restart for the chatops project. |
True, we haven't reached a conclusion yet, sorry if I wasn't clear on this point. I'm just trying to constrain this discussion to two questions:
Any discussions about what future features we'd like to add are largely tangential to those two subjects, and I think it would be appropriate to section that off into a separate discussion/proposal.
I think the vast majority of our existing ChatOps users use ST2-flavored ChatOps via the aliases mechanism. I think we have very few - if any, at this point - users rolling their own st2chatops using our hubot-stackstorm plugin. And given how few outside patches we've received for hubot-stackstorm, I'm not feeling particularly charitable to anybody who wants to complain that we're changing too much.
This approach is perfectly normal for a paid-for product, but since StackStorm has transitioned to the LF, it's now less of a product and more of a project. And with open source projects, it isn't the customers who drive change - because there are no paying customers - it's the developers. And if users want to change the project, or prevent a specific change from happening, they have to get themselves involved in the development process. As such, I would expect to see those people giving their opinion in this thread, and so far both @nzlosh and @cognifloyd have been supportive of switching. But if we have users who don't want this change to happen, they should already be involved in the project, and this discussion. I'm skeptical of any users who think they care about this implementation detail but aren't already involved in this discussion. Transitioning to using a different ChatOps backend largely shouldn't change how users' ChatOps aliases function, so that abstraction layer should still work the same as it always has. For more "off the beaten path" users who are rolling their own ChatOps, if they want to see ST2 ChatOps grow, develop, and evolve with the current Node.js implementation, then they should have already been involved. The fact that we really aren't seeing any pushback from those users tells me that they don't actually care about this, or they at least don't care as much as we seem to think they do. Either way, it's ST2 developers, maintainers, and contributors who get to chart the course of the project. End users who want a say in an open source project can get involved in those exact ways, but I don't think they get to dictate how this project grows if they aren't actively involved in the development or at least funding the project on some level. I have proposed questions for the ChatOps User Survey in matrix-org/matrix-spec-proposals#19. Let's discuss that there, run the survey, and then discuss back here once we have the results from that. |
Right. However Engineers driving decisions doesn't mean that they should only think about the code and not thinking about users and from their perspective taking into account feature parity issues/consistency/usability overall experience and how that fits with the whole platform. I think that's how StackStorm engineers approached it before and it's not because of the customers.
That's the dream. The reality is that more pain points in the software leads to a situation when people just stop using it. |
|
Overall I'd like to make sure that we know and research the ChatOps domain in full before 3 engineers initiate the platform reset (I tend to think about it this way). And I believe this is just start, so how you can lead it if you don't see the big picture? I believe that more data, research, better understanding of community, use cases, pain points, chatops experience in general will drive better decisions, including transition and implementation. Otherwise we're navigating blind. You may also find something that you don't know yet. And yes, thanks for starting the discussion with the Survey Brainstorming at matrix-org/matrix-spec-proposals#19! Absolutely awesome stuff! 👍 Adding to the point of blindly driving: how do we know if decisions we'll do are good if we're not even using chatops ourselves at StackStorm today? @blag @nzlosh @cognifloyd Is this the right time to resurrect the st2 ChatOps instance in Slack community? |
There was an instance in the community? What things could it do? @nmaludy's beertab? 😄 I'm 👍 on having a community st2 ChatOps bot. It should be named "stanley" 😉 |
|
I just wanted to drop in and say hi, I'm the creator of Opsdroid and I really appreciate you considering using it. This has been a really interesting read. We are very open to input and discussions about how we can improve the framework. One of the main things we struggle with is there are so many things we want to do on the project, and being an open source project we have limited time and don't have the visibility of our user's behaviour to accurately prioritise. So dropping into our issues or Matrix chat to give us a nudge in a certain direction is much appreciated. Contributions are also very welcome. We have four maintainers who look after the project in our spare time (although I just had a second child so am a little less active than normal and probably will be for the next few months). I also just updated our roadmap to show that Finally, I wondered if I could pinch the comparison matrix that @cognifloyd put together for our documentation. It's really helpful for us and our users to see a comparison like that. It also gives us some help with prioritisation to ensure we are comparable to the alternatives. |
|
@jacobtomlinson go for it :) Note that the leftmost column is specifically about ST2 + Hubot, not hubot alone. That's relevant for the discussion here, but probably not in the OpsDroid docs. If you want to include Hubot, then I would go evaluate hubot on its own and replace that column. |
|
Thanks will do! It would also be interesting to create a comparison matrix of other features not related to chat integrations. I'm thinking things mentioned in this issue like support for NLP/NLU services, non chat events such as user's joining and leaving rooms/channels, support for interactive elements like Slack blocks. As users external to the frameworks you are discussing I would like to hear your thoughts on what those features could be and how valuable they are to you? |
StackStorm ChatOps Plans Follow-upChatOps User Survey (#48) uncovered some inspiring data and answers as well as a lot of supporters from community willing to help moving the platform to the new Python rails. @blag it would be great to plan and organize the StackStorm ChatOps open meeting under your leadership and invite everyone interested @StackStorm/tsc @StackStorm/contributors and others offered their to help to discuss the direction, efforts and plans on StackStorm ChatOps side, similar to what we do with the TSC Meetings. Let me know how I can help 😉 |
|
Following up, OpsDrois has a (WIP) functional connector that adds support for MS Teams: It does use BotFramework, but only to grab it's internal API SDK. It doesn't have the rest of BotFramework's baggage. |
|
I just scheduled a get-to-know-you meeting for OpsDroid and StackStorm devs. Please join us on March 11th. Meeting Link: https://meet.jit.si/stackstorm-opsdroid
Agenda Topics (a general/flexible outline of possible topics based on what attendees want to cover):
|
|
I just edited my chart above: Basic Teams Support was just merged into OpsDroid opsdroid/opsdroid#1679 |
|
OK. Here is my initial plan for integrating OpsDroid and StackStorm. I put it in google docs and opened it up so anyone can comment on the doc. Feedback welcome! https://docs.google.com/document/d/1ycV05-sUwd0Q27ZVjPQAq5nLuUJM_gzaBWOynwdXDJ8/edit?usp=sharing |
What
Identify a path for st2chatops that:
Why
The existing approach is:
How
The Purpose of this Issue
Discussion
Initial Post by @blag
Our ChatOps microservice is just...weird compared to all of our other microservices. It's written in asynchronous Javascript, so it can't share any code with the other normal Python-based microservices, and it must duplicate a lot of the code found in our Python st2client. This leads to more complicated development and release processes, since we have to keep st2client.js, hubot-stackstorm, and st2chatops all up-to-date and in-sync with the rest of the ST2 repositories.
I propose that we look into Python-based ChatOps bots as a base to use for future st2chatops. Two that people have told me about at ErrBot and OpsDroid, both are Python projects.
asyncioframework in the Python standard library, and it supports more our normal regex-based parsers, but it also support more complex NLP/NLU systems to match messages. Getting this to work with StackStorm would be more involved than ErrBot, but would enable a next-generation ChatOps architecture with StackStorm. Upstream is also very responsive, and PRs get feedback quickly. It also does not yet support Microsoft Teams. It is licensed under the Apache 2, so we won't have any questions about distributing it, or including it in our distribution.I'd like to give a huuuuuge shoutout to @nzlosh, as almost all of this is based on conversations I've had with him, and he has done a lot of investigating into this subject on my behalf. Thank you for your work!
The text was updated successfully, but these errors were encountered: