TheThingsNetwork / lorawan-stack

The Things Stack, an Open Source LoRaWAN Network Server
https://www.thethingsindustries.com/stack/
Apache License 2.0
954 stars 302 forks source link

Revisit webhook templates asset mounting #3357

Open adriansmares opened 3 years ago

adriansmares commented 3 years ago

Summary

We should revisit our decision not to mount webhook template assets (specifically logos) as part of TTS.

References https://github.com/TheThingsNetwork/lorawan-stack/pull/1011 References this Slack conversation

Why do we need this?

While discussing the scope of #1011, we've agreed not to mount (i.e. make them available under /as/webhook-templates/logos for example) the webhook template assets as part of the stack. The reasoning here was that these assets should be hosted separately, perhaps maybe even be distributed over a CDN. A counter point to this is of course the air-gapped deployments, where no internet access is available, and the resolution there was still to leave the burden of hosting these assets on the stack operator.

However, since that decision in 2019, we've started to be more 'friendly' with our deployment options: we bundle everything under the same Docker image / AMI / CF templates nowadays, instead of the do-it-yourself approach we had initially. As such, I'd like to revisit if we still want to stand by our decision to leave the burden of hosting these pictures on the stack operators.

The main reason for this is that currently, as part of the lorawan-webhook-templates repository, all of the logo URLs are provided by the integration maintainers, and they are hosted on their premises.

As expected of this practice, one of the URLs became invalid recently, and as such we've decided we want to host them ourselves. This means that we have to edit all of our current templates, make their logo paths relative (so instead of https://example.com/logo.png, we'd have logo.png) and set the stack LogoBaseURL to an S3 bucket containing the logos.

The follow up to this is that all of the self contained deployment options basically need their own separate web server in order to show the assets. Do we still want this ?

What is already there? What do you see now?

Hosting the webhook templates assets is left to the stack operator, instead of allowing the stack to be used as an access point to the assets.

What is missing? What do you want to see?

We could fetch and serve the assets as part of the stack - this way we don't have to add a separate web server to server a dozen logos.

Environment

v3.10

Can you do this yourself and submit a Pull Request?

Yes.

johanstokking commented 3 years ago

I think it makes perfect sense to serve these from AS. We already have configuration for remote HTTP access, i.e. for webhooks.

If we tie the webhook repository to the release, we can use existing assets syncing to a CDN, but I think the feature of the webhook repository is that it's dynamic. So let's serve these from AS and don't bother too much.

adriansmares commented 3 years ago

Blocking https://github.com/TheThingsNetwork/lorawan-webhook-templates/pull/7.