Terraform: Feature request: add a Slack provider

[luisdavim]

Hi,

Since we already have a PagerDuty provider I think it would be cool to also have a Slack provider, this way we could automate some integrations like PagerDuty to Slack or other monitoring tools.

For example, at the moment I'm working on a module to deploy the infrastructure for sensu and one of the things we need is to create a slack channel and set up a webhook to get a url to pass it to sensu and at the moment that is a manual step and we pass the previously created slack webhook url as a variable to the module.

Thanks,
Luis

[stack72]

Hi @luisdavim

Thanks for the feature request - I was thinking about this just yesterday and will see what I can do in my spare time :)

Paul

[luisdavim]

Awsome. Thanks.

[luisdavim]

I found this https://github.com/nicholasjackson/terraform-provider-slack but it looks like it only handles users. I would be more interested in creating channels and integration webhooks.

[juniorplenty]

Esp integration webhooks

[lisfo4ka]

+1
It would be very usful for our project too. We need to integrate it with sensu.

[nbering]

I have a meta-question about this issue. Since providers have been moved out of core, where are discussions about new "official" providers to take place? If there is a place, I suggest this discussion be closed and moved there. With providers not being part of core build this type of issue is no longer relevant to this repository.

[apparentlymart]

Hi @nbering, and everyone!

Now that the 0.10.0 release is out and things are starting to settle down under a new development process, we're in a better position to address this question.

As the set of Terraform providers has grown we've found it challenging to ensure the desired level of quality and support across them all, and so we are beginning to be more cautious about which providers we bring into the HashiCorp releases repository to reduce the risk of plugins becoming neglected over time and creating a bad experience for users and potential contributors.

HashiCorp remains committed to either directly supporting or working with partners to support all of the _existing_ providers, but moving forward we want to have a good plan for how each new provider will be maintained, and ideally have its respective vendor directly involved in its development to reduce the risk of design errors or dead-ends.

For this provider in particular, this means that we'd prefer to work directly with representatives of Slack or, if necessary, outside contributors that are able to commit to maintaining the provider as new contributions are submitted and as Slack changes its platform. We realize that this is a lot to ask of community contributors, and so we've assumed that the direct vendor support probably the only feasible path for most providers at this time.

We've started to document the process for adding new providers that are co-maintained by their respective vendors and HashiCorp, in _Terraform Provider Development Program_. This is a rather "heavy" process that is honestly optimized mainly for the "big" cloud providers that are Terraform's main use-case, so I'll be the first to acknowledge that it's non-ideal for something like Slack where the use-cases are more ancillary, despite it certainly being useful.

In the longer term we do plan to improve Terraform's plugin support to allow automatic installation from third-party sources, with the ultimate goal of allowing provider development to be decentralized without the user-experience concerns that currently leads to. We have a fair amount of foundational work to do before we can achieve that end goal, since it requires a more sophisticated plugin installer and repository system than we currently have. In this future state, Slack seems like a good candidate for a third-party-maintained provider. For now, we unfortunately don't have the resources to develop and support it in-house.

I hope this helps clarify the current situation. I understand that this is a frustrating situation, and indeed it's frustrating for us too. The size of Terraform's current provider set is already challenging our workflow, and so I hope you can all be patient with us while we get the infrastructure into place to better scale this process, so we can widen the Terraform provider ecosystem in a sustainable way. We should have more to say on this subject once the system design for it is more complete.

[kingdonb]

I think we can definitely improve on the work at nicholasjackson/terraform-provider-slack by adding webhook support.

My team has been piggybacked on a larger team's free Slack that has reached the integration limit, and we are not sure who maintains our Slack, but we have enough integrations to now justify our own free Slack.

At this point my Terraform experience has been so good that I'll go so far as to say, I don't want to migrate things from one "cloud" to another without writing a Terraform for it (so I could migrate back, when we decide to pay Slack some money, of course...)

