Thank you for the strong feedback on this request. We will share our plans for this in the coming weeks. Thank you for your patience!
We’re currently evaluating an option that will provide the functionality offered by nested groups, but removes the complexity nested groups adds. We appreciate your patience on this ask and want to ensure we deliver a solution that benefits all of our customers. Below are use cases that we’d like for you to stack rank, with #1 being priority for you. We thank you for the continued comments and feedback.
Use case A: nested group in a cloud security group inherits apps assignment
Use case B: nested group in a cloud security group inherits license assignment
Use case C: nesting groups under Office 365 groups
119 votes17 comments · Azure Monitor-Application Insights » Web tests · Flag idea as inappropriate… · Admin →
With the release of Azure Functions 2.0, the previously posted template no longer works.
However, we recognize the need for this request, and are actively scoping and prioritizing the work needed to make it happen.
I am very interested in speaking with anyone who needs this feature to learn more about your scenarios, particularly any information around cost issues. If you would like to help me scope this feature, please reach out: firstname.lastname@example.org.
Suppression of alerts during maintenance now available in Azure Monitor, as part of Action Rules (preview): https://docs.microsoft.com/azure/azure-monitor/platform/alerts-action-rules
An error occurred while saving the commentJonG commented
In any proper SDLC, the Development, QA, PerformanceLab and Prod subscriptions would properly NOT have the same instance size (small in Dev, small or Medium in QA, and larger in Perf and Prod); if for no other reason than pre-production cost savings (not a trivial thing with many teams, projects, etc). The fact that changing the instance size for Cloud Services can only currently be accomplished by unpacking and repacking the CSPack file at deploy time is, for lack of a better term, functional broken. In addition to requiring custom pre-deployment scripts and utilities to accomplish this modification, it also means the package being deployed to different environments will actually be different (dissimilar MD5 hashes for deployed packages within the same SDLC); which, regardless of the subtleness of the change, this is unacceptable in many companies.
We are likely to support this in phases. Stay tuned for more details.
This is something we’re thinking about, but would like to ensure that we’re providing a sufficiently robust set of capabilities within the template language syntax itself.
What scenarios are “overly complicated and hard to maintain”? This will help us understand where we need to invest.