March 22, 2016
by Anthony Shaw of Dimension Data
I’m “pretty excited” to share some news, we’ve just finished integrating Cisco Spark into StackStorm, via our automation-bot, Hubot.
This means you can get all of the power of StackStorm chatops from within Cisco Spark rooms and collaboration experiences.
Cisco Spark delivers cloud-based business communications that enables customers to message, meet and call anyone, whether it be on their mobile device, desktop or meeting room end-points.
StackStorm is an event-driven automation platform that ties together every component of your environment. It’s commonly used for auto-remediation—including response to security events—and other cases such as complex deployments.
If you don’t already have a Cisco Spark account, you can sign up at www.ciscospark.com.
Once you have signed up, go to developer.ciscospark.com and sign in, then you should be able to generate a key
February 15, 2016
by Jon Middleton, Optimisation Project Lead @ Pulsant Limited
In the post StackStorm QuickTip: ChatOps your pack dev workflow James Fryman gave a ChatOPS alias recipe to reduce the friction for deploying packs and then in the Random Thoughts section asked:
This action is tied directly to the
packs.install. What about a workflow? Seems like that would be a better way to structure this.
This resonated with me as I had already started working on an internal pack that did just that, as I thought attempting to deploy a pack via an alias (and action) contained within the same pack would be madness (or just lead to interesting race conditions). In the last week, our Pull Request has been merged, documentation has been included in st2docs (link) for a workflow that fulfils the above random thought and should be released with 1.4.
So introducing packs.deploy, an action written in Mistral to handle the mapping of names for Git repositories to the information required to carry out the packs.install action.
February 8, 2016
by Edward Medvedev
Less than a week ago Microsoft announced a plan to activate Yammer — its corporate social network — for every customer with Office 365 subscription. Yammer will be seamlessly turned on for everyone with a business or education account over the next two months, which means more and more people will rely on it in their daily communication. Pretty exciting!
If you’re a long-time StackStorm user, chances are you already know what’s going to happen. After all, we only write articles with words like “pretty exciting” in them when we have something great to show, and this one is no exception: today we’re proud to announce ChatOps integration with Yammer for both Community and Enterprise editions of StackStorm!
If you’re new to ChatOps, it’s a chat-centric way to enable or extend DevOps — especially when based upon StackStorm. With the help of our powerful rules engine, workflows, and more, you can execute actions from your chat app of choice, keep it visible for your team, and grow your automation patterns over time. Naturally, our own blog has a lot of articles on the topic, like the recent On Force Multiplication and Event-driven Automation by James Fryman.
February 4. 2016
By Manas Kelshikar
We have always wanted StackStorm to be much more transparent than older run book automation systems so that users trust it – so they allow StackStorm to do more and more of the work such as quashing 2am pages via auto-remediation.
Recently we’ve added some capabilities that further increase StackStorm’s transparency.
This post focuses on a few features that help follow the breadcrumbs of an event-driven automation. It specifically provides ways to answer the questions –
- Why does this rule not work?
- What did StackStorm do with the event that it received?
We will put these question in context of a StackStorm Auto-remediation. The example for this blog will use StackStorm to auto-remediate an application that at times has poor API response times. The cast for this plot will be StackStorm as the guardian and protector, Sensu as the watcher and an application that must be brought back to the light when it starts erring in its ways.
We will specifically demonstrate the use of st2-rule-tester as well as what we call Trace Tags. As always in these kinds of “tutorial” blogs – we include the actual StackStorm content.
February 3, 2016
By James Fryman
Recently, I have found myself reflecting on the statement “Be a force multiplier”. This usually comes to mind when faced with some sort of burn-out: hearing in indirectly from a colleauge or friend, or experiencing it first hand. The intent is good and aligns well with some core tenants of DevOps. Force multiplication fits into the DevOps ethos by encouraging the need to cross-train and collaborate. By working together and sharing knowledge about respective domains (Development or Operations), team members gain empathy for each other. This in turn has a downstream effect of now enabling better collaboration around the repair/growth/operation/expansion of the delivery pipeline.
The only challenge that I have seen over and over again is that by the time that this idea of “force multiplication” is needed in a team, one or more major bottlenecks exist. These bottlenecks are often real and a result of an imbalance of resources. Servers arriving faster than there are resources to rack/stack/configure/turn-up. DBAs cannot handle the number of schema changes needed to be reviewed/tested/deployed. Developers must wait on a certain person or persons who have access to publish a package before it can “go live”. You probably have your own bottleneck that you see very clearly in your own mind.
January 29, 2016
by Dmitri Zimine
Fellow automators, we are happy to announce StackStorm 1.3. In this “Holiday release” (yes most of the work took place around the holidays) we took a break from “big features” and focused on addressing key learnings from extensive field usage, turning feedback from our expert users, and our own take aways from internal StackStorm use, into practical product improvements. The highlight of the release is a long-awaited ability to restart a workflow from a point of failure. We have been pushing it through for quite a while, first in upstream OpenStack Mistral, than exposing it via StackStorm, and now it’s ready for the prime time. With other highlights – making it easier to debug rules, track complex automation executions, and keep the history size under control – 1.3 release is a major step up in making StackStorm performant, operational and convenient.
Read on to learn about release highlights and what is coming up next. To upgrade, follow this KB.
January 29, 2016
By James Fryman
Originally published at http://devops.com/2016/01/29/unifying-applications-into-one-system
Let’s talk about a real problem that all of us have faced at one point or another: keeping track of a single thread of work across many disparate tools. Regardless of the specific industry a company operates in, as a company grows, back-office applications in support of the business begin to accumulate. Many knowledge based companies have some sort of communication tool, some sort of project tracker, and some support tracker. These are tools that aim at being more effective with daily business process. Conversations suffice until they do not, and tools are implemented as the need arises. Every tool that was added has purpose, solves a critical need, and made you and/or your team more productive.
At some point however, this changes. Discovery starts to become a major issue as usage patterns between different tools leaves solos of data. It becomes hard to correlate the different company pipelines that ultimately drive your business: the pipeline to care and communicate for customers, the pipeline to deliver new features, and the human interfaces involved in each. This is only intensified by team members that work on different project with different tools and people, you introduce team members from a timezone not your own, the sheer quantity of work… how many ways can you name how not just conversations are lost, but context
by James Fryman
Happy Monday! In today’s StackStorm quick tip, we are going to show you a way to rapidly test and deploy packs. This technique pairs a StackStorm action, packs.install, and an Action-Alias that we will create to allow users to rapidly test and deploy new ChatOps commands for themselves.
Let’s just dive in!
January 21, 2016
by Igor Cherkaev aka eMptywee
Originally published at http://emptywee.blogspot.com/2016/01/stackstorm-and-chatops-actions-with.html
Before moving to Openstack integration I’d like to post a short article about highly demanded feature, which is going to be implemented and supported natively out of the box by StackStorm one day, – Chatops Action Confirmation.
In short, some actions, requested from chatops, may indeed be dangerous and typo errors or incorrectly entered values may harm your system or lead to unexpected, unpredictable and undesirable results. That being said, it would be really nice to ask the user who issued the command to confirm his or her intentions to execute it.
So for now we have to do it on our own. And I’ll tell you what – it is not really difficult. We will examine two chatops aliases and I will elucidate on the things happening under the hood when these aliases are triggered.
January 07, 2016
by Igor Cherkaev aka eMptywee
Recently I’ve been playing around Stackstorm – a platform for integration and automation of day-to-day tasks, monitoring events, existing scripts and deployment tools.
I am going to explain how easy it is to wrap your daily tasks into Stackstorm actions and workflows and how to provide a simple way of execution for complex tasks.
I’ve been thinking for a while and initially I was going to bring everything up in one blog post. But later, it didn’t seem like a good idea. That being said, I’d rather break it into multiple posts, no matter how many there would be. Anyway, it seems to me that it’d be more practical and easier to read and understand.
Let’s start with integrating Nagios alerts into Stackstorm. Assuming that you already have Stackstorm version 1.2.0+ installed, configured and running, as well as there’s Nagios running somewhere else that is capable of processing alerts and handling events. If not, please, proceed to www.stackstorm.com and www.nagios.org (installation and initial configuration of these two tools is beyond the scope of this post). Both tools are open source and free to use and have extensive documentation on installation and basic configuration.
First of all, I was happy to find an existing Nagios integration pack on StackStorm community repo, but my joy ended really quickly as I found it not working. Secondly, this StackStorm tutorial helped me to get started.
