Jan 12, 2017
by Siddharth Krishna

Recently we explained how to use Syslog with Splunk & StackStorm to auto-remediate a link going down on a switch. Splunk is a widely used log management tool but there’s also a popular open source alternative – Elastic Stack (formerly the ELK Stack: Elasticsearch, Logstash and Kibana). So if you’re using the Elastic Stack, and are looking to automate event remediation in your environment, you’re at the right place! In this post, we’re taking the same use case as before and talking about how to set up the Elastic stack to collect syslog data and trigger event-based network remediation workflows using StackStorm.

Any changes to StackStorm?

No. Everything in relation with StackStorm (webhooks, workflows, actions and integrations) remains the same as documented in the earlier blog. Optionally, you could create a new webhook URL (eg. elk_link_flap) specifically for your Elastic Stack setup. Here, our primary focus will be on configuring the Elastic Stack for an end-to-end demonstration of the auto-remediation use case.

Set Up Logstash

First step is to define data source for syslog as input and Elasticsearch as the output in the Logstash configuration. UDP port 514 is used for syslog. The Logstash configuration file is located at /etc/logstash/conf.d/. Create a new config file eg. lsconfig.conf if one does not already exist and ensure that there’s only one config file at this location for Logstash to use. Add the following content:

Restart the Logstash service:
sudo service logstash start

Verify Syslog on Kibana

On Kibana, define a new Index Pattern logstash-* and select it in the Discover dashboard. Assuming that your network devices are pointing to the Elastic Stack server for syslog, you should now start seeing the syslog messages from the devices on Kibana dashboard.

Add Field Extractions

To be able to pass relevant information such as the switch interface name (for the link which went down) and IP address to the StackStorm Auto-Remediation workflow, the info has to be first extracted from the log message body. We use Logstash Filters & Kibana Fields to do this. Add the following filter to the Logstash config and restart all Elastic Stack services.

Once this is done, fields interfacename and host will start getting auto-populated for each syslog message. Yes, interfacename extraction will work only for “link down” syslog messages but that’s good enough for our demonstration. Of course, you can use more specific grok text pattern matching for better filtering.

Sense App for Kibana

The Sense App is nice for interacting with the REST API of Elasticsearch. We use it to create a watch to trigger our workflow. It is a convenient way to quickly test out elastic search configurations via the REST interface. Follow the official documentation here to install Sense.

Install Watcher, Create a Watch

We use Elasticsearch Watcher Plugin for the alerting functionality required for triggering the StackStorm workflow. After installing the plugin, use Sense to create a watch: an alert which calls a webhook into StackStorm whenever the “link down” syslog message is received from a switch (determined by a match criteria and a condition).

Watcher helps identify changes in your data that are interesting to you by using the Elasticsearch query language. It provides multiple alerting options with built-in integrations and comes with a powerful webhook output for integration with your existing monitoring infrastructure or any third-party system.

Watch definition:

The watch has the following characteristics:

• Schedule: Runs every 5 seconds.
• Match Criteria: Messages in index logstash-* containing string “is link down” received in the last 8 seconds.
• Condition: If the filtered message count at watch run time is greater than 0.
• Actions: Call a webhook into StackStorm passing parameter values for host (switch IP address) and interfacename (identity of the interface that went down).

Putting it together

We are now ready with the configurations and its time to verify our automation. Trigger the event (in this case, link down), confirm that the syslog for the event shows up on the Kibana dashboard and finally validate the execution of the StackStorm workflow to see the programmed auto-remediation in action. That’s it. You now have syslog driven auto-remediation working in your environment with the Elastic Stack!

The post Event Driven Auto-Remediation with the Elastic Stack appeared first on StackStorm.

Jan 24, 2017
by Dana Christensen

Part 1 of 3

At DevOps Enterprise Summit 2016, DevOps leaders like Target, American Airlines, Disney, and Quicken Loans spoke of the importance of managing/optimizing operations, addressing technical debt, eliminating silos, collaboration, and the importance of open source and community to drive innovation. I was especially struck by Jason Cox of Disney, who stressed the importance of “creating a culture of courage” where teams are encouraged to be curious, to experiment, explore and embrace change across process, roles, and technology-all for the purpose of enabling meaningful work.

It turns out that these themes are being talked about not only by these large Enterprise DevOps leaders. These themes are being repeated in conversations around the globe with IT leaders who are looking to leverage DevOps practices to successfully drive innovation and digital transformation.

Anthony Shaw, Group Director of Innovation and Technical Talent at Dimension Data has seen this first hand. Anthony not only leads innovation efforts within Dimension Data-but he also travels the world speaking with customers about their business priorities, their Digital Transformation goals, and how the innovative use of technology, organizational structure, community, and transforming day to day operational practices can accelerate their Digital Transformation journey.

We were fortunate to have Anthony travel from his home in Australia all the way to the US to present about StackStorm at the Gartner Data Center Conference in Las Vegas. He then joined us to speak at the Auto Remediation and Event Driven Automation Meetup here in San Jose, where he shared his thoughts on key DevOps trends & challenges–and some creative ways to address these challenges leveraging the power of the StackStorm platform. You can listen to Anthony’s presentation at the MeetUp here.

When looking at how DevOps can accelerate digital transformation, Anthony stresses the importance of : 1) recognizing that DevOps is not just about deployment–it’s about automating and optimizing ongoing operations; 2) the importance of breaking down silos and streamlining/optimizing DevOps Tool Chains; 3) and the importance of collaboration and open source communities to drive innovation and accelerate digital transformation.

In this series of blogs we will share how Anthony leverages StackStorm to address each of these topics and how he is helping to accelerate innovation with StackStorm within Dimension Data and with their clients.

StackStorm Takes DevOps Beyond Deployment to Optimize Ongoing Operations

Anthony has observed that when many customers speak of DevOps, they tend to limit their focus on application deployment- Continuous Integration and Continuous Deployment. Most DevOps tools on the market today are focused on being able to get the application deployed as quickly as possible, or being able to update the application in production and staging environments 10x, 100x per day. These practices typically apply to new in house developed applications and services. However, for most of Anthony’s clients, application deployment is maybe 5% of the overall problem. The major challenges and greatest costs are around ongoing operational support, availability, and scaling.

According to Anthony, the questions enterprises really should ask are: How do you ensure that your teams are working together to provide seamless, uninterrupted delivery of applications and services to your customers? How do you deal with your technical debt? All those other pieces of software or applications that you’ve purchased, that were built a while ago, or acquired as a result of a merger? How do you integrate with the old system that only has a command line interface, doesn’t have a nice REST API to plug into, doesn’t already have a python library? What if something goes down, what do you do next?

The real power of DevOps is in being able to give the operations teams tools to diagnose and remediate issues, think about the day to day events, and that’s where Anthony suggests customers take a look at StackStorm to leverage the power of event driven automation and auto remediation.

When developing DevOps processes and defining approaches to automation, it’s important to look at the operational lifecycle of an application instead of just thinking about deployment. Take a meta view of the entire value stream, and identify workflows that involve a lot of repetitive, manual work. Ask questions like what does this application look like in operation? How do we diagnose issues in runtime? How do we look at tuning performance? How do we link those events into the application and the automation process?

StackStorm is an event driven automation platform that is designed to help you answer these questions in code. You can define rules, workflows, and integration points to your entire application lifecycle. And StackStorm can be leveraged to optimize workflows in all areas across the data center–including Security, Networking, Big Data Workflows, and IoT.

One example is the way Dimension Data leverages StackStorm to optimize an existing workflow to respond to security incidents.

The diagram below illustrates the StackStorm automation script Dimension Data created to trigger a security audit whenever a new server is deployed on the AWS cloud ( this could work just as well on other clouds such as Microsoft Azure).

The workflow notifies the teams whenever an action is taken. This allows the Di Data security teams to be a lot more agile and responsive. Instead of running a scan once a day or once a week, they can respond immediately to any changes in the infrastructure.

This is just one example of efficiencies gained at Di Data by using StackStorm.
In the next blog in this series, we will review how Anthony leverages StackStorm at Dimension Data to integrate and Optimize the DevOps Tool Chain.

Learn More About StackStorm Event Driven Automation & Auto-Remediation

To learn more about StackStorm, please visit the StackStorm website, listen to this excellent overview of StackStorm given by our expert Stormer Matt Stone at OpenStack Summit Barcelona, or check out this to short video on StackStorm

To learn more about how companies like Netflix, Facebook and others are leveraging Event-Driven Automation and Auto-Remediation, please join the Auto-Remediation and Event Driven Automation Meetup.

The post Innovation at Dimension Data: Accelerating Innovation and Digital Transformation with StackStorm Event Driven Automation appeared first on StackStorm.

Jan 30, 2017
by Edward Medvedev

Warning: this post describes a long set of important changes. It is enormous in size and full of cheesy puns, feelings, and heart emojis. You might prefer to read the documentation if that is not what you are into. Otherwise, grab a favorite caffeinated drink of your choice and let’s begin!

A little while ago we rolled out StackStorm 2.1, a release focused on one primary theme: integration packs.

StackStorm pack management infrastructure is evolving with the demand. As the number of integration packs grows, we want to provide means for faster and easier deployment, make pack development more productive, and encourage collaboration. There are dozens of changes making it happen—both in our internal infrastructure and the StackStorm core—and we are excited and hopeful that through better experience with integration packs, working with StackStorm will become even more efficient, easy, and fun.

As it is the case with all “thematic” releases, 2.1 is more than just a set of features and changes. It has a lot of context around it, and more importantly, it has a story—and this is a story we are now going to tell.

From st2contrib to StackStorm Exchange

