We have one FLOW implementation, and I want each of my projects to have
its own AMI server. Our projects are local to an office, each has its
own local storage so the AMI server should be local as well. We will
store the AMI server name on a field on the project e.g. project.sg_ami_server.
So project “A” might be served by “melbourne_ami.echidnafx.com”.
So project “B” and “C” might be served by “perth_ami.echidnafx.com”.
Since FLOW has only one AMI table, we would need to have the URL field be
calculated, e.g. CONCAT(project.sg_ami_server, “/api/v1/do_render”).
For project “A” you get “melbourne_ami.echidna.com/api/v1/do_render”
For project “B” or “C” you get “perth_ami.echidna.com/api/v1/do_render”
However, this is not possible because on the AMI page, the URL field is a
Text, not a Calculated field. If it worked, it would dynamically route to
the server specified for the project.
Is there way to have one AMI server per project?
Is there a way to change the type of a built-in field (e.g. Text to Calculated)?
I believe you can restrict AMI records by project, so you could have multiple entries for the same AMI script but each with a different URL and then link project A to the melbourne ami and B and C to the perth ami.
Thank you Kim for the suggestion, and we have 253 AMI entries for our Melbourne studio.so I didn’t want to duplicate each of them for Perth. I was hoping I could do some CONCAT string manipulation in the URL field to save me replicating all the AMI entries.
Another possibility is for all the AMIs to point to one server (primary) which examines the request, edits it based on parameters such as project name and maybe some other fields then forwards the request to the appropriate secondary server located at the target studio.
We could always set up a separate FLOW instance which would allow two AMI tables and two servers, but you loose the synergy of having all projects in one place.
Thanks again, Kim, for your reply. I think that duplicating AMI entries would work for a studio with fewer entries.
One option is to make the duplication using python - a script that automatically copies all AMIs for all servers, and adjusts the url accordingly.
Another option is to perform some dispatch locally - the AMI is executed on the calling machine, which then reroutes the request, depending on the project the AMI was run from.
Third option, not sure how it would work, is to have custom DNS resolving, which uses Flow information. The AMIs then point to a single address, and the magic is in resolving that address.
DNS could also be done locally in the dns server on that site.
sg-ami.mystudio.com would then route to the correct server for that site.
This only works if your dns is locally administrable.
Another way would be for the sysadmin to alter the hosts file on the network machines to hardcode the pointer of a “fake” dns name.
There are many many options here.
But if you are dealing with 253 ami’s I would really start to think about a good infrastructure to support that cross site, and in the best way possible.
If your ami’s don’t do anything other than connect to Sg or other webservices then you could just host them somewhere or host them in one studio and use something like Cloudflare Tunnels to make the endpoint accesible to the other sites without exposing the ami endpoints to the general internet.
Thank you everyone for the very useful suggestions. We’re looking at the implementation now, I’ll update this thread with what we ended up doing.
Kindly,
Here’s an update!
We plan to use a front-end server with secondary servers at each site. The front-end server receives the AMI request, and it examines the project value to determine which site to forward the request to.
Anyways, all the suggestions are workable. I think they are all the “correct answer” to my original question.
