ChatOps is a new operational paradigm - work that is already happening in the background today is
brought into a common chatroom. By doing this, you are unifying the communication about what work
should get done with the actual history of the work being done. Things like deploying code from
Chat, viewing graphs from a TSDB or logging tool, or creating new Jira tickets…all of these are
examples of tasks that can be done via ChatOps.

ChatOps leverages two components within EWC in order to provide a fluid user experience. These
subsystems are the Action Aliases and Notifications subsystems. You can learn more about
each of these individual components in their corresponding sub-sections.

Our goal with ChatOps is to take common patterns and make them consumable by teams of all makeups.
Behind our implementation of ChatOps lies the operational scalability and stability of EWC,
allowing you to grow and unleash the latent power of your existing teams. In addition to allowing
integration with a plethora of existing plugins and patterns available in the larger EWC and
ChatOps communities, we’ve added these features to the tool-belt:

History and Audit. Get complete history and audit trails of all commands executed via ChatOps.
Learn and understand how people are consuming the automation via ChatOps. Enhance your
understanding.

Bring your favorite tools! Each bot comes with its own requirement to learn their language.
Forget that mess! Bring the tools that make you productive.

We want to make ChatOps approachable by every team in every circumstance. This means an
understanding of how teams of all sizes run, in many different types of verticals. Issues like
compliance, security, reliability: these concerns are at the forefront of our minds when we think
about what ChatOps means to us, and how it provides real-world value to you.

Since
HipChat is being discontinued,
official support for the HipChat adapter will end when
HipChat reaches end-of-life (as of this writing, this is planned for June 30th, 2020), and it will be
completely removed without any deprecation period from the st2chatops project once HipChat itself
is terminated. Administrators of local HipChat servers should already be actively migrating to
other chat providers.

Configuring st2chatops with Microsoft Teams is a more involved process. Please see
our documentation specifically for that chat provider.
All other chat providers can be configured in st2chatops.env with the instructions
below.

If you installed EWC following the install docs, the st2chatops
package will take care of almost everything for you. Hubot with the necessary adapters is already
installed, and StackStorm API keys have been configured.

You just need to tell EWC which Chat service to use - e.g. Slack, MatterMost, etc. You will also need
to give it credentials. Your Chat service may also need configuration. For example, to configure Slack,
you first need to add a new Hubot integration to Slack. You can do this through Slack’s admin interface.
Take note of the HUBOT_SLACK_TOKEN that Slack provides.

Then edit the file /opt/stackstorm/chatops/st2chatops.env. Edit and uncomment the variables for
your adapter. For example, if you are configuring Slack, look for this section:

# Slack settings (https://github.com/slackhq/hubot-slack):#exportHUBOT_ADAPTER=slack
# Obtain the Slack token from your app page at api.slack.com, it's the "Bot# User OAuth Access Token" in the "OAuth & Permissions" section.exportHUBOT_SLACK_TOKEN=xoxb-SUPER-SECRET-TOKEN
# Uncomment the following line to force hubot to exit if disconnected from slack.exportHUBOT_SLACK_EXIT_ON_DISCONNECT=1

Your specific Chat service may require different settings. Any environment settings needed can be
added to this file.

Once you have finished making changes, restart st2chatops with sudoservicest2chatopsrestart.
Check your log files to ensure that it is successfully connected.

If you want the ChatOps messages to include the right hyperlink to execution url for the action
you kicked off via ChatOps, you have to point EWC to the external address for the host running
the web UI. To do so, edit the webui section in /etc/st2/st2.conf. For example:

If you use proxies in your environment, you may need to configure st2chatops to use the proxy. If you used
the scripted installation, this has been done for you. If not, configure either /etc/default/st2chatops or
/etc/sysconfig/st2chatops (depending on your Linux distribution), following the same pattern as used for
configuring st2api and st2actionrunner.

Please note that while we always try to help the best we can, we can’t support adapters that are
not bundled into st2chatops since they are too numerous. If you run into trouble with an
external adapter, it’s usually best to open an issue in the adapter’s GitHub repo or contact the
authors.