Our contribution repository, st2contrib, served the StackStorm users well for a long time. It was home for about a dozen integration packs when it started, and over a few years it successfully expanded to more than a hundred.

The amount of StackStorm content is growing fast, and around the time when the pack count couldn’t fit into an int8 anymore, placing all packs into a single repository suddenly stopped looking like such a good idea.

Having more content than we could handle was a good problem to have—and still, it was a problem that needed solving. Every clone of st2contrib downloaded thousands of extra actions, it was very hard to version and process packs separately, and it was nearly impossible to give external contributors access to a subset of packs or assign pack maintainers.

So we had to bid farewell. As of the 2.1 release, st2contrib has been closed to new contributions, and the packs have moved to a new home. The goodbye was bittersweet, but we knew it had to happen.

Of course, the repository will stay open for backwards compatibility with the old StackStorm versions that might have deployment workflows depending on it. However, if you want to keep up with the bug fixes, updates, and new pack versions, we encourage you to upgrade to StackStorm 2.1 and read our transition guide.

Now, about that new home.

StackStorm Exchange is the hub around which our new pack management system works. We have been planning and preparing the transition for a while, and the new infrastructure has been successfully rolled out with the release of StackStorm 2.1.

There is a huge number of changes, big and small, and most of them can be attributed to one of the four key scenarios that we will talk about: discovery, collaboration, development, and deployment.

Those make up four entirely different stories—varying even in mood and tone—but in the end they combine into one giant Super Robot and awesomeness ensues.

Let’s begin.

Discovery

Of all the things introduced in this release, the StackStorm Exchange front-end is probably the shiniest. It has been crafted with sweat, tears, ReactJS, and a little bit of love, and we hope you enjoy using it to find new packs you might like.

The “a little bit of love” part might seem debatable in light of some earlier UI prototypes, but our love for automated tests is just as important as our love for users.

We are determined to keep updating the UI with new amazing features, and we won’t stop until discovering and installing the packs you need is effortless. We’ll just have to write a React plugin for mind-reading (I’ve heard you can do anything in JS just by gluing a few hundred of npm modules together, so it should be pretty simple).

Visit the Exchange at exchange.stackstorm.org, or check out the source code at StackStorm-Exchange/web at Github if you are curious.

Another new way of discovering packs is the st2 pack CLI commands introduced in StackStorm 2.1 (more on that later). You can search for packs or get information about a particular one:

$ st2 pack search monitoring
+----------+------------------------------+---------+-----------------------+
| name     | description                  | version | author                |
+----------+------------------------------+---------+-----------------------+
| dripstat | Integration with the         | 0.2.0   | James Fryman          |
|          | Dripstat Application         |         |                       |
|          | Performance Monitoring tool  |         |                       |
| sensu    | st2 content pack containing  | 0.3.0   | StackStorm, Inc.      |
|          | sensu integrations           |         |                       |
| nagios   | Nagios integration pack. See | 0.2.0   | StackStorm, Inc.      |
|          | README.md for setup          |         |                       |
|          | instructions.                |         |                       |
| newrelic | st2 content pack containing  | 0.3.0   | StackStorm, Inc.      |
|          | newrelic integrations        |         |                       |
| datadog  | datadog                      | 0.0.2   | Lisa Bekdache         |
| mmonit   | st2 content pack containing  | 0.3.0   | Itxaka Serrano Garcia |
|          | mmonit integrations          |         |                       |
+----------+------------------------------+---------+-----------------------+

$ st2 pack show sensu --yaml
author: StackStorm, Inc.
content:
    actions:
        count: 19
    rules:
        count: 2
    tests:
        count: 1
    triggers:
        count: 1
description: st2 content pack containing sensu integrations
keywords:
- sensu
- monitoring
- alerting
name: sensu
ref: sensu
repo_url: https://github.com/StackStorm-Exchange/stackstorm-sensu
version: 0.3.0

The underlying back-end behind both the UI and the CLI commands deserves a special mention. We are all into automation, so our pack directory is now exposed as a consumable JSON file: you can download it at index.stackstorm.org/v1/index.json or clone the StackStorm-Exchange/index repository.

The index updates in real time: our CI system rebuilds it right after an update is pushed to the packs. Also, because it is served as a static file, we can build the UI as a front-end-only app and host it on GitHub Pages for free, because we are cheap GitHub is awesome.

Pack indexes in 2.1 are meant to be extensible: while the StackStorm Exchange index is used by default, you are free to introduce your own! You can mirror our main index, expand it, or even host your own catalog of internal packs, similar to source files in OS package management. Read on to the Deployment section or jump straight to the documentation section on indices for the distilled wisdom free of cheesy puns.

With StackStorm Exchange, we hope to make the discovery of integration packs easier for both new and advanced users, and the custom indexes can come in handy for larger-scale Enterprise deployments. We hope to hear your thoughts in our Slack community channel, and please stay tuned—we have even more exciting things planned!

Collaboration

Pull requests from our community aren’t just pieces of code: behind each one there is time and effort that someone has put into making StackStorm better for everyone. To show our appreciation, we strive to save as much of your time as we can by reducing the overhead of submitting new packs and features (we also send heart emojis and pug pictures as a sign of appreciation, but I digress).

StackStorm Exchange continues this tradition: we have made both architectural and organizational changes that are meant to make contributions faster, easier, and more straightforward.

Most importantly, the packs are now split into multiple single-pack repositories inside a dedicated GitHub organization, StackStorm-Exchange. Smaller repositories are not just easier to work with, but also more manageable—and they make our primary organizational change possible.

With the transition to StackStorm Exchange, we are introducing the pack maintainer role.

A pack maintainer is someone who is an active developer (and often creator) of the pack, and an expert on both the target product of the pack and the API or the library that is used. Pack maintainers often help other users with their contributions, respond to issues, and review pull requests. They heavily rely on the packs they maintain in production use.

Some of our most active community members have already taken up this role over time, and now we are happy to recognize them in an official capacity. Those we are inviting to become maintainers are getting full permissions to their pack repositories and will be able to develop and manage their packs more efficiently. We are fascinated by everyone who has agreed to step up, and to give credit where it’s due, we will talk about our maintainers shortly in a dedicated post!

Everyone else submitting a pull request or opening an issue benefits from this equally: in addition to the help from our engineering team, they will also get help from pack maintainers, who are often more knowledgeable about their packs than we are. With this kind of help, we can reduce the average time required for bug fixes, reviews, and new releases, as well as the average response time for issues, which, in turn, benefits our users as well.

As a conclusion to the collaboration part, we would like to thank everyone who has ever contributed to a StackStorm pack. With the new changes, we humbly hope to encourage you to keep working with StackStorm and developing new integrations. Think of StackStorm Exchange as a huge heart emoji that we’re sending to every one of you.

❤️️

Development

The core change in the pack development workflow—hosting packs in their separate repositories—has already been mentioned in passing, and now we are going to focus on it a little more. First things first: with this change, we had to make a very hard decision.

Dramatic build-up music plays.

The transition to single-pack repositories is breaking. Pack installation in StackStorm 2.1 does not support repositories with multiple packs in them.

Sudden violin screech!

Let’s rewind and talk history: there were several problem areas with st2contrib that made this change unavoidable.

• Organization: inability to fine-tune access—for instance, assign maintainers to individual packs.

• Structure: overall mess and clutter, like having issues from 100+ packs piled up in one place or being unable to follow the changes only in certain packs.

• Architecture: having to clone the entire repository to install a single pack is, well, suboptimal.

• Technical debt: best illustrated by the opening comment in the pack download action.

#####
# !!!!!!!!!!!!!!
# !!! README !!!
# !!!!!!!!!!!!!!
#
# This NEEDS a rewrite. Too many features and far too many assumption
# to keep this impl straight any longer. If you only want to read code do
# so at your own peril.
#
# If you are here to fix a bug or add a feature answer these questions -
# 1. Am I fixing a broken feature?
# 2. Is this the only module in which to fix the bug?
# 3. Am I sure this is a bug fix and not a feature?
#
# Only if you can emphatically answer 'YES' to allow about questions you should
# touch this file. Else, be warned you might loose a part of you soul or sanity.
#####

Consider this: the transition to single-pack repositories solves all those problems at once. And then some: we can start utilizing git tools and repository metadata to introduce features like versioning at virtually no cost.

Even though introducing breaking changes always feels like a blood sacrifice—and relying on git for package management can definitely backfire—no other solution would be nearly as effective at this stage of our growth. And so the blood sacrifice has been made. So it goes.

Regardless of whether you contribute to community packs in the Exchange or create packs for your own internal use, you will notice positive changes from day one. First, let’s see how the problem areas outlined above turn into improvements:

• Organization: as pack maintainers contribute their time and expertise to help us review issues and pull requests, you can expect better code quality of the Exchange contributions—and faster reviews because of the shared workload!

• Structure: single-pack repositories are easier to manage and control with git. Logs and metadata are concise, diffs in branches and tags are free of clutter, and whenever there is a new commit upstream, you know it is related to your pack. It is also easier to keep track of issues and pull requests—and easier for the users to follow only the packs they need.

• Architecture: several internal improvements like faster pack deployments, extended support for private repositories, or git+SSH support.

• Technical debt: 84.5% less code paths that lead to insanity—and more time to develop useful features!

Pretty neat, right? But we have only scratched the surface: now we can take this idea of git coupling even further and build up on it to make development—and then deployment—even more convenient.

• Live development: since pack installation essentially becomes a git clone, you can work with installed packs just like you would with any other git repository. Switch tags and branches, try out local changes and revert them, or even make commits from your StackStorm server (not a good development workflow, but could be useful for playing around or pushing hotfixes upstream).

• Versioning: following the previous point, we can easily make our deployment action install specific pack revisions, branches, and tags (only branches were supported before 2.1). Use feature branches for development, pin pack versions to a specific revision in production—you know, do what you would normally do with versioned packages.

And then a few more extra features for pack developers as a small cherry on top:

• Pack metadata additions: there are several new fields in pack.yaml, like contributors or stackstorm_version—read more about them on the pack documentation page. Additionally, we introduce semver format (X.Y.Z) validation for the version field to keep the versioning more consistent.

• Extensible CI in Exchange: if you are developing an Exchange pack that requires special treatment (for instance, extra system-level dependencies for running tests), it is now possible to modify its CI environment or add new checks—unlike st2contrib which had uniform CI for all packs.

• Version tagging in Exchange: if your PR to any of the Exchange packs changes version in pack.yaml, our caring CI robot will also create a corresponding version tag in git for easier deployment. Speaking of tidy and orderly!

With all the changes, the one important goal we are trying to achieve is creating a development environment that just gets out of your way. You have probably noticed that the new features are not focused on development, but create a utility layer around it instead—and while we find this layer very helpful, it is also completely optional.

You do not have to list your packs in StackStorm Exchange, you do not have to host your repositories on GitHub, and you do not even have to use git at all. At the end of the day, StackStorm packs are just directories and files, and you are free to create, store, and deploy them in any way you want.

Instead of imposing a set of tools or a specific workflow, we would rather take the supporting role and reduce overhead and clutter as much as possible, so that you can focus on writing code and getting things done.

Damage boost engaged!

Deployment

Now, for the final part of the StackStorm Exchange transition: deployment. Pack deployment in 2.1 is one huge bundle of improvements and new features—something that every change in this release has been building up towards, and something that has made all the blood sacrifices worth it.

There is enough good news for everyone.

Good news for those who use our CLI: we have new st2 pack subcommands for installing, upgrading, and managing packs.

usage: st2 pack [-h] {list,get,show,search,install,remove,register,config} ...

A group of related integration resources: actions, rules, and sensors.

positional arguments:
  {list,get,show,search,install,remove,register,config}
                        List of commands for managing packs.
    list                Get the list of packs.
    get                 Get information about an installed pack.
    show                Get information about an available pack from the
                        index.
    search              Search the index for a pack with any attribute
                        matching the query.
    install             Install new packs.
    remove              Remove packs.
    register            Register a pack: sync all file changes with DB.
    config              Configure a pack based on config schema.

optional arguments:
  -h, --help            show this help message and exit

Good news for those who work with git: packs can be installed from any git repository—and versioned with tags, branches, or commit SHAs.

$ st2 pack install https://github.com/emedvedev/chatops_tutorial=49b65a5

    [ succeeded ] download pack
    [ succeeded ] make a prerun
    [ succeeded ] install pack dependencies
    [ succeeded ] register pack

+-------------+---------------------------+
| Property    | Value                     |
+-------------+---------------------------+
| name        | Chatops Tutorial          |
| description | Tutorial pack for ChatOps |
| version     | 0.3.0                     |
| author      | emedvedev                 |
+-------------+---------------------------+

Good news for those who like neat interactive prompts: most packs can be configured interactively with st2 pack config.

$ st2 pack config sensu
ssl (boolean) [n]: false
host: localhost
pass (secret): ******
user: admin
port [4567]: 4568
---
Do you want to preview the config in an editor before saving? [y]: n
---
Do you want me to save it? [y]:
+----------+---------------------------+
| Property | Value                     |
+----------+---------------------------+
| pack     | sensu                     |
| values   | {                         |
|          |     "port": "4568",       |
|          |     "ssl": false,         |
|          |     "host": "localhost",  |
|          |     "user": "admin",      |
|          |     "pass": "secret"      |
|          | }                         |
+----------+---------------------------+

Good news for those who like ChatOps: we have made a complete overhaul of our pack management aliases.

Good news for those who control StackStorm through the API: there is an API endpoint for every pack management command in StackStorm 2.1.

$ curl -k https://192.168.16.20/api/v1/packs/uninstall \
    -H "Content-Type: application/json" \
    -d '{"packs":["jira"]}'

{"execution_id": "588f7bc9c4da5f38ad10a344"}

Good news for those who want to keep it classy: you can maintain your own pack index to make your private packs searchable and resolvable by name. You can even host your own directory page: just fork our Exchange front-end!

Good news for those who got sad after learning that we do not support multi-pack repositories anymore: there is a migration script (courtesy of @pixelrebel) that helps you split them while preserving the commit history.

Moving bwc_topology...
Rewrite 459e3a1e7bf72bd114e9380ed7ac88fa36fda721 (11/11) (0 seconds passed, remaining 0 predicted)
Ref 'refs/heads/master' was rewritten

Counting objects: 89, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (55/55), done.
Writing objects: 100% (89/89), 27.38 KiB | 0 bytes/s, done.
Total 89 (delta 45), reused 55 (delta 31)
remote: Resolving deltas: 100% (45/45), done.
To https://github.com/stackstorm/stackstorm-bwc_topology.git
 * [new branch]      master -> master
The bwc_topology pack has been transferred.

And what if you would rather not use any of this and prefer a completely different deployment workflow? Oh boy, do we have good news for you, too! As mentioned in the development section, you are completely free to keep doing this in 2.1, and just as before, all you need is to have your packs copied to /opt/stackstorm/packs and reload the content:

$ cp -r stackstorm-aws/ /opt/stackstorm/packs/aws
$ st2 pack register aws
+--------------+-------+
| Property     | Value |
+--------------+-------+
| actions      | 639   |
| aliases      | 0     |
| configs      | 0     |
| policies     | 0     |
| policy_types | 3     |
| rule_types   | 2     |
| rules        | 0     |
| runners      | 13    |
| sensors      | 2     |
| triggers     | 0     |
+--------------+-------+

That would be all.

Conclusion

With one release—for most of our users, essentially overnight—pack management in StackStorm turned from a bunch of actions into a full-featured package control system with versioning, CLI commands, API endpoints, and a dedicated hub. It has not been an easy journey, and some sacrifices have been made, but in the end it was well worth it.

When it comes to acknowledgements, it has been an immense collective effort, and while our entire engineering team has been working in full force to make the release happen, it would not be complete without the support of our amazing community.

We are grateful to everyone who has ever contributed to our growing library of more than a hundred integration packs—for helping StackStorm and the community grow.

To the StackStorm experts who stepped up to become our first pack maintainers—for their sincere desire to give back.

To the curious folks who started testing features before we even announced they are in development—for giving early feedback and showing us the fun of open source.

To the awesome crowd of a spontaneous StackStorm meetup in London—for sharing their thoughts during my early Exchange presentation.

To everyone who relies on StackStorm—for giving our work meaning.

Thank you. ❤️️

Lastly, a few useful documentation links:

• full 2.1.0 changelog;
• upgrade notes;
• st2contrib/Exchange transition notes;
• general pack documentation;
• pack development documentation.

And as always, we are there for you! If you have questions, want to give feedback, or just feel chatty, you can find us in our StackStorm community Slack.

— Ed

The post StackStorm Exchange: The New Pack Management appeared first on StackStorm.

Februrary 3, 2017
by Eugen C. (@armab)

Did you know we have Ansible playbooks to deploy StackStorm?
It’s something that was in a shadow for a while.

github.com/StackStorm/ansible-st2

Here, now you know!

Despite of “secrecy”, some people used it and even actively contributed. For example our friends from Arteria Project.

ansible-st2 v0.6.0 released

But there are more good news! Recently we released big update in ansible-st2 which apart of existing Ubuntu Trusty and Xenial adds support for the new platforms: RHEL6/CentOS6, RHEL7/CentOS7 and accumulates a lot of work: new features, bugfixing, CI improvements like running a play in Docker with Test-Kitchen and Travis across all 4 platforms, a lot of end-to-end testing and polishing.

So you can deploy StackStorm with Ansible, even on a real RHEL now!

Looks like a lot of activity for a single version release in Ansible playbooks repo, isn’t it?
Thanks to our own Anirudh Rekhi and Matt Oswalt for making it possible!

Being confident about the quality now, we reference Ansible Playbooks as additional installation method in our docs, check out: docs.stackstorm.com/install/ansible.html

If you are aware of using Ansible with StackStorm, here is the full v0.6.0 CHANGELOG.

Quick Install

So if you’re tired of curl | bash installer and missing real idempotence, here are basic instructions to get started:

git clone https://github.com/StackStorm/ansible-st2.git

ansible-playbook stackstorm.yml

Behind the scenes stackstorm.yml play composed of the following roles for a complete installation:
– epel – Repository with extra packages for RHEL/CentOS.
– mongodb – Main DB storage engine for StackStorm.
– rabbitmq – Message broker for StackStorm.
– postgresql – Main DB storage engine for StackStorm Mistral.
– st2repos – Adds StackStorm PackageCloud repositories.
– st2 – Install and configure StackStorm itself.
– st2mistral – Install and configure StackStorm Mistral workflow engine.
– nginx – Dependency for st2web.
– st2web – Nice & shiny WebUI for StackStorm.
– st2smoketests – Simple checks to know if StackStorm really works.

For more detailed configuration, please refer to GitHub repository with a full list of vars.

Community

If you need more, – please feel free to submit your Pull Requests and remember that our users and contributors are those who make biggest impact on StackStorm, so your involvement or opinion is very important!