Let's improve the state of things here, it should be easy. Many Slack integrations are just a simple webhook with single parameter.

[yn]

As an experiment in community-driven open source development, I just started a Patreon for creating and maintaining third-party Terraform providers. The first thing I would work on would be Slack Webhook integration. https://www.patreon.com/YuriNiyazov

I am vaguely qualified:

• I have contributed a minor bug fix to the AWS Terraform provider here
• I have contributed a minor bug fix to the terraforming ruby gem here

[kingdonb]

@yn good idea! and thanks for the link to terraforming, this looks like something I need.

Pledged $25 on your patron account! Cheers!

[r1williams]

+1

[cornfeedhobo]

Slack's API is fairly limited. When looking into this, I couldn't find a real-world use case that isn't extremely trivial (users and channels). All of the things I would want to automate, like enabling SSO, establishing a Bot, etc, are not exposed through the API. Please please please prove me wrong.

[jhoblitt]

If I recall, creating a bot/app via the API is something that's supposed to be coming soon.

I think that basic functionality such as creating channels, setting channel topics, channel purpose, inviting users to a channel would be useful. Note that creating a channel, setting its topic/purpose, is fairly obnoxiously 3 separate API calls.

I think it would also be useful to be able to send messages directly from tf, such as when a long provisioning process has finished.

[r1williams]

yes @jhoblitt notification is nice to have, my workflow every new resource we send notification to a slack channel.

[tdmalone]

@jhoblitt @ricardson I'm not sure notifications would make sense in Terraform.. a message isn't really a resource and there's no state to manage. Might be better to wrap terraform apply in a custom script that sends a notification on complete/error?

[jhoblitt]

@tdmalone I agree that a notification isn't going to be idempotent. In the puppet dsl, this is handled with resources that either always try to "converge" or are a noop unless they are triggered by a notification due to a change in portions of the graph upon which they depend. Common examples would be patterns that use the notify and exec types.

I think that trying to wrap tf and generate useful notifications beyond tf finished or error red, would require parsing the state json. This is certainly do-able, and I have done this in some cases (less often now that outputs can be json formatted), but it isn't exactly convenient.

One possible alternative would be to support "callback" like functionality on resources that invoked an external command or perhaps performed some sort of IPC.

[yebyen]

I personally was looking for a terraform resource that is the channel and the integration webhook for the notification (channel) itself. That is the idempotent part; you can check if the webhook already exists and matches your desired config, and then no-op (or apply the new state.)

I don't want Terraform to send notifications to Slack during the terraform apply invocation. I want Terraform to create the webhook, so that the part of my infrastructure that requires a webhook can depend on creating one through a terraform provider, and ensuring that webhook is created (or still valid) can be a part of the plan. (I am @kingdonb so) this is the relevant part of my previous post:

My team has been piggybacked on a larger team's free Slack that has reached the integration limit, and we are not sure who maintains our Slack, but we have enough integrations to now justify our own free Slack.

At this point my Terraform experience has been so good that I'll go so far as to say, I don't want to migrate things from one "cloud" to another without writing a Terraform for it (so I could migrate back, when we decide to pay Slack some money, of course...)

[yebyen]

It will depend on there being an API available for setting up Slack integrations, and I don't know if such an API does exist yet (or if it is stable.)

[jhoblitt]

AFAIK - the slack api doesn't allow automated setup of apps.

[TimDurward]

Terraform Slack Provider:
https://github.com/TimDurward/terraform-provider-slack

I've been working on a Slack provider for Terraform, currently it supports Channel creation, Channel Topics, and Channel Deletion. It's a side project of mine, but I'll add more features from time to time, feel free to open PR's.

It fully supports the Terraform Schema model, and I haven't found any bugs with it...yet, but if anyone uses it, please open an issue if you find anything odd!

[pkolyvas]

I'm going to close this out. Many thanks to @TimDurward and all the contributors that helped make the Slack provider a thing!

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.