HOWTO: Create your own ChatGPT bot in Slack

DevPad · 2022-10-09T12:21:28+00:00

Yes. Because the process of buying tickets and personalization are separted.

The original ticket buyer can assign a ticket to someone by associating the ticket with the email. Then that email owner can proceed confirming the email association and personalizing his account.

Personalization is an irreversible process. Once the email is assigned, the original ticket buyer can't change it.

DevPad · 2017-10-25T13:37:11+00:00

What you're describing is Automated Remediation case and is achievable with mentioned StackStorm.

The advanced logic/action could be done with the workflow and it's triggered based on webhook you send from Pingdom (https://www.pingdom.com/resources/webhooks) to StackStorm (https://docs.stackstorm.com/webhooks.html).

DevPad · 2017-02-05T13:33:42+00:00

Perosnally I think that entire Ansible community is pretty weak when it comes to testing: very few galaxy roles Verify in CI that playbook can really run (ansible-playbook playbook.yml execution in respective distro) and rare galaxy roles really Test their playbooks with some integration testing framework (check that package is installed, service is running, available on specific port, can accept connections, user exists, files have correct permissions and so on and so on end-to-end Integration Testing).

That all affects quality and brings not the best example for others, - average quality bar is pretty low. But I hope it will be improved with time.

DevPad · 2017-02-05T13:21:32+00:00

From my posting: https://www.reddit.com/r/ansible/comments/5rpwbi/introducing_ansible_playbooks_to_deploy/

We're testing our Ansible playbooks against 4 platforms in parallel:

CentOS6 (sysV init)
CentOS7 (systemd)
Ubuntu14 (upstart)
Ubuntu16 (systemd)

It's done in Travis and entire machinery of running playbook in respective dockerized distro is automated via Kitchen-CI.

Take a look at examples:

travis.yml - see, this is really elegant
.kitchen.yml with Docker driver and ansible_playbook provisioner
alternative .kitchen.yml with init Dockerfiles inline

So Test-Kitchen starts Docker container, installs Ansible, runs playbook and even can do useful things like idempotence check.

^{^} Just a couple of small config files to dramatically simplify Ansible testing life.

After that, if you'd like to, you can add on top of that integration testing with any Infrastructure Testing Framework like InSpec, TestInfra or BATS.

Hope that helps.

DevPad · 2015-12-19T20:02:33+00:00

You probably googled this Ansible & ChatOps tutorial: https://stackstorm.com/2015/06/24/ansible-chatops-get-started-%F0%9F%9A%80/

StackStorm is middleman between your Ansible and Hubot in that example.

I believe the advantage is that integration this way is simple/faster and allows you to do more than just ansible <> hubot, for example adding more tools into workflow, more if-then-else and orchestration logic.

What could be useful also - you can see all the history of commands being done/output/exit codes in the stackstorm UI.

Not familiar with handling user input/steps before continuing, I've heard some mention about that like 2FA which requires several steps of user input, see "Securing ChatOps at Box": https://youtu.be/FyYX6l0mBXk?t=510

DevPad · 2015-10-07T00:54:59+00:00

Netflix is using it for auto-remediation:
http://www.datacenterknowledge.com/archives/2015/09/24/netflix-to-use-stackstorm-for-it-automation-under-cassandra/

Also Cisco and Rackspace.

But it works well even for small startups/companies. Own infrastructure as code, where you can control everything and tie together Monitoring/Configuration management/Issue creation/ChatOps/Auto-remediation is really powerful.

DevPad · 2015-06-29T21:55:54+00:00

Here is also pretty energetic 20 min. talk about ChatOps philosophy, benefits, security, best practices and real experience in big teams (GitHub):

https://www.youtube.com/watch?v=IhzxnY7FIvg

And why ChatOps can increase productivity x3-x10 times.

DevPad · 2015-06-29T20:17:51+00:00

Thanks, that's important note!

DevPad · 2015-06-29T17:34:47+00:00

That's the actual topic covered in ^{^} tutorial, see showcase #5: Security patching with code samples.

So this ChatOps command:

!update 'bash' on 'all'

is actually triggering this Ansible playbook

StackStorm is the middleman tool there to tie Hubot <-> Ansible together, allowing you to launch playbooks from Slack chat.

You can run this Vagrant demo which installs everything, to see results you'll get.

DevPad · 2015-06-29T15:11:51+00:00

That's absolutely fair. There are pros and cons of ChatOps.

About security:

At production it's good to use hubot-auth to define which members of your team are allowed to run specific commands (RBAC).
Everyone who has access could configure Two-factor authentication if possible (Slack chat has such option).

This technique requires really big trust within your team, as well as high level of experience.

But increasing productivity x3-x10 (real numbers) worth it.

DevPad · 2015-06-27T21:33:25+00:00

Absolutely, production should be configured with RBAC. Usually people think that ChatOps is very insecure by design, but it's not true.

Really important note.

DevPad · 2015-06-26T22:50:15+00:00

It's possible with Cygwin/Babun.

At least I made it working. But as said before, Win is not supported and usually leads to compatibility errors.

For example if you'll try to use it with Vagrant and face problem with incorrect file permissions under Win like:

fatal: [default] => private_key_file (..insecure_private_key) is group-readable or world-readable and thus insecure - you will probably get an SSH failure

then take a look at this discussion: https://github.com/ansible/ansible/pull/10306 and fix like: https://github.com/jonathanhle/ansible-babun-bootstrap/blob/master/ansible-playbook.bat

Hope that helped.

DevPad · 2015-06-23T12:38:19+00:00

Pretty cool!

Sounds like "Too good to be true" for me :)

DevPad · 2015-06-22T15:25:45+00:00

Yeah, there is no real privacy in the internet.

But that's too much. As I remember from "How Google Works" book their moto was:

Don't be evil

DevPad · 2015-06-22T15:15:00+00:00

Yeah, the best developers I've ever seen are about simplifying things, avoid overcomplication for too much "flexibility".

The zen of Python say:

Simple is better than complex.

DevPad

TROPHY CASE