Keep an eye on StackStorm/ansible-st2 for more improvements. In future updates you’ll see st2chatops, more options and vars for Custom Installations, Integration tests and eventually we’ll publish everything on Ansible Galaxy.

The post Introducing Ansible playbooks to deploy StackStorm appeared first on StackStorm.

Feb 06, 2017

by Dmitri Zimine, @dzimine

Last Thursday, we had another great meetup session on Auto Remediation and Event Driven Automation. This time it was in San Francisco at Make School, thanks to our new sponsors Neptune.io. The drive from South Bay was totally worth it!

The Facebook Infrastructure Orchestration team presented their FBAR. No, this is NOT the FBAR talk you may have heard hundred times. It is the premiere of a new talk about their System Lifecycle Automation which includes a newer and better FBAR. The FB guys keep the scent of secrecy around it: take no video, post no slides – come see in person. Those who came were truly rewarded.

There are two types of remediations in FBAR: one that is out of the box, built by SRE team, and one that is built by application owners. Results?

94% alarms are cleared without human intervention.

The value of auto-remediation is immediately obvious from these numbers. “At our scale, even with 2% coming to us it’s a lot of manual work” says Gabriel dos Santos.

James Mills went over advanced topics – rate limiting, preventing “run-away automations”, job prioritization, automating large batches of hosts… When FB says “large” they mean it:
* Hundreds of millions distinct jobs per month
* Thousands of years combined run time per month
* Hundreds requests per second

Next on stage, Neptune.io founder Kiran Gollu drove home the need and business value for automated diagnostics and remediation; that it is not “if”, it’s “when” for any sizable ops. It is just a matter of time and maturity of the incident response team when automated diagnostics and remediation becomes a necessity.

Today, 95% of your incident’s MTTR is still manual

This resonates: “I am used to having FBAR at FB; now we need something like this at Uber n” says Rick Boone, ex FB production engineer, now SRE at Uber. Hey Rick, hope you’ll like StackStorm!

There would have been no fun without a good demo, and we enjoyed live demo of Neptune.io. It is a hosted auto-remediation solution, impressively easy to set up, nice event consolidation UI and familiar concepts to auto-remediation. StackStorm and Neptune.io are technically competitors, but we share the passion for auto-remediation, I really love some aspects of their solution and wholehartedly wish Neptune growth and success.

Of course the best part of meetup is meeting up – with like-minded folks. We are a small group (only 670 :P) of experienced devops practitioners and thought leaders who are knowledgeable and passionate about automating operations. We spent a good time hearing each others’ stories, learning perspectives, posing and trying to answer challenging questions.

Among other things, we’ve talked about event correlation, the state of live event processing in the industry, the technical reason why this functionality is still missing in FBAR, StackStorm, and Neptune.io, and brainstormed some ways to solve the problem – a topic worth a dedicated blog.

We are lining up more igniting talks and inviting speakers for our next sessions. What is YOUR story? Care to share? Please propose the topic. To do so, go to the Auto-Remediation meetup page page, and press a big red Suggest a Meetup button.

Talking same topic on stackstorm community slack today.

And for continuous conversation (CC) on event driven automation, join our on StackStorm Slack channel – stackstorm.com/community-signup.

Until next time,

DZ.

The post Meetup: How to automate 94% incident responses: Facebook, Neptune.io, autoremediation appeared first on StackStorm.

Feb 10, 2017
by Siddharth Krishna

Want to install StackStorm on a machine that doesn’t have access to the internet? If you’ve got another box on your local network that connects to the public network, you can do this by making it a local package repository server. In this post, we’ll walk you through steps for setting up an apt-mirror server with the required packages and configuring the offline client machine to quickly get a full StackStorm installation up and running!

Note: We are using Ubuntu on the mirror server and therefore going with apt-mirror in the example here. You can build a local Yum repository in case you are running RHEL/CentOS.

Setting up the Mirror

1) Let’s assume that you already have an apt-mirror server with packages for an Ubuntu distribution in place: see an example guide here. As part of this, you would need to install the apache web server as well. It’s used to make the repositories accessible from the client machine (ST2 installation target) over HTTP.

2) The following packages should be made available on the local package repository for a complete installation of StackStorm (including Web UI, Chatops etc.):

• ST2: https://packagecloud.io/StackStorm/stable/ubuntu/
• Mongodb: http://repo.mongodb.org/apt/ubuntu trusty/mongodb-org/3.2
• Nodejs: https://deb.nodesource.com/node_6.x
• Nginx: http://nginx.org/packages/ubuntu/

Add the custom repository URL details for these packages to the apt mirror.list file on the server.

sudo vi /etc/apt/mirror.list
..
deb https://packagecloud.io/StackStorm/stable/ubuntu/ trusty main
deb http://repo.mongodb.org/apt/ubuntu trusty/mongodb-org/3.2 multiverse
deb https://deb.nodesource.com/node_6.x trusty main
deb http://nginx.org/packages/ubuntu/ trusty nginx

deb-src https://packagecloud.io/StackStorm/stable/ubuntu/ trusty main
..

3) Update the mirror to download the required packages on the local mirror:sudo apt-mirror

Directories for each of the new packages should get created inside the apt-mirror base path (set base_path):

/aptmirror/mirror/packagecloud.io/StackStorm/stable/ubuntu/
/aptmirror/mirror/repo.mongodb.org/apt/ubuntu/
/aptmirror/mirror/deb.nodesource.com/node_6.x/
/aptmirror/mirror/nginx.org/packages/ubuntu/

Making the Repos Accessible

4) Configure the webserver on the local mirror to make the repositories accessible over HTTP from the client machine by creating symbolic links to each of the repos in the /var/www/html/ directory.

brocade@apt-mirror:/var/www/html$ ls -l
total 0
lrwxrwxrwx 1 root root 46 Jan  9 04:29 mongodb -> /aptmirror/mirror/repo.mongodb.org/apt/ubuntu/
lrwxrwxrwx 1 root root 44 Jan 10 02:30 nginx -> /aptmirror/mirror/nginx.org/packages/ubuntu/
lrwxrwxrwx 1 root root 46 Jan  9 04:29 nodejs -> /aptmirror/mirror/deb.nodesource.com/node_6.x/
lrwxrwxrwx 1 root root 47 Jan  9 04:29 st2 -> /aptmirror/mirror/packagecloud.io/StackStorm/stable/ubuntu/
lrwxrwxrwx 1 root root 44 Jan  9 02:44 ubuntu -> /aptmirror/mirror/archive.ubuntu.com/ubuntu/

Restart the web server: sudo service apache2 restart

Verify the repository directory structure in web browser: http://local-mirror-ip/

Setting up the Offline Client System

5) Modify apt sources to point to the local mirror server for all packages – Ubuntu, ST2, MongoDb, NodeJS and Nginx. Replace mirror with the hostname or IP of the local mirror server:

sudo vi /etc/apt/sources.list

Comment out (#) all existing content and replace with the following:

deb http://mirror/ubuntu/ trusty main restricted universe multiverse
deb http://mirror/ubuntu/ trusty-security main restricted universe multiverse
deb http://mirror/ubuntu/ trusty-updates main restricted universe multiverse

deb http://mirror/st2 trusty_stable main
deb http://mirror/mongodb/ trusty/mongodb-org/3.2 multiverse
deb http://mirror/nodejs trusty main
deb http://mirror/nginx trusty nginx

Update package information: sudo apt-get update

GPG Key Errors?

At this point you might hit some GPG signing errors for the custom packages on the client:

The following signatures couldn't be verified because the public key is not available: NO_PUBKEY

To fix this, do the following:

On Server:

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv
sudo apt-key export > exportedkey

Move the exportedkey file to the client.
Note: In case you are facing errors for multiple keys, you may use the following instead:

 sudo apt-key exportall > exportedkey(s) 

On Client:

sudo apt-key add exportedkey(s)

Retry apt-get update

6) All required packages should now be downloadable from the local mirror server using sudo apt-get install –y command. The one-line installation process won’t work for this system. You’ll need to follow the manual install steps documented here. Or better yet, use something like Ansible to configure your system. Note that you do not need to setup any custom repositories on the client system. We have already done this by pointing apt towards the local repository server. Install the dependencies directly using sudo apt-get install –y st2|st2mistral|mongodb|nginx|nodejs|st2chatops instead.

What Next?

You should now have StackStorm running. Verify the installation. Since its in offline system, the usual pack install process won’t work on it. One of the ways of working around this is to use an HTTP proxy. In a follow-up blog I’ll show you how to set that up.

The post Installing StackStorm on Offline Systems appeared first on StackStorm.

Feb 27, 2017
by Lindsay Hill

Here’s a nice way to start your week: StackStorm 2.2 has been released! Mistral updates, Jinja in Mistral workflows, Jinja in complex objects, new st2 login and st2 whoami commands, security improvements and more! Our release master put in some hard work over the last few days to get this out the door. Read on for more details.

Jinja Enhancements

You asked, we’ve delivered: You can now use Jinja expressions in Mistral workflows, wherever YAQL expressions are accepted. This lets you do things like manipulate the input & output data structures, perform boolean logic, and and conditional logic for evaluating and transforming data. Each expression should be encapsulated with {{ }}. Here’s an example that shows how to work with environment variables:

Read the docs, and check the examples for more info.

Also: You can now nest Jinja variables inside array and object types.

Don’t worry though: YAQL is not going anywhere. It’s still there, and will continue to have first-class support, for those need its power and type support.

Mistral Updates

As you know, we use and contribute to the OpenStack Mistral service for complex workflows in StackStorm. With this release we’ve updated our fork to the latest master branch. We’ve been wanting to do this for a while, as it brings us stability improvements, weeds out some corner-case deadlocks, and delivers performance enhancements. Thanks to Renat and all the crew for the good work they’re doing.

CLI Authentication helpers

Want to authenticate to ST2 using the CLI, but don’t like storing your password in plaintext in your config file? Check out the new st2 login command. This is an easy way to login and cache your authentication token. Just run st2 login st2admin --password Ch@ngeMe.

This also gives you a quick way to switch user. Need to check which user you’re logged in as? Use the new st2 whoami command to check!

Security Hardening

We’ve been doing some housekeeping, and we’ve tightened our default settings used by our installer script:

• MongoDB now only listens on localhost, and creates two new users admin and stackstorm. The stackstorm user only has access to the st2 database.
• RabbitMQ now only listens on localhost.
• PostgreSQL only listens on localhost (this was already a default on some distributions).
• Mistral now uses a random password for PostgreSQL authentication.

This further reduces the default attack surface. If you’re doing a manual install of StackStorm, be sure to read the new Security section.

Miscellaneous Fixes and Improvements

The usual collection of smaller changes:

• Validation of trigger parameters and payloads is now available. You will need to enable the system.validate_trigger_payload and system.validate_trigger_parameters options to use it – it is disabled by default. Thanks to Hiroyasu Ohyama for the contribution.
• We now support MongoDB 3.4. The installation script will still install 3.2 by default, but you are welcome to move to 3.4. In future we will make 3.4 the default version.
• RPM packaging fixes: The logrotate and LDAP configurations will no longer be removed on RPM upgrade.
• st2 pack install will now work with git repositories that do not use master as the default branch.

Upgrade Warnings

We previously warned that the system and user Jinja variable notation for accessing system and user scoped datastore items inside workflows and actions is going away and be replaced by the new st2kv.system and st2kv.user notation.

Well, that time has arrived. Now you really do need to update your actions and workflows to use the new scoping notation.

The database schema for Mistral has changed. The executions_v2 table is no longer used. The table has been broken down into workflow_executions_v2, task_executions_v2, and action_executions_v2. There is currently no migration script to move existing records from executions_v2 into the new tables. If you really need to read from executions_v2, either use psql or install an older version of the python-mistralclient.

As always, full changelogs are here, full upgrade notes are here, and we are always available to help on our Slack channel. Sign up here.

The post StackStorm 2.2 is up! appeared first on StackStorm.

Catch us at the sold out SRECon17 Americas event at the Hyatt Regency in San Francisco. We’ll be at booth #16 ready for your questions, suggestions, and to share our latest integrations. The event runs from March 13 through March 14. See you there!

The post StackStorm at SRECon17 (Booth 16) appeared first on StackStorm.

Mar 03, 2017
by Dmitri Zimine

Hey, it’s Dmitri here, back from Scale15x with a short report of what I enjoyed the most.

My talk It was a bit symbolic for me. I spoke at Scale13x, comparing and contrasting Enterprise Suites and OpenSource, and stated the free pillars of “Designed for DevOps”:

• OpenSource
• Infrastructure as code
• Social coding and collaboration

In my talk this time, I reported back on how we put these three principles in practice with StackStorm, redefining Runbook automation for the time of clouds and Devops. The core of the talk was a live demo of StackStorm, auto-remediation, and ChatOps. Thank you who came for my talk on this late Sunday afternoon and gave me warm welcome and great questions. For the rest, here are the the slides and the video recording.

The sessions: they were were numerous, diverse, and mostly very good, ranged from compiling Linux kernel to political aspects of IoT data collections by municipalities. Video footage already posted to Scale youtube channel. I liked more than you have time to read about, note just a few:

Joe Smith from SlackHQ presented SlackOps Automation Framework – welcome to Auto-remediation club and looking forward for you sharing more at our AutoRemediation meetup, hopefully soon!

Nate DAmico and Rich Pelavin @ reactor8 – the authors of DTK – gave some insightful sessions. Rick talked on “Declarative Management vs Procedural Workflows” at rare depth of insides, Nate gave a non-superficial overview of container technologies, placed some bets of who’s gonna win the arms race, and dived into serverless frameworks.

Serverless is on top of everyone’s mind. It prompted me to make a new “StackStorm is like…”: I am convinced that StackStorm is a fair contender in Serverless space and can do at least as much as OpenWhisk, with all due respect to IBM folks. The topic is worth a dedicated blog, stay tuned.

The Expo: RedHat booth attracted folks with geeky little micro racks of R-Pi’s and Intel Galileo Gen 2’s running k8s. I learned about Atomic, the immutable OS, and re-learned what is OpenShift now, which is not what it was before. For those who like me missed the memo – it represent RedHat’s open and total shift from VMs and OpenStack to containers and K8n.

The people: Meeting with like-minded folks is the best part of any good conference, and scale15x was good to me. Fortunate to connect with the founders. Nice to meet Alexey Vladishev(@avladishev), the founder of Zabbix – hope this turns into partnership thanks to StackStorm’s synergy with monitoring tools , Great to hear Kohsuke Kawaguchi “Hackers Gotta Eat: Building a Company Around an Open Source Project”: the author of Jenkins shared the story of his journey from a hobby side-kick to the iconic CI/CD tool. A thoughtful and insightful talk on striking the right and fair balance between open source purity and lessons to to make the projects survive and sustain. A topic near to me as we lived the shared struggles to strike same balance, and left me thinking what’s the future sustainable model for open-source utility tools.

Overall, great conference. It grew tremendowsly in the past years, yet it still has this spirit of freedom activism keeping OpenSource what it is. Hat’s off for organizers – nearly invisible themselves, they managed to set it up perfectly and created this great atmosphere of diversity, breadth, depth, geekiness, and courage of intellectual inquiry.

For StackStorm, the main take-aways is “people get it when they see it”. We have built the right platform, that solves real problems, but have much work to do to make you folks aware of the awesome automations you can build with StackStorm. Have ideas for those automations to solve your problems? Join us – ping the team and community on Slack and let’s do it together.

The post Notes from Scale15x appeared first on StackStorm.

March 15, 2017
by Edward Medvedev

The majority of StackStorm packs are created and submitted by our community. While we do code reviews and give advice, it is our users that helped us reach over 100 integrations.

But a lot of people do not just stop there. Even after submitting packs, they are continuously putting effort into keeping the codebase up to date, reviewing contributions, and helping others. This effort does not go unnoticed—and in the recent post about StackStorm Exchange we have announced that we will be granting pack maintainers full collaboration rights in the Exchange repositories. We are happy to introduce the first maintainers, together covering around 20 packs.

Pulsant

Packs: AlertLogic, CloudFlare, Duo, HP Enterprise ICSP, Networking Utils, OpsGenie, Orion, VMWare VSphere

The Pulsant team—Jon Middleton, Paul Mulvihill, and Grant Mitchell—have been StackStorm users and enterprise customers for several years now, and there’s not too many people who would have more experience with StackStorm integrations.

Among their contributions are integrations with VSphere and Duo Security—with the latter being featured in one of our Automation Happy Hour podcasts.

Anthony Shaw

Packs: Dimension Data, Yammer, OctopusDeploy, Cisco Spark, SignalR, Qualys, PowerPoint, Tesla

Anthony Shaw, Director of Innovation at Dimension Data, is mentioned in at least 20% of the posts in this blog. He contributed a wide variety of packs and integrations, from Cisco Spark to communicating with your Tesla car, and even hosted a spontaneous StackStorm User Group Meetup in London.

Watch Anthony talk DevOps at the recent Auto Remediation meetup.

Hiroyasu Ohyama

Packs: AWS

Hiroyasu is taking the helm of our AWS pack: the single largest pack we have, and one of the most widely used. If you’ve contributed to the AWS pack or kept track of issues and PRs, you have probably seen his comments—his expertise and continuous help with code reviews made this decision very easy.

For Hiroyasu’s team, StackStorm has replaced an in-house operations platform that was becoming less and less cost-effective as the company grew.

Lisa Bekdache

Packs: Datadog

Lisa is working in the Engineering Infrastructure Team at Dailymotion. She is the creator and maintainer of the Datadog integration pack with over 50 different actions, and a long-time StackStorm user along with her colleague, Carlos, who is a core StackStorm contributor.

The Dailymotion team is using StackStorm to automate routine actions, respond to monitoring alerts, and perform system upgrades over hundreds of bare-metal servers in production.

Pearson

Packs: Kubernetes

The Bitesize team at Pearson is working on a Kubernetes PaaS, using StackStorm to integrate third-party services. They have come up with a way to generate a StackStorm pack with actions and sensors for most of the Kubernetes features: that’s an astounding 365 actions and 33 sensors to date!

To learn more about StackStorm with Kubernetes, watch the amazing Kubernetes integration with StackStorm talk by Peter Idah.

We feel humbled and very grateful to see so many people in the StackStorm community putting their precious time and effort into helping each other. In turn, we are committed to giving back and helping as much as we can—from providing community support and code reviews to building a platform that is easy to use and contribute to.

Love and hugs all around. ❤️️

Lastly, if you would like to submit a pack or help with maintaining a pack that is already featured in the Exchange, reach out to us in Slack!

— Ed

The post Introducing pack maintainers appeared first on StackStorm.

March 23, 2017
by Matt Oswalt

StackStorm was proud to once again exhibit at SREcon this year in San Francisco. If you haven’t attended SREcon before, there’s really no better place to get in touch with so many SRE professionals that are pushing the envelope and redefining what it means to run a modern operations team.

This year, we brought a quite nifty, flashy demonstration that one of our core developers Matt Stone put together, involving Raspberry Pis, LEDs, and – of course – StackStorm! (He’s @BigMStone on twitter – tweet at him and tell him to write his own blog post on his creation – it’s really cool!)

SREcon 2017 Takeaways

This was my first SREcon, and hopefully not my last. I was very pleased at not only the high concentration of talented operations professionals, but also the quality of discussion held throughout the two day conference.

One of the things I noticed right away was the sheer number of attendees who just “got it”. I’ve spent a fair amount of my career advocating for more automated, modern approaches to operations, specifically within network infrastructure. Whenever dealing with new technologies or processes, it’s understandable that not everyone is on the same page, so it’s often useful to spend some time level-setting about the problem space.

However, at SREcon, this was very rarely necessary. Nearly everyone we spoke to was already convinced that concepts like “infrastructure as code”, and “event-driven automation” were useful, and was already looking to practice them. They were clearly dealing with challenges that required these new ways of running operations, and were beyond thinking about the problem – they wanted solutions.

The StackStorm “Sweet Spot”

One very common conversation with the audience at SREcon was the subject of where StackStorm fits in the rapidly changing world of operations. We think there are plenty of great tools in the monitoring space, and StackStorm integrates with them – we don’t try to act like a monitoring tool. Similarly, there are some really great configuration management tools out there, and we integrate with those as well. What we like to do is fit right in the middle.

Perhaps the best way of looking at this is to think about your own built-in procedures. I worked in operations, I know there are a multitude of things that an operations team must deal with each day – some planned, some not. For each of these things, there’s almost always a predetermined way of dealing with it. Log in to monitoring system. Analyze logs. View dashboards. Correlate information. Update configs. Restart services. This is a day in the life of an operations professional.

The StackStorm answer, then, is a simple one – commit those workflows to code. Whether it’s writing an Action metadata file so you can get started using your own scripts in StackStorm, or writing full-blown Mistral workflows to automate an entire remediation process, there really is no magic involved here – it is a matter of committing into “code” the same analysis, decision-making, and remediation you’d normally perform yourself, and letting StackStorm perform these tasks on your behalf.

This area of discussion resonated greatly with the audience at SREcon, and it’s clear that if you haven’t explored event-driven automation yet, the time has never been better to get started.

Event-Driven Automation Meetup

Fortunately for those in the Bay Area, StackStorm and LinkedIn are putting on the next Event-Driven Automation Meetup in Sunnyvale next week. These meetups are great because they focus on the same kind of things I like to focus on, which is the general ideas and concepts behind event-driven automation, with less of a focus on specific implementations. While there’s always a time and a place for getting into the technical weeds, it’s often useful to take a step back and talk about trends, and collaborate on what’s around the corner.

I will be flying in from sunny Portland to sit on the panel – but don’t let that discourage you…I hope to see you there anyways!

Matt Oswalt

@Mierdin

The post StackStorm at SREcon 2017 appeared first on StackStorm.

April 5, 2017
by Lindsay Hill

StackStorm 2.2.1 has been released, incorporating the usual array of improvements, bug fixes, and this time a BWC-specific security update. Read on for details.

Pack Management Fixes

• If the config schema specified default values, but you didn’t create a config in /opt/stackstorm/configs/, Python actions & sensors never got those default values. Whoops. Resolved. Workaround: Create a pack config file.
• The pack configs API endpoint was not working when RBAC was enabled. Fixed now.
• Config schema validation might not be performed upon registration, which could result in bad or empty config schemas. It is now working as expected.

BWC LDAP Security Fix

While working on some LDAP improvements, we found a potential security exposure in the BWC LDAP Authentication backend. If the requirements were that a user was a member of all three groups x, y, z, then BWC may have allowed access if a user was a member of only a subset of those groups – e.g. if the user was only a member of groups x and z. This has been resolved, and tests added to check for this condition in future. We encourage users to upgrade. This only affects BWC (StackStorm Enterprise) users who use LDAP, and have authentication policies that require users to be a member of multiple groups.

Miscellaneous Fixes & Improvements

• Updated tooz library (v1.15.0) means you can now use backends such as Consul and etcd for coordination.
• The st2ctl reload command now preserves the exit code from st2-register-content. So if your content registration fails, your scripts will properly detect it.
• Nginx has been updated to remove support for medium-strength ciphers in the default configuration. You can always add them back in, if you’re some sort of monster who only uses the StackStorm Web UI from IE 7 on Windows XP. The rest of us will happily use stronger encryption without noticing any difference.
• The st2-run-pack-tests tool now works directly out of box on servers where StackStorm was installed using packages. In addition to that, the stool no longer installs all the global pack dependencies when they’re already available.

As always, full details are in our Changelog.

Upcoming Releases

This will probably be the last 2.2.x version that gets shipped. We are working on 2.3 right now, which is going to include a new API (with docs!!), and LDAP group -> RBAC role synchronization. More upcoming features include the new packs view in st2web, and oauth2 support. Thanks Peter! Not sure if those last two will make it into 2.3 or the next version after, but they won’t be far away.

The post Bugs, fixes, security updates: It’s ST2 2.2.1 appeared first on StackStorm.

Apr 11, 2017
by Matt Oswalt

If you’ve been paying attention to the news around new StackStorm integrations, you may have noticed the NAPALM pack was created a few weeks ago. For those unfamiliar with NAPALM, it’s a Python library that provides a multi-vendor abstraction layer for interacting with network devices like routers and switches (for those not working in the network industry, you can think of NAPALM as “libcloud” for your network).  This is really useful for doing network automation, because it means you only need to write a script (or a StackStorm action) once, targeting this library, and it’s immediately usable against the 10+ network vendors supported by NAPALM (a list that is growing all the time).

This provided a great opportunity for us to bring event-driven automation into the network space in a big way. We started developing a pack for this, and the community really ran with it. community member Rob Woodward responded to our initial pull request with a bunch of new actions and workflows that covered a huge portion of the functionality in the NAPALM library. This was merged a few weeks ago, and while we’re still considering the pack to be in the “beta” stages for now, this made a huge step towards mature multi-vendor network automation with StackStorm. Thanks, Rob!

The presence of this pack means the worlds of multi-vendor network automation and event-driven automation are finally coming together. NAPALM already provides a lot of great features on its own, such as vendor-agnostic retrieval of operational data (like routing and neighbor tables), as well as pushing configuration changes to network devices. What’s really exciting about linking this up with the event-driven automation of StackStorm is that we can now trigger these activities in response to interesting events elsewhere, such as in your network monitoring system.

Check out the pack’s README for a full summary, but I’ll spoil a few of the goodies that are currently included in this pack:

• Rules to automatically react to common network events, like a topology change, or a configuration update
• Actions for retrieving network state, like ARP, BGP, and IPv6 neighbor tables, as well as actions for making changes, like running one-off commands, or installing full or partial configurations

Also, we’re not just talking about a handful of actions; right now the NAPALM pack supports just about everything that is exposed by the NAPALM library itself!

Again, all of these features are inherently multi-vendor because of the NAPALM library. If you want to use the “get_lldp_neighbors” action to retrieve LLDP neighbors on a Juniper firewall, and use the retrieved info to create a BGP configuration and push to a Cisco router using the “loadconfig” action, that’s now possible!

Checking Configuration Consistency

Ever since the very first version of the pack was published, we’ve been thinking of ways to add to the pack, specifically focusing on problems that network engineers have to solve every day, in an effort to make their lives easier. One important challenge in any network, especially when starting to automate, is the task of ensuring the network is configured the way you think it is.

To that end, we recently added an action to the NAPALM pack called “check_consistency”. This action will connect to the network device you specified, using the NAPALM library, and retrieve its configuration. Then it will compare it to a “golden configuration” that you’ve stored in a Git repository, and let you know if there are any deviations.

Oh, and it’s chatops-enabled, so you can do all this from the comfort of Slack or HipChat! Check out the video below for a quick walkthrough of this specific feature:

This is just one example of what you can do with the NAPALM pack. We’ll be producing all kinds of interesting network automation demos with this and related functionality, all aimed at improving the operational capabilities of the network engineer.

We’re not finished – this pack is going to get a lot of love in the near future, so if you have any interest in network automation, put it through its paces and let us know what you think! For those that are either already sold on NAPALM, or are already using it, but haven’t gotten into StackStorm yet, check out our StackStorm Overview to become familiar with the concepts and get started! If you want to know more about NAPALM, check out the project’s Github page.

Happy automating!

The post Ensuring Network Configuration Consistency with StackStorm + NAPALM appeared first on StackStorm.

Apr 21, 2017
by Warren Van Winckel

At long last, the official StackStorm Docker image is available on Docker Hub! Now you can skip the installation hurdles and jump right into evaluating StackStorm, or building automations faster than ever.

Hello! I’m Warren, one of the newest members of the StackStorm team, and maintainer of the new StackStorm/st2-docker Github repo.

You’ve been asking for StackStorm as a Docker image for a long time. We’ve asked you to use our images, which have served us well internally for our package and build infrastructure. But you deserve something better. Something built especially for you, the user. Here it comes!

This official image is simple for quick evaluations; convenient for building automations, yet solid enough for light-to-medium production use.

We invited our community docker experts into the #docker channel on StackStorm Slack community (you’re welcome to join!) and we are thankful for everyone’s passionate input. Special thanks to Bruce Smith and Shu Sugimoto, who have their own implementations and ideas on how to build a docker image for StackStorm. These repositories helped us get going, and ensure we didn’t stray too far from what the community desired.

Why Docker? You know it already, but if you insist, I’ll state the obvious:

• Runs consistently across instances, and various host operating systems.
• Build images once, deploy same image to dev, staging or production.
• Uses less resources than VM’s such as Vagrant, allowing for denser consolidation.
• Decouple infrastructure requirements from the application environment.

Our current focus is on creating an image that is useful to perform an evaluation of StackStorm in the matter of a few minutes. By design, this image also makes it easy to develop and maintain packs. Let’s jump right in.

How To Use

To give it a quick try, clone st2-docker, and follow the samples in README.md.

  $ git clone https://github.com/stackstorm/st2-docker

Usage is expressed in the docker-compose.yml file for readability. You can run it as is, or translate to Kubernetes, Swarm Stack, or your favorite orchestration service definition format.

Here are some of the highlights of our StackStorm image:

• Quick, consistent installation. If you’re just trying StackStorm for the first time, no more troubles like “It doesn’t install for me”. If you’re already using Docker, no heart burn on “oh gee, I need to Dockerize it” – it’s all done for you.
• It’s ready to go with defaults, but can be configured to fit your needs; explore the Dockerfile to see what you can configure by passing the environment variables.
• We map an additional pack directory to the host filesystem and refer to it in the StackStorm configuration (https://docs.stackstorm.com/packs.html#under-the-hood-pack-basics), making it convenient to use your favorite tools to write your StackStorm automations. System packs and the packs from exchange still install under /opt/stackstorm/packs inside the container.

The Future

This is just the beginning. We continue to rapidly improve the implementation and adapt to feedback.

There are many use cases for dockerized StackStorm, and we we know there’s no “one size fits all” solution. For instance, for heavy production loads, a multi-container solution might be a better fit. There are different options for placing Mistral. And for some, even a smaller all-in-one container may be desirable. This work is ongoing.

Are you more inclined to try StackStorm in a Docker container now that it is officially supported? Are there any use cases that we have not considered? We’ve created a #docker channel in our Slack community. That’s probably the best way to contact us, but no matter how you do, we’re looking forward to hearing your thoughts, suggestions, and concerns.

Strong opinions are welcome in the form of a PR. Please start submitting issues against st2-docker. You will have an influence on how things are implemented.

Let’s continue doing amazing things together!

The post Official StackStorm Docker Image is Here! appeared first on StackStorm.

May 4, 2017
by Dana Christensen

The world runs on open infrastructure. At the OpenStack Summit, you’ll learn about the mix of open technologies building the modern infrastructure stack, including OpenStack, Kubernetes, Docker, network automation and more. From integrating legacy applications, to self-healing clouds, robotics and network automation the StackStorm open source event driven automation platform provides DevOps teams a powerful, flexible, and reliable solution to take your cloud to the next level. Be sure to stop by the StackStorm booth to meet the StackStorm team, and learn how you can integrate the StackStorm event driven automation platform with your OpenStack cloud

StackStorm at OpenStack Summit Boston Highlights:

– Booth: D26

– Booth Demo: Robot actions controlled by StackStorm event driven automation

– Presentations:

• StackStorm “If-This-Then-That” for DevOps Automation, Monday May 8th, 1:30 pm. Hynes Convention Center-Level 2-Marketplace Theater. Presented by Dmitri Zimine, StackStorm
• StackStorm-We Destroy Our Production CI Server Multiple Times a Day Tuesday May 9th, 2:45 pm. Hynes Convention Center-Level 2-Marketplace Theater. Presented by Matt Stone, StackStorm
• Serverless on OpenStack with Docker Swarm, Mistral and StackStorm Wednesday May 10, 9:00 am. Sheraton Boston Hotel-2nd Floor-Grand Ballroom. Presented by Dmitri Zimine, StackStorm

The StackStorm team is looking forward to seeing old friends and making new ones as we gather to share best practices and learn innovative approaches to delivering applications in the cloud.

Designing, deploying, and managing OpenStack, with an ever increasing number of components, services, and tools to choose from, is a complex process. With event-driven automation, StackStorm provides an elegant solution for greater resiliency, adaptability and auto-remediation of your OpenStack deployments.

The topics above just scratch the surface of StackStorm capabilities. In fact, one of the greatest strengths of StackStorm is its community- with over 2000 integrations to date. Check out StackStorm Exchange – home to dozens of integrations with most of tools you already know and use.

Stop by to see us at the booth and let’s unleash your imagination on how you can include StackStorm in your overall OpenStack automation strategy. If you know us—you know we’re passionate about event-driven automation. And if you are not already a Stormer, you will be… once you see all the cool things StackStorm can do.

We look forward to seeing you in Boston!

The post StackStorm at OpenStack Summit Boston 2017 appeared first on StackStorm.

May 15, 2017 by Eugen C. (@armab)

As you may know, previously we announced availability of Ansible production-friendly playbooks to install & configure StackStorm for cases when our demo bash installer wasn’t sufficient.

With the new release github.com/StackStorm/ansible-st2 v0.7.0 you can do even more!

This version includes new bwc and st2chatops roles, features like passing settings to st2.conf, enhancements to use custom SSL certificate for st2web, more documentation use-cases, some breaking changes and of course, bug fixes.

ChatOps

StackStorm ChatOps is rocking, but it wasn’t available as a playbook. Now you can configure ChatOps via Ansible with the new st2chatops role. Thanks to stormer Anirudh Rekhi, you can do this:

  - name: Install st2chatops with "slack" hubot adapter
    role: st2chatops
    vars:
      st2chatops_version: latest
      st2chatops_hubot_adapter: slack
      st2chatops_config:
        HUBOT_SLACK_TOKEN: xoxb-CHANGE-ME-PLEASE

^^ So slick!

StackStorm Enterprise (BWC)

Our own Lakshmi Kannan has a serious case of FOMO, and didn’t want to miss the fun others were having with Ansible. So he created a new bwc role.

Here is an example to customize Brocade Workflow Composer (BWC) with LDAP auth backend and RBAC configuration to allow/restrict/limit different StackStorm functionality to specific users.

That’s the power of StackStorm Enterprise:

- name: Install StackStorm Enterprise
  hosts: all
  roles:
    - name: Install and configure StackStorm Enterprise (BWC)
      role: bwc
      vars:
        bwc_repo: enterprise
        bwc_license: CHANGE-ME-PLEASE
        bwc_version: latest
        # Configure LDAP backend
        # See: https://bwc-docs.brocade.com/authentication.html#ldap
        bwc_ldap:
          backend_kwargs:
            bind_dn: "cn=Administrator,cn=users,dc=change-you-org,dc=net"
            bind_password: "foobar123"
            base_ou: "dc=example,dc=net"
            group_dns:
              - "CN=stormers,OU=groups,DC=example,DC=net"
            host: identity.example.net
            port: 389
            id_attr: "samAccountName"
        # Configure RBAC
        # See: https://bwc-docs.brocade.com/rbac.html
        bwc_rbac:
          # Define BWC roles and permissions
          # https://bwc-docs.brocade.com/rbac.html#defining-roles-and-permission-grants
          roles:
            - name: core_local_only
              description: "This role has access only to action core.local in pack 'core'"
              enabled: true
              permission_grants:
                - resource_uid: "action:core:local"
                  permission_types:
                    - action_execute
                    - action_view
                - permission_types:
                  - runner_type_list
          # Assign roles to specific users
          # https://bwc-docs.brocade.com/rbac.html#defining-user-role-assignments
          assignments:
            - name: test_user
              roles:
                - core_local_only
            - name: stanley
              roles:
                - admin
            - name: chuck_norris
              roles:
                - system_admin

Massive thing for our enterprise customers. Community users, you can request a trial license here and try it now!

Configure st2.conf & mistral.conf settings

With the new st2_config var it’s possible to adjust any st2.conf configuration setting by passing a dict of values to the st2 role, like this:

  - name: Install st2, configure with external MongoDB and RabbitMQ
    role: st2
    vars:
      # https://github.com/StackStorm/st2/blob/master/conf/st2.conf.sample
      st2_config:
        auth:
          enable: True
        database:
          host: st2-remote-mongo-node
          port: 27017
          db_name: st2
          username: st2
          password: random-password123
        messaging:
          url: amqp://st2:st2@st2-remote-rabbitmq-node:5672/

The Mistral role var st2mistral_config works in the same way.

Super helpful long-waited feature!

This will be especially beneficial for those wanting to configure StackStorm with external services like RabbitMQ, MongoDB. We’ll focus on HA-friendly deployments more in next releases, see for example: ansible-st2/issues/17.

Custom certificate for st2web

By default we generate a self-signed certificate for nginx in st2web role. That’s good just to try it out, but doesn’t work well in real-world production deployments.

If you have a custom, signed SSL certificate, you can pass it now:

  - name: Configure st2web with custom certificate
    role: st2web
    vars:
      st2web_ssl_certificate: "{{ lookup('file', 'local/path/to/domain-name.crt') }}"
      st2web_ssl_certificate_key: "{{ lookup('file', 'local/path/to/domain-name.key') }}"

One more step forward to production-friendly configurations.

Installing behind a proxy

If you are installing from behind a proxy, you can use the environment variables http_proxy, https_proxy, and no_proxy in the playbook. They will be passed through during the execution.

Thanks John Hogenmiller for sharing his discoveries and providing the documentation example:

---
- name: Install st2 behind a proxy
  hosts: all
  environment:
    http_proxy: http://proxy.example.net:8080
    https_proxy: https://proxy.example.net:8080
    no_proxy: 127.0.0.1,localhost
  roles:
    - st2

Community

I would like to additionally thank our power user Hiroyasu OHYAMA who contributed really nice feature requests and fixes for this release. Shout out to everyone in our growing Slack community for asking questions, helping others, committing Pull Requests.

If you are aware of using Ansible with StackStorm, here is the full ansible-st2 v0.7.0 CHANGELOG.

The post Ansible playbooks to deploy StackStorm: BWC, ChatOps and more appeared first on StackStorm.

WHEN: Wednesday, May 24, 2017

WHERE: BridgePort Brewpub, 1313 NW Marshall St, Portland, OR

>> REGISTER HERE <<

StackStorm at Monitorama 2017 

StackStorm is a silver sponsor of Monitorama 2017, and we- along with our great panel from LinkedIn, Sensu, and VictorOps- are looking forward to sharing with you key insights from the show–and to help you build a map for leveraging auto-remediation to optimize your operations.

Wondering how to start your automation journey and which tasks you should automate first? Or have you started to automate, and are wondering how to take your automation to the next level?

Our panel will share how auto-remediation- creating automated workflows based on input from your monitoring systems- is a proven way to help minimize alert “noise”, minimize operations engineer burn-out, and significantly increase overall system health.

Join us for a great interactive discussion, collaborate with your peers, and generate ideas on how to take the next step in your automation journey.

See you in Portland!

Agenda:

• 6:00-6:30 Registration & Networking (plus great beer & food!)
• 6:30-7:15 Panel Discussion
• 7:15-7:45 Q & A, Interactive Conversation
• 7:45-9:00 Networking & more beer!

Panel Details:

Moderator: Brian Sherwin (Sr. SRE, LinkedIn)

Panelists (in alphabetical order)

• Nina Mushiana—Senior SRE Manager, LinkedIn
• Matt Oswalt—Software Engineer, StackStorm/Brocade; Blogger “Keeping it Classless”
• Sean Porter—original author of Sensu, Co-Founder and CTO of Sensu Inc.
• Jonathan Schwiertert—High-concurrency platform engineer at VictorOps

The post Perspectives on Optimizing Operations & Learnings from Monitorama-5/24 (Por­tland, OR) appeared first on StackStorm.

May 23, 2017
by Warren Van Winckel

Mistral Now Included

A month ago, we launched the stackstorm image. We continued working on this and now it’s, hmm… ready! Well, software is never ready so how do we mean it? The image now contains Mistral, fixed bugs, new features. You can now perform everything with StackStorm using this image. The stackstorm image now contains st2, st2web and st2mistral!

If you’re using docker-compose, the dependent services (Redis, RabbitMQ, PostgreSQL and MongoDB) are pulled from docker hub and run in their own containers. You can also use environment variables to point StackStorm at your own instances of any dependent service..

Community Maintainer

The st2-docker repository is rapidly maturing. It is no longer in daycare! We’re proud to announce today that it has even outgrown the StackStorm team, and is now maintained by the broader community.

We have an awesome community, and @shu will take on the mantle of ‘community maintainer’. He will maintain the roadmap, review PRs, and all that good stuff.

Some ideas the community has brought to the table are support for Kubernetes and high availability. However, first, we will reduce the number of assumptions we make about the runtime environment. See the roadmap for more details.

To that end, if you’d like to request a new feature, or report a bug, as always, please submit an issue.. or better yet, submit a PR with the change and we’ll make sure it gets merged ASAP!

We look forward to what st2-docker will be able to do as it gets older…

The post StackStorm on Docker Grows Up: Mistral, Community Maintainers and more… appeared first on StackStorm.

May 30, 2017
by Warren Van Winckel

We have updated the PagerDuty pack to use the “pypd” library, maintained by PagerDuty. Previously we were using the “pygerduty” library, maintained by DropBox. Key point to note is that “pygerduty” uses version 1 of the PagerDuty API, and “pypd” uses version 2.

We needed to update to v2 because PagerDuty will not be supporting version 1 of their API after July 6, 2017. As a consequence of the migration to the latest API, any existing Stackstorm and PagerDuty users should update their packs and configurations now. You will need to change the way some actions are called because the API has changed and some new parameters are required:

st2 run pagerduty.acknowledge_incident email=’’ ids=<incident-ids>

st2 run pagerduty.resolve_incident email=’’ ids=<incident-ids>

“<incident ids>” is a comma separated list of incident ids. Additionally, ensure the /opt/stackstorm/configs/pagerduty.yaml file looks similar to this:

api_key: T7-yQxyFzxSiy2p2vQr5
debug: false
service_key: c409912215b34511aa1814d8fa9b9d00

In the next few weeks, we will be adding additional functionality to the pack so that you can take advantage of even more features of PagerDuty.

The post PagerDuty Pack Update – API v2 appeared first on StackStorm.

June 7, 2017
by Matt Oswalt

The team here at StackStorm was psyched to sponsor Monitorama 2017. This was the first Monitorama we attended, and it was an interesting new take on the world of monitoring. A proper monitoring infrastructure is key crucial for event-driven automation, in order to better understand what an “event” is.

Monitorama is a fairly small conference, opting for a single speaker track instead of several talks in parallel. I found this to be a very comfortable and engaging format; the organizers did a great job of structuring the schedule so that the topics flowed organically, and even flowed into the hallway conversations. Also, because it was in Portland, a local coffee shop came and made pour-overs for everyone, so that was a nice alternative to traditional conference coffee

Naturally, the conference focused on monitoring, but I noticed two strong common themes:

• Many talks promoted a very “non-traditional” approach to monitoring. In lieu of looking at Nagios dashboards, many speakers tackled the topic from almost a data science perspective. Lots of deep-dives into mathematics and performance analysis techniques.
• There was a heavy focus on the human side of operations and being on call. This reminded me a lot of SREcon 2017. There were a lot of war stories, and perspectives into making ops lives easier through better processes.

Non-Traditional Monitoring

I come from a networking background, and when it comes to monitoring, most products in this space have historically focused on up/down monitoring – i.e. is it up or down? These days, simple metrics like that are not sufficient, and more granular, programmatically accessible telemetry is needed. This is a situation that is slowly improving, but there’s still a lot of work to do.

We’ve all seen recently, all IT disciplines have – out of necessity – had to operate closer and closer to the applications. As a result, the line where “traditional monitoring” has operated is getting blurred with things like application performance monitoring. No longer can the network engineer or sysadmin focus solely on whether their switch or server is on – they have to be able to understand how applications interact with their infrastructure, and be able to show detailed performance metrics and other telemetry on how this is taking place.

John Rauser started the conference with a message from the future – okay, not really, his goal was simply to bring the world of data science into the monitoring toolchains in use today, in his talk  “Finding Inspiration in the Data Science Toolchain”. In it, he illustrated several ways that ideas from the world of data science were having a big impact on monitoring techniques, and vice versa. For instance, some data scientists are finding usefulness in the idea of infrastructure-as-code – describing visualizations and calculations in code as opposed to a click-through GUI. In general, the idea of bringing the specialized skills of a few, and making it consumable for the masses, resonated with me greatly, and is definitely a big driver for what we do at StackStorm.

Ian Bennett (Twitter) gave a talk near the end of the last day on “Debugging Distributed Systems” that I found interesting. In it, he highlights the need for traditional sysadmin skills and more developer-oriented skills to coexist to fully troubleshoot a problem. One minute he’s talking about an optimal logging infrastructure, and the next minute he’s diving into troubleshooting application performance by looking at how the garbage collector in JVM is handling certain string concatenations.

In general, I enjoyed this fresh take on monitoring. There are a lot of interesting ideas and tools that are just starting to take shape in this space, and I came away from these talks inspired with new ideas for StackStorm sensors to write in order to connect this advanced logic with some sweet auto-remediation workflows.

The Changing Culture of Operations

Alice Goldfuss gave a lively talk about the need for change in the culture of operations and being on-call. This was a very useful look into the way operations are traditionally run, and their impact on human beings. She did a good job of mixing real talk about what’s wrong, what’s right, and some funny stories along the way. There were some good ideas presented here – one that impacted me greatly was the need to stop viewing pages as a metric of success. I had many discussions later this week about this topic, especially as it pertains to StackStorm, since the whole idea of auto-remediation is to never have to solve the same problem twice. When encountering an outage, troubleshoot it, fix it, then write a workflow that incorporates all that logic into “code” – a workflow that performs these same steps on your behalf next time. Bottom line: don’t take pride in the fact that you get paged – work to reduce the number of times a human needs to be engaged to solve a problem.

These ideas and more – such as the need for developers and operations to work more closely – really hit home for me, and I would recommend this talk for anyone, whether or not you consider operations your primarily role.

Auto Remediation Meetup

I was pleased to participate in a panel at the first meeting of the Portland chapter of the Auto-remediation meetup. This not only served as a great (and audience-interactive) discussion of automation and monitoring, but also a good recap of Monitorama 2017 (this took place the last day of the conference at a local brewpub). I highly recommend you watch the video, there were a lot of great audience questions (that we hopefully answered):

Conclusion

It was clear that Monitorama’s audience leaned heavily towards the “ops” side. This kind of mix is no stranger to me, as I’ve been going to these kind of conferences for a few years. However, unlike traditional IT conferences, where applications or developer types are despised (for the most part), Monitorama definitely took a more positive approach – opting instead to work better with developers; even borrowing tools and ideas from the world of software in order to work more efficiently. This was greatly comforting to me, since I’ve been advocating for this approach in the world of networking for a few years.

I am excited for next year’s Monitorama, and am hoping we’ll be back as a sponsor next year. There’s a LOT to talk about at the intersection point between monitoring and automation, and I feel strongly that StackStorm can provide a lot of value as monitoring makes this transition into the world of data science.

The post Monitorama 2017: Data Science, Discussions, and Deep Dives appeared first on StackStorm.