Hi Magnus. This is currently unplanned by us for our road map. Some context and feedback for you on this.
First, to do the replication itself to the secondary region you need RU/s sufficient to support the request rates for the primary region itself. Replication and writing to the secondary region itself is not free so there needs to be sufficient throughput provisioned to do that.
Second, for the secondary region to be able to function as the primary should a fail over occur, the replica region itself needs sufficient throughput to function as the primary.
Thanks again for your suggestion. Will mark as unplanned for now in case circumstances ever do change.
We are working on this but do not have an ETA for this yet. Will update here as we get closer to releasing.
Thank you for your suggestion.
For any questions, please reach out to us at AskCosmosDB@microsoft.com
Azure Cosmos DB is a multi-model database service, and therefore supports accessing the same underlying data using any/all APIs. We are however implementing some platform-level changes to make data access from different APIs seamless like supporting conversions between disparate type systems, and capabilities.
Is there any update that can be made on the status of this? Or at least a description of what is currently supported and what's not?
So often you are required to open multiple browser tabs to various different services and blades within the Azure Portal at the same time. it would be nice if the Azure Portal supported tabs more natively.
Here's 2 suggestions on how tab support could work:
- Add ability to open links within the Azure Portal in a new browser tab when desired.
- Add mutli-tab support to the Azure Portal UI / UX itself so you can have multiple blade views open simultaniously.
The reason for this request:
When managing production workloads it's often the case where you need to monitor multiple services, and/or make configuration changes in multiple places. It's extremely cumbersome to keep navigating around the Portal between resources, especially when you need to go back and forth between multiple resources.
There are many times when you need to keep, for instance, an App Insights Live View open, while making database queries to an Azure SQL Database, and checking the trigger status of Azure Functions when monitoring and troubleshooting.
This would be more a limitation of the Solidity language, and not Azure Blockchain Workbench itself. And Solidity does support enums and structs.
4 votesChris Pietschmann shared this idea ·
We want to add this as well.
A personal assistance would be great within the Azure Portal. Perhaps, clippy should be brought back and added to the Azure Portal to help us manage our cloud resources even easier. Maybe you could also rename Cortana to Clippy and give it a happier more helpful voice and personality as well.
In September 2014, Microsoft announced plans to deliver Azure from datacenters in India. You can read more here: https://www.microsoft.com/india/datacenter/
Isn't this one already completed?
This request is for custom domain and custom SSL certificate support for the IoT Hub endpoint. This work is currently unplanned for IoT Hub but we’re listing to customer requests and may chose to support this in the future.
If you have interest in have a deterministic way of understanding your IoT Hub IP address (and corresponding geo-pair IP address) in order to keep firewall rules up-to-date, see and vote on this request: https://feedback.azure.com/forums/321918-azure-iot/suggestions/15714243-iot-hub-network-address instead.
SSL only requires multiple IPs when the client is on Windows XP, using an older version of Internet Explorer. Most modern browsers support SNI (Server Name Indication) and thus don’t require multiple IPs.
Support for multiple IPs is under review in the team.
I completely agree with Carl. While this idea sounds good on the surface, it would really end up increasing Microsoft costs of running the service resulting in higher prices. People are already complaining about Azure prices being too high. If you want to donate "unused CPU cycles", then install that stuff on your own computers and leave them running 24 hours a day.
This would provide for a security hole in the system. You can't trust any other subdomain at cloudapp.net any more than you trust any other random website. It's most secure for you to map your own custom domain or subdomain to your *.cloudapp.net url and then install your own SSL certificate for your site to use.