You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Because there are multiple solutions available and people should not be forced to use certain solution, it should be possible to tell what implementation is used in Azure (or other cloud provider). It is fully possible that different solutions are available for solving the same problem with different cloud providers.
I suggest the following (as an idea, not as final implementation, should be expandable) as an extension that does not break anything or hurt anybody - optional addition to hedge.edn or resources/cloud-config.edn:
This cloud specific configuration is also required because user might want to set AWS region or Azure datacenter to something different than the hardcoded value.
Overloading must not be based on hacking and forking or handling manually the output of hedge and then uploading it to the cloud - it should be a seamless developer experience where you configure your function upfront. Other feasible option might be command line parameters for Azure: -q queue-implementation
Azure: Possibility to specify SQL (cosmosdb) or ODATA (table storage) & max fetch, target id / rowkey / partitionkey to fetch for inputs and outputs of type :table and :db
AWS: Possibility to set filtering / query on DynamoDB input
Implement cloud configuration overloading (configuration from file)
Regions / datacenters to cloud configuration overloading (configuration from file)
AWS stage to cloud configuration overloading (support in future from Azure when Slots are released)
Implement Namespaces for values i.e. :azure/northeurope
Should allow global overrides
Should allow function specific overrides
Should define if resources are created if they don't exist
Migrate azure queue-type selection from hedge.edn parsing (triggers, inputs and outputs)
Define Spec for file
The text was updated successfully, but these errors were encountered:
Because there are multiple solutions available and people should not be forced to use certain solution, it should be possible to tell what implementation is used in Azure (or other cloud provider). It is fully possible that different solutions are available for solving the same problem with different cloud providers.
I suggest the following (as an idea, not as final implementation, should be expandable) as an extension that does not break anything or hurt anybody - optional addition to hedge.edn or resources/cloud-config.edn:
This cloud specific configuration is also required because user might want to set AWS region or Azure datacenter to something different than the hardcoded value.
Overloading must not be based on hacking and forking or handling manually the output of hedge and then uploading it to the cloud - it should be a seamless developer experience where you configure your function upfront. Other feasible option might be command line parameters for Azure: -q queue-implementation
The text was updated successfully, but these errors were encountered: