Add global AWS resource prefix to settings

[markdrzy]

The quantity of Cache Policies and Origin Request Policies are strictly limited to 20 per AWS account. AWS does not provide a means to alter the quota for these resources. If you manage multiple Flux-enabled projects under one AWS account, you run the risk of exceeding your quota.

To avoid this, these resources should be created using a "global" resource prefix, so that they are shared between all Flux-enabled sites. In this update, a new settings variable called awsGlobalResourcePrefix has been added. If no global resource prefix is provided, these quota-restricted resources will be created using the standard AWS resource prefix defined in settings. With this fallback in place, backwards compatibility is maintained -- no existing users of the Flux plugin will need to alter their settings.

With the addition of a "global" scope to AWS resources created by Flux there is one item that should be considered as the plugin is updated: These global resources MUST NOT be removed by Flux when it is uninstalled. Future versions of Flux should take this into account, if a "cleanup" of AWS resources is ever introduced as a feature of the plugin.

Fixes #8

[markdrzy]

Hey Chris -

Just to be clear, this is totally up to you to implement if you want. No expectations here. Obviously if you decide not to do this, I'll have to come up with some other way to address this issue on my end. But I wanted to offer it as a potential solution in case you thought it was a good idea.

Again, really appreciate the plugin — it's been a huge help to us. We love it.

Thanks!

[dyerc]

Thanks very much for noting this issue @markdrzy and putting together a PR. Much appreciated! 👍

I've held off merging for a few days just trying to think through the best way to do this. On the one hand, both the origin policy and cache policy are the same for every Flux site. Although that might not always be the case if future features or updates change things.

A similar but slightly different way to handle this might be to have a light switch option called "Strict Namespacing". When this is enabled, everything is namespaced to the project and if it's disabled, any common resources could have a standard name such as "Flux-Cache-Policy". I just wonder if this might be more simple for users to get their heads around. What do you think?

[markdrzy]

I totally understand giving it a few days thought! I wasn't 100% pleased with my workaround, and I think your feedback here really highlights what I didn't like about it — there's really no reason for this to be yet another config variable. You're right, this can be more conveniently exposed as a toggle switch in the AWS or Advanced Settings tab in the Control Panel.

Use Strict Resource Namespacing When this setting is enabled, all AWS resources created by Flux will use the defined AWS Resource Prefix. When disabled, common resources will use a global namespace.

If you wanted to have an extended description of why this option is available, you could truncate the description in the control panel like so:

Use Strict Resource Namespacing When this setting is enabled, all AWS resources created by Flux will use the defined AWS Resource Prefix. Learn More

Then you could use something like to following in your documentation:

Use Strict Resource Namespacing When this setting is enabled, all AWS resources created by Flux will use the specified AWS Resource Prefix. When disabled, common resources will use a global namespace. Certain resources in AWS are limited by quotas that can't be modified. To avoid exceeding these quotas when multiple Flux projects share the same AWS account, these resources are created using the global namespace by default.

Final thought: I'm sure you've considered this, but I would caution against making any updates that would require project-specific resources that are also subject to a hard quota. We're hitting this now because we're maintaining two environments per-site (staging & production). But even if we moved to enabling Flux in production only, that would effectively limit us to only 20 Flux-enabled projects. And we certainly hope to have more than 20 in the long term.

Thanks for your thoughtful reply! Let me know if you want to connect further to talk it over.

[dyerc]

I have implemented a slight variation of the changes within this PR in commit b6c0e5daf61016fdad6fb1fda8b886be6a3c475a