[BUG] Autoscale definition for App Service is missing namespace and requires re-saving from Portal

[JosXa]

Describe the bug Using infrastructure code similar to the example implementation for a Linux App Service plan, the app with its scale rules deploys successfully to Azure, but cannot in fact autoscale due to errors. I can see 'Metric Failure' events exactly 4 hours after deployment as follows: 'Autoscale has not been able to read monitoring data for resource '[my-app-plan]' since '[4 hours ago]' UTC. The capacity will be adjusted when Autoscale successfully reads monitoring data for your resource'.

A potential cause might be the missing metricNamespace field in the definition of the scale definition, as can be observed from the JSON tab in the Azure Portal. What fixes it, is to open the scale rule and to manually save it once more after initial deployment:

To Reproduce / Code Snippet The exact code I used is as follows:

            var scaleSettings = _azure.AutoscaleSettings.Define("autoscale")
               .WithRegion(region)
               .WithExistingResourceGroup(rg)
               .WithTargetResource(appServicePlan.Id);

            var profile = await scaleSettings.DefineAutoscaleProfile("metrics-scale")
               .WithMetricBasedScale(7, 30, 12)
               .DefineScaleRule()
               .WithMetricSource(appServicePlan.Id)
               .WithMetricName("CpuPercentage")
               .WithStatistic(TimeSpan.FromMinutes(2), TimeSpan.FromMinutes(2), MetricStatisticType.Average)
               .WithCondition(TimeAggregationType.Average, ComparisonOperationType.GreaterThan, 37)
               .WithScaleAction(ScaleDirection.Increase, ScaleType.ChangeCount, 5, TimeSpan.FromMinutes(5))
               .Attach()
               .DefineScaleRule()
               .WithMetricSource(appServicePlan.Id)
               .WithMetricName("CpuPercentage")
               .WithStatistic(TimeSpan.FromMinutes(5), TimeSpan.FromMinutes(2), MetricStatisticType.Average)
               .WithCondition(TimeAggregationType.Average, ComparisonOperationType.LessThan, 33)
               .WithScaleAction(ScaleDirection.Decrease, ScaleType.ChangeCount, 1, TimeSpan.FromMinutes(2))
               .Attach()
               .Attach()
               .CreateAsync();

Expected behavior

There does not appear to be a .WithMetricNamespace builder method before or after the .WithMetricName, nor is there a field for this property in the inner model. Therefore, I'd expect this scale rule to work out of the box, but it does not.

Setup (please complete the following information):

• OS: Deployed from Windows 10 to Linux App Service P2V3 plan
• IDE : Rider
• Version of the Library used: 1.38.0

[JosXa]

I am also in contact with Microsoft support to verify whether the missing metricNamespace is in fact the root cause. I will update the issue accordingly.

[JosXa]

Project to reproduce: https://github.com/JosXa/MSReproduceScaleIssue

[weidongxu-microsoft]

For .NET, the development focus has shifted to the next generation of Azure SDKs which follows the new SDK guideline and introduces a set of important new features. Those new packages are currently in preview state and we are actively working on making it production ready. You can visit this link here to see the latest .NET packages: https://devblogs.microsoft.com/azure-sdk/october-2020-management-ga/

We have also published a few blog posts on why we are doing this: https://devblogs.microsoft.com/azure-sdk/introducing-new-previews-for-azure-management-libraries/

With this background, .NET Fluent is currently in a low maintenance mode, and we mostly do security and bug fixes. It is subject to deprecation in the future when the new set of .NET packages become Generally Available (GA). Please let us know if there are further questions, thanks!

[JosXa]

@weidongxu-microsoft when these libraries are ready, will we lose the fluent style of declaring Azure resources? I really enjoyed creating these infrastructure-as-code projects for all our services and would be really sad to see this pattern go...