text:
Port sql tests

This PR ports the SQL tests to azure_devtools.
The tests run fine with the previous recordings when I move them to the appropriate location, but due to suspected complications with my internal Azure account I wasn't able to run in live mode myself to make new recordings.
One other small change to mgmt_testcase aliases AzureMgmtPreparer.is_live to the test class's in_recording attribute rather than its is_live one. This requires a little distinction between "live mode"'s meaning in AzureMgmtTestCase, which is "the config file specifies live mode, so make new recordings for all tests" and its meaning in preparers, which is "either the config file specified live mode or we don't have a recording to draw from." In either of those cases the preparer needs to make real resources, so this fixes a previous bug where preparers wouldn't do so when they should have.

Codecov Report

Merging #1271 into master will increase coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1271      +/-   ##
==========================================
+ Coverage   54.82%   54.84%   +0.02%
==========================================
  Files        3012     3023      +11
  Lines       75844    75984     +140
==========================================
+ Hits        41578    41674      +96
- Misses      34266    34310      +44

Impacted Files
Coverage Δ

...ces/v2017_05_10/operations/resources_operations.py
58.63% <0%> (-4.9%)
:arrow_down:

...keyvault/azure/keyvault/custom/key_vault_client.py
96.66% <0%> (-3.34%)
:arrow_down:

.../azure/keyvault/custom/key_vault_authentication.py
39.02% <0%> (-2.77%)
:arrow_down:

...ql/azure/mgmt/sql/operations/servers_operations.py
37.68% <0%> (-1.01%)
:arrow_down:

...ke/analytics/job/operations/pipeline_operations.py
89.65% <0%> (ø)
:arrow_up:

...ions/express_route_service_providers_operations.py
93.75% <0%> (ø)
:arrow_up:

...017_05_10/operations/resource_groups_operations.py
97.36% <0%> (ø)
:arrow_up:

...1/operations/bgp_service_communities_operations.py
37.5% <0%> (ø)
:arrow_up:

azure-batch/azure/batch/models/exit_options.py
100% <0%> (ø)
:arrow_up:

...re-batch/azure/batch/operations/pool_operations.py
72.35% <0%> (ø)
:arrow_up:

... and 114 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 631a6c3...f45634d. Read the comment docs.

authors: codecov-io v-iam


text:
Avoid running non-2.7 and non-3.6 python versions for windows/macos CI tests

from @chlowell: "Our shared requirement for cryptography is >=2.1.4. For 2.1.4, PyPI has Windows wheels only up to Python 3.6. Now that CI runs 3.9 on Windows, mindepends must build cryptography 2.1.4 from source. This fails because the VM doesn't have the necessary build tools (for example)."
This also affects macOS.
This PR tunes the base test matrix a little bit to make sure that the python versions that land on windows are only 2.7 and 3.6. There are some overrides in the keyvault and identity CI matrices to also swap the macOS version to 3.6 and re-add the then-missing 3.7 test.

/azp run python - identity

/azp run python - identity

/azp run python - keyvault

There are more affected libraries than identity and keyvault-keys:
❯ rg -tpy "cryptography>=2.1.4"
eventhub\azure-eventhub-checkpointstoreblob\setup.py
73:        "cryptography>=2.1.4",

eventhub\azure-eventhub-checkpointstoreblob-aio\setup.py
72:        "cryptography>=2.1.4",

identity\azure-identity\setup.py
76:        "cryptography>=2.1.4",

keyvault\azure-keyvault-keys\setup.py
85:        "cryptography>=2.1.4",

storage\azure-storage-blob\setup.py
98:        "cryptography>=2.1.4"

storage\azure-storage-file-share\setup.py
83:        "cryptography>=2.1.4"

storage\azure-storage-queue\setup.py
86:        "cryptography>=2.1.4"

/azp run python - identity

/azp run python - keyvault

/azp run python - eventhub

/azp run python - storage

/azp run python - identity

/azp run python - storage

/azp run python - eventhub

/azp run python - keyvault

@benbp the pypy3 failure for keyvault was a DNS resolution failure. Intermittent and not a blocker imo.

Yep, generally things are looking pretty good, especially all the cases this PR is intended to fix.

source: gharchive/pull-request

authors: benbp chlowell scbedd

repo: Azure/azure-sdk-for-python

license: MIT

license_type: permissive

license_source: github-api


text:
[ACR] Prepare for first GA

Updates:

Renamed:
size -> size_in_bytes
TagOrder -> ArtifactTagOrder
ManifestOrder -> ArtifactManifestOrder
Updated CHANGELOG.md
Updated Development status to Production/Stable in setup.py

Changes look good as per our discussions during the API consistency review.


text:
Regression Runs Proxy prior to invoking tests

We dealt with a breaking change for running the test-proxy in CI. The problem is, the regression tests are now hitting this as well because they use the engsys at the time of writing. That would mean that the sdk-tools startup of the test-proxy will hit issues from these older branches.
An alternative is to go in and apply the proxy_startup.py patch to each old tag/branch that doesn't have this adjustment. I'd rather save myself that effort. This PR is an attempt to avoid a couple dozen manual patches.

There are a couple failing regression tests, but at least we're to the real failures, versus failures of the system. Going to override and merge this.

/check-enforcer override


text:
Increment version for cosmos releases

Increment package version after release of azure-cosmos

API change check
API changes are not detected in this pull request.


text:
[Cosmos] Fix service regressions

The service has changed some behaviors and some error messages, this PR addresses that so that our tests can pass again.

/azp run python - cosmos - tests

API change check
API changes are not detected in this pull request.

/azp run python - cosmos - tests

/azp run python - cosmos - tests

/azp run python - cosmos - tests

/azp run python - cosmos - tests

/azp run python - cosmos - tests

authors: azure-sdk simorenoh


text:
[AutoPR hanaonazure/resource-manager] Microsoft.HanaOnAzure: Remove readOnly attribute from customer-provided properties in CreateHanaInstance

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/6259

(message created by the CI based on PR content)

This PR has been merged into https://github.com/Azure/azure-sdk-for-python/pull/5808


text:
[AutoPR storage/resource-manager]  [SRP] Add Support for File Service and File Shares

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/6892

(message created by the CI based on PR content)

This PR has been merged into https://github.com/Azure/azure-sdk-for-python/pull/6382


text:
.NET branding is wrong in APIView

Nit: in APIView, ".NET" should be cased that way everywhere. I see from the "Creak issue" hamburger menu item it's ".Net".

See https://github.com/dotnet/brand

Resolved by https://github.com/Azure/azure-sdk-tools/pull/4206

source: gharchive/issue

authors: chidozieononiwu heaths

repo: Azure/azure-sdk-tools


text:
[PowerApps] Decide what information would be displayed after the SDK is released

This is to follow up with the discussion the EngSys sync up meeting.
There are a couple of thinkings.

Release pipeline would provide the link of the released SDK but for some language, it takes time to get the link of the released SDK.
Use a template to combine the information for the link of the released SDK.
Shall we provide other information like installation guide, etc

No conclusion yet, need PM's input about the scenarios.

let's work on this after collecting feedback from service parnter.

We have removed this view from the current SDK release apps so issue is no longer needed

authors: josefree lirenhe maririos


text:
Pipeline support request by Wei Hu: pipeline not triggering

As reported on email thread with subject Error of "No usable version of the libssl was found" when running autorest.csharp V2 in swagger pipeline.

The connection string of MongoDB was rotated, applied the latest value to bot Container App, issue resolved.


text:
Enable APIView approval block for .NET GA management plane packages

[ ] Documentation updates @josefree or @live1206
[ ] Release Planner update @maririos
[ ] Release pipeline block @chidozieononiwu

Release planner update:
Change is:

Deployments:

[ ] DEV
[ ] PPE
[ ] PROD


text:
Unexpected context deadline exceeded

Which version of the SDK was used?
master 197d1c0aea1b9eedbbaee0a1a32bf81e879bde80
(go get github.com/Azure/azure-storage-blob-go/2018-03-28/azblob)
Which platform are you using? (ex: Windows, Linux, Debian)
macOS
What problem was encountered?
Trying a simple example to download a file. I passed in context.Background() but got the error:
context deadline exceeded
How can we reproduce the problem in the simplest way?
Code below, credentials and blob information changed, but otherwise unchanged. I guess the blob must be big enough to trigger the deadline. In my case it was 723.75 MiB.
	credential := azblob.NewSharedKeyCredential("account", "key")
	p := azblob.NewPipeline(credential, azblob.PipelineOptions{})

	u, _ := url.Parse("https://account.blob.core.windows.net/")

	serviceURL := azblob.NewServiceURL(*u, p)
	containerURL := serviceURL.NewContainerURL("container")
	blobURL := containerURL.NewBlobURL("blob")

	log.Printf("starting")

	ctx := context.Background()
	blob, err := blobURL.Download(ctx, 0, 0, azblob.BlobAccessConditions{}, false)
	if err != nil {
		log.Fatal(err)
	}

	body := blob.Body(azblob.RetryReaderOptions{})
	defer body.Close()

	f, err := os.Create("output")
	if err != nil {
		log.Fatal(err)
	}
	defer f.Close()

	_, err = io.Copy(f, body)
	if err != nil {
		log.Fatal(err)
	}

Output:
2018/08/08 15:18:52 starting
2018/08/08 15:19:52 context deadline exceeded

Have you found a mitigation/solution?
Not as yet.

Ok, looks like I found the solution, I need to extend the TryTimeout on the Pipeline:
	p := azblob.NewPipeline(credential, azblob.PipelineOptions{
		Retry: azblob.RetryOptions{
			TryTimeout: 5 * time.Minute,
		},
	})

This seems to work, but is a little unexpected. I'm not sure if this could be made more obvious in the docs or error message?

The pipeline includes a retry policy which places a per-try timeout on each request. I suspect that you are downloading a large file, perhaps over a slow network, that is causing the timeout.
Try adjusting the per-try timeout via the PipelineOptions. An example is shown here: https://godoc.org/github.com/Azure/azure-storage-blob-go/2018-03-28/azblob#example-NewPipeline
-- Jeffrey Richter (watch Architecting Distributed Cloud Appshttps://aka.ms/RichterCloudApps on YouTubehttps://aka.ms/RichterCloudApps or edXhttps://aka.ms/edx-devops200_9x-about)

From: Jeff Williams notifications@github.com
Sent: Wednesday, August 8, 2018 6:22 AM
To: Azure/azure-storage-blob-go
Cc: Subscribed
Subject: [Azure/azure-storage-blob-go] Unexpected context deadline exceeded (#60)
Which version of the SDK was used?
master 197d1c0https://github.com/Azure/azure-storage-blob-go/commit/197d1c0aea1b9eedbbaee0a1a32bf81e879bde80
(go get github.com/Azure/azure-storage-blob-go/2018-03-28/azblob)
Which platform are you using? (ex: Windows, Linux, Debian)
macOS
What problem was encountered?
Trying a simple example to download a file. I passed in context.Background() but got the error:
context deadline exceeded
How can we reproduce the problem in the simplest way?
Code below, credentials and blob information changed, but otherwise unchanged. I guess the blob must be big enough to trigger the deadline. In my case it was 723.75 MiB.
    credential := azblob.NewSharedKeyCredential("account", "key")
    p := azblob.NewPipeline(credential, azblob.PipelineOptions{})

    u, _ := url.Parse("https://account.blob.core.windows.net/")

    serviceURL := azblob.NewServiceURL(*u, p)
    containerURL := serviceURL.NewContainerURL("container")
    blobURL := containerURL.NewBlobURL("blob")

    log.Printf("starting")

    ctx := context.Background()
    blob, err := blobURL.Download(ctx, 0, 0, azblob.BlobAccessConditions{}, false)
    if err != nil {
            log.Fatal(err)
    }

    body := blob.Body(azblob.RetryReaderOptions{})
    defer body.Close()

    f, err := os.Create("output")
    if err != nil {
            log.Fatal(err)
    }
    defer f.Close()

    _, err = io.Copy(f, body)
    if err != nil {
            log.Fatal(err)
    }

Output:
2018/08/08 15:18:52 starting
2018/08/08 15:19:52 context deadline exceeded
Have you found a mitigation/solution?
Not as yet.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/Azure/azure-storage-blob-go/issues/60, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACK0v9IXhYt0AymsrXMA5-dTqAf4-gHUks5uOuYUgaJpZM4Vz7JM.

Hi Jeff,
I'm curious, how did you figure this out on your own?
What led you to the solution?
-- Jeffrey Richter (watch Architecting Distributed Cloud Appshttps://aka.ms/RichterCloudApps on YouTubehttps://aka.ms/RichterCloudApps or edXhttps://aka.ms/edx-devops200_9x-about)

From: Jeff Williams notifications@github.com
Sent: Wednesday, August 8, 2018 6:47 AM
To: Azure/azure-storage-blob-go
Cc: Subscribed
Subject: Re: [Azure/azure-storage-blob-go] Unexpected context deadline exceeded (#60)
Ok, looks like I found the solution, I need to extend the TryTimeout on the Pipeline:
    p := azblob.NewPipeline(credential, azblob.PipelineOptions{
            Retry: azblob.RetryOptions{
                    TryTimeout: 5 * time.Minute,
            },
    })

This seems to work, but is a little unexpected. I'm not sure if this could be made more obvious in the docs or error message?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/Azure/azure-storage-blob-go/issues/60#issuecomment-411411203, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACK0v1BmjBGB4KUhLAdU3mHAaZMERbBjks5uOuvlgaJpZM4Vz7JM.

@JeffreyRichter In case it's helpful, I ran into this today too; I was uploading a large blob, rather than downloading, and my connection was fairly fast.
I re-read the docs to find the answer; I guess at first, I hadn't realized that the timeout was a maximum bound for the entire upload operation, even if steady progress was still being made. I found this comment to be the most useful:
https://github.com/Azure/azure-storage-blob-go/blob/463a4570c8e8e8169f78de28fa8bf06eabcb78a3/2018-03-28/azblob/zc_policy_retry.go#L37-L42

I appreciate your post. If love to make this more obvious but I don't know the best course of action to take. One idea I had was to return my own error with helpful text but then it won't be a deadline exceeded error which is what go programmers would expect. Error handling in go is problematic. There are some our handling proposals for go 2 which would allow me to wrap the deadline exceeded error in my own, richer error but this would be some time in the future and if like to do something sooner.
Any suggestions?

@JeffreyRichter I missed your question - I actually had to go look at the code to figure it out.
It looks like you might be able to track whether the user's context timeout or the RetryOptions TryTimeout is used in the RetryOptions pipeline.FactoryFunc. Then respond with a specific error. But I see what you mean: at the moment you are returning a context.DeadlineExceeded error, and this would be lost.
For me at least, I would only expect to receive a context.DeadlineExceeded error if the deadline was exceeded for the context I passed in (that was what confused me in the first place). If there was some separate, well defined error for when the the RetryOptions.TryTimeout was exceeded, that would be fine for me, but I guess it might cause problems for existing clients.

This library is the best one available for Go today. Now, with the new error support in Go, we can improve the experience here. When the inner (per-try) context expires, the library can add a message to the error with helpful guidance directing you to the RetryOptions TryTimeout field letting you know what happened and how to address it.
We don't want to get rid of the per-try timeout entirely because, if a service doesn't respond, then your goroutine is just hung.
And, Go's context fully support composing contexts and we take advantage of this to make this work. In a future version of this library, we'll add the richer error support to simplify diagnosability.

Ok, looks like I found the solution, I need to extend the TryTimeout on the Pipeline:
	p := azblob.NewPipeline(credential, azblob.PipelineOptions{
		Retry: azblob.RetryOptions{
			TryTimeout: 5 * time.Minute,
		},
	})

This seems to work, but is a little unexpected. I'm not sure if this could be made more obvious in the docs or error message?

This saved my life 👍  Thank you very much.

authors: JeffreyRichter jatoben jeffw-wherethebitsroam yakuter

repo: Azure/azure-storage-blob-go


text:
Compilation Error when added dependency of FsLab

Hi,
I'm attempting to use FsLab (http://fslab.org/) to create and return HTML chart via Azure Function however I'm getting an error.
Repro steps
Provide the steps required to reproduce the problem

Create project.json with

{
  "frameworks": {
    "net46":{
      "dependencies": {
        "FSharp.Data": "2.3.2",
        "Newtonsoft.Json": "9.0.1",
        "FsLab" : "1.0.0",
        "RProvider" : "1.1.20"
      }
    }
   }
}

Wait for compilation

Expected behavior
Not error
Actual behavior
Logs:
2016-09-07T10:40:49.424 Restoring packages.
2016-09-07T10:40:49.424 Starting NuGet restore
2016-09-07T10:40:51.004 Restoring packages for D:\home\site\wwwroot\api-chart\project.json...
2016-09-07T10:40:52.837 GET https://api.nuget.org/v3-flatcontainer/http.fs/index.json
2016-09-07T10:40:54.184
2016-09-07T10:40:54.465 Packages restored.
2016-09-07T10:40:55.004 Script for function 'api-chart' changed. Reloading.
2016-09-07T10:40:56.010 OK https://api.nuget.org/v3-flatcontainer/http.fs/index.json 459ms
2016-09-07T10:40:56.010 GET https://api.nuget.org/v3-flatcontainer/http.fs/0.8.0/http.fs.0.8.0.nupkg
2016-09-07T10:40:56.010 OK https://api.nuget.org/v3-flatcontainer/http.fs/0.8.0/http.fs.0.8.0.nupkg 399ms
2016-09-07T10:40:56.010 WARNING: Detected package downgrade: Newtonsoft.Json from 0.0.0 to 9.0.1
2016-09-07T10:40:56.010 api-chart (>= 1.0.0) -> FsLab (>= 1.0.0) -> XPlot.GoogleCharts (= 1.3.1) -> Newtonsoft.Json
2016-09-07T10:40:56.010 api-chart (>= 1.0.0) -> Newtonsoft.Json (>= 9.0.1)
2016-09-07T10:40:56.010 WARNING: Detected package downgrade: Google.DataTable.Net.Wrapper from 0.0.0 to 3.1.2.0
2016-09-07T10:40:56.010 api-chart (>= 1.0.0) -> FsLab (>= 1.0.0) -> XPlot.GoogleCharts (= 1.3.1) -> Google.DataTable.Net.Wrapper
2016-09-07T10:40:56.010 api-chart (>= 1.0.0) -> FsLab (>= 1.0.0) -> Google.DataTable.Net.Wrapper (= 3.1.2)
2016-09-07T10:40:56.010 WARNING: Detected package downgrade: Deedle from 0.0.0 to 1.2.5
2016-09-07T10:40:56.010 api-chart (>= 1.0.0) -> FsLab (>= 1.0.0) -> XPlot.GoogleCharts.Deedle (= 1.3.1) -> Deedle
2016-09-07T10:40:56.010 api-chart (>= 1.0.0) -> FsLab (>= 1.0.0) -> Deedle (= 1.2.5)
2016-09-07T10:40:56.010 WARNING: Detected package downgrade: Newtonsoft.Json from 0.0.0 to 9.0.1
2016-09-07T10:40:56.010 api-chart (>= 1.0.0) -> FsLab (>= 1.0.0) -> XPlot.Plotly (= 1.3.1) -> Newtonsoft.Json
2016-09-07T10:40:56.010 api-chart (>= 1.0.0) -> Newtonsoft.Json (>= 9.0.1)
2016-09-07T10:40:56.010 Committing restore...
2016-09-07T10:40:56.010 Writing lock file to disk. Path: D:\home\site\wwwroot\api-chart\project.lock.json
2016-09-07T10:40:56.010 D:\home\site\wwwroot\api-chart\project.json
2016-09-07T10:40:56.010 Restore completed in 3206ms.
2016-09-07T10:40:56.010
2016-09-07T10:40:56.010 NuGet Config files used:
2016-09-07T10:40:56.010 C:\DWASFiles\Sites\speech-svrless\AppData\NuGet\NuGet.Config
2016-09-07T10:40:56.010
2016-09-07T10:40:56.010 Feeds used:
2016-09-07T10:40:56.010 https://api.nuget.org/v3/index.json
2016-09-07T10:40:56.010
2016-09-07T10:41:00.603 startup(2,1): error FS3053: The type provider 'RProvider.RProvider' reported an error: The type provider constructor has thrown an exception: Could not load file or assembly 'RDotNet, Version=1.6.5.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
2016-09-07T10:41:00.603 startup(2,1): warning FS3005: Referenced assembly 'D:\home\data\Functions\packages\nuget\RProvider\1.1.20\lib\net40\RProvider.dll' has assembly level attribute 'Microsoft.FSharp.Core.CompilerServices.TypeProviderAssemblyAttribute' but no public type provider classes were found
2016-09-07T10:41:00.603 startup(2,1): error FS3053: The type provider 'RProvider.RProvider' reported an error: The type provider constructor has thrown an exception: Could not load file or assembly 'RDotNet, Version=1.6.5.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
2016-09-07T10:41:00.603 startup(2,1): warning FS3005: Referenced assembly 'D:\home\data\Functions\packages\nuget\RProvider\1.1.20\lib\net40\RProvider.dll' has assembly level attribute 'Microsoft.FSharp.Core.CompilerServices.TypeProviderAssemblyAttribute' but no public type provider classes were found
2016-09-07T10:41:00.603 Compilation failed.

Warmest regards,
Garrard.

@tpetricek do the type providers expect the assemblies to be loaded in a specific way?

Yes, they do - they get loaded and called by the F# compiler. The compiler loads them from the location where the package manager puts them. The R type provider specifically, as part of the loading, registers AssemblyResolve handler and in the handler looks for R.NET (another package, also from NuGet) in "typical folders used by NuGet".
By default, it searches the path specified in ProbingLocations in app.config and we ship default config file that works for NuGet and Paket: https://github.com/BlueMountainCapital/FSharpRProvider/blob/master/src/RProvider/app.config#L4
It seems that we need to add something to the probing locations to make it use with whatever Azure functions are using. Assume I install RProvider and RDotNet from NuGet, what will be the relative path to RDotNet.dll from RProvider.dll? In Paket and NuGet, this is ../../../*/lib/net40.
For Azure Functions - based on the sample above, I would guess we need one more ../ because the version number is adding one more nested folder?
tl;dr @garrardkitchen This is a bit of a mess but we'll sort it out :) In the meantime, can you reference just the libraries you need? (Which, I suppose is FSharp.Data and XPlot?)

@fabiocav I'll be able to look into this next week - if you want more background, we actually have very detailed documentation on how this works and instructions for debugging R provider issues (As you can see, this is mostly black magic :-))

Hi @tpetricek, I will definitely try this and let you know how I get on.  Thank you for looking into this BTW. It may now be next week though before I get to this.

@tpetricek I'm moving this into Next - Triaged. CC @dsyme and @sylvanc

Hi @tpetricek, I changed my sample code to use XPlot and FSharp.Data and it compiles but I get an error when I access the uri.
error:
2016-11-03T15:41:16.428 Compilation succeeded.
2016-11-03T15:41:45.747 Function started (Id=dbad1aab-d34d-4099-8c1f-eb861d35ca14)
2016-11-03T15:41:45.747 Generate chart
2016-11-03T15:41:45.762 Function completed (Failure, Id=dbad1aab-d34d-4099-8c1f-eb861d35ca14)
2016-11-03T15:41:45.996 Exception while executing function: Functions.api-chart. XPlot.GoogleCharts: Could not load file or assembly 'Google.DataTable.Net.Wrapper, Version=3.1.2.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
2016-11-03T15:43:15  No new trace in the past 1 min(s).

run.fsx:
#if !COMPILED
#I @"../../bin/Binaries/WebJobs.Script.Host"
#r "Microsoft.Azure.WebJobs.Host.dll"
#r "System.Web.Http.dll"
#r "System.Net.Http.dll"
#r "System.IO.dll"
#endif

#r "System.Data.dll"
#r "Google.DataTable.Net.Wrapper.dll"
#r "XPlot.GoogleCharts.dll"
#r "XPlot.Plotly.dll"

open System
open FSharp.Data
open Google.DataTable.Net.Wrapper
open XPlot.GoogleCharts
open XPlot.Plotly
open System.Net
open System.Net.Http
open Microsoft.Azure.WebJobs.Host
open System.Data
open System.Threading.Tasks

type data = {
    label: string
    value: float
}

let Run (req: HttpRequestMessage, log: TraceWriter) : Task<HttpResponseMessage> =

    async {
        log.Info(sprintf "Generate chart")

        let mutable Bolivia = [("2015/2016",2);("2016/2017",2);("2017/2018",19)]
        let mutable Ecuador = [("2015/2016",6);("2016/2017",42);("2017/2018",3)]
        let mutable Madagascar = [("2015/2016",11);("2016/2017",22);("2017/2018",2)]
        let mutable Average = [("2015/2016",31);("2016/2017",3);("2017/2018",14)]

        let series = [ "bars"; "bars"; "bars"; "lines" ]
        let inputs = [ Bolivia; Ecuador; Madagascar; Average ]

        let output =
            inputs
            |> Chart.Combo
            |> Chart.WithOptions
                (Options(title = "Coffee Production", series =
                    [| for typ in series -> Series(typ) |]))
            |> Chart.WithLabels
                ["Bolivia"; "Ecuador"; "Madagascar"; "Average"]
            |> Chart.WithLegend true
            |> Chart.WithSize (600, 250)

        let res = HttpStatusCode.OK |> HttpResponseMessage
        res.Content <- new StringContent(output.Html)
        return res
    } |> Async.StartAsTask

project.json;
{
  "frameworks": {
    "net46":{
      "dependencies": {
        "FSharp.Data": "2.3.2",
        "XPlot.Plotly" : "1.3.1",
        "XPlot.GoogleCharts" : "1.3.1",
        "Google.DataTable.Net.Wrapper" : "3.1.2"
      }
    }
   }
}

Warmest regards,
Garrard.

@garrardkitchen @lindydonna @fabiocav @tpetricek @christopheranderson - We are actively looking into this bug this week.  We think nearly all the existing F# issues boil down to the one same bug (not finding assemblies at runtime which have been resolved statically)

Great! Let me know if you guys need to chat or  support with anything.

@fabiocav I've pinged you with a few questions about CI.  If we could have permission to add the full-ci tag ourselves that would be really useful, as submitting failing CI tests are the best way for us to be sure we're nailing this.

This has been partially fixed, in that FsLab is no longer problematic, and RProvider can find RDotNet.
RProvider still does not load, of course, since R is not installed. This is expected behaviour. The error message from RProvider isn't ideal, as it complains about a broken pipe rather than R not being installed.
Depending on FsLab now works.

@fabiocav @lindydonna This can be closed, per @sylvanc's comment above, thanks

Closed, thanks.

authors: dsyme fabiocav garrardkitchen lindydonna mathewc sylvanc tpetricek

repo: Azure/azure-webjobs-sdk-script


text:
Expose ServicePointManager.DefaultConnectionLimit as host setting

Repro steps
I have a C# function that triggers off of a Service Bus topic subscription and then makes ~10 HTTP calls to external services using HttpClient. The calls are made concurrently (starting the Tasks and then doing an await WhenAll() on them).
Some HTTP calls would fail with this error:
System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: An attempt was made to access a socket in a way forbidden by its access permissions
   at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
   at System.Net.Sockets.Socket.InternalBind(EndPoint localEP)
   at System.Net.Sockets.Socket.BeginConnectEx(EndPoint remoteEP, Boolean flowContext, AsyncCallback callback, Object state)
   at System.Net.Sockets.Socket.UnsafeBeginConnect(EndPoint remoteEP, AsyncCallback callback, Object state)
   at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Exception& exception)
   --- End of inner exception stack trace ---
   at System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult, TransportContext& context)
   at System.Net.Http.HttpClientHandler.GetRequestStreamCallback(IAsyncResult ar)
   --- End of inner exception stack trace ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Submission#0.<UpdateFoo>d__5.MoveNext() in :line 39

I also started receiving this toast message in the function app portal:

Microsoft.ServiceBus: Could not connect to net.tcp://********.servicebus.windows.net:9354/. The connection attempt lasted for a time span of 00:00:00. TCP error code 10013: An attempt was made to access a socket in a way forbidden by its access permissions. . System: An attempt was made to access a socket in a way forbidden by its access permissions.
Session Id: 8a9791233343447d9e0b04ba22e21412
Timestamp: 2016-10-31T05:44:21.084Z

Known workarounds
Turning down the maxConcurrentCalls in host.json to 16 appears to help (but doesn't eliminate the problem the System.Net.Http.HttpRequestException entirely). More of these exceptions and the Microsoft.ServiceBus errors happen when it is turned up to 64 or higher.
Related information
Perhaps this is related to how I use HttpClient. It is newed up as a static variable at the top of the function and not disposed. Is there a recommended way to use HttpClient in a function?

@brettsam I seem to recall you investigated a similar issue regarding service bus connection management. Does this look related?

@anthonychu  -- Are you using a Consumption plan? With a Consumption plan, you are limited to 250 connections (https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox#per-sandbox-per-appper-site-numerical-limits). When that number is hit, you'll start seeing this error.
In the other cases I've come across, this was due to the function creating a new Service Bus MessagingFactory, using it, and never closing it. Every MessagingFactory creates a single connection and won't release it until Close() is called. Using the IBinder approach to programmatically create bindings hits this also: https://github.com/Azure/azure-webjobs-sdk/issues/881.
Do you happen to be doing anything like this with your ServiceBus interactions? Would you mind sharing your code (even stripped down if you want)?
Using a static HttpClient should be alright but those 10 connections firing with each function invocation is another place to look. HttpClient has a way to throttle web calls -- where it will only allow X number of connections to a specific host before it starts queuing the requests. But I believe in Functions this number X is very high because it runs in the context of a Web app. If the ServiceBus MessagingFactory isn't the culprit, we'll take a look here.

@brettsam I was using a consumption plan. The 250 concurrent connections appears to jive with what I was seeing. If I went above 16 maxConcurrentCalls in host.json (like 32 or 64), I started getting those errors. Each triggered call generated 9-10 HTTP calls. So the math roughly adds up.
I'm not using MessagingFactory.
Thanks for the explanation. Looks like this is expected behavior.

If you issue your HTTP calls sequentially, does the problem go away (while your function obviously takes longer)?
It may be expected, but I think there's some knobs we can expose to make this better if it is the HTTP calls that are hitting the limit. For example, if you were able to set ServicePointManager.DefaultConnectionLimit to something like 200, you'd be able to make as many calls as you could as quickly as possible -- some may be queued up, but it'd be better than trying to issue them sequentially.
If changing your HTTP calls fixes things, I'll rename this issue and we can look into a better solution.

I've updated the title as I've run into this elsewhere and verfied that it is an issue. If you, for example, loop through a bunch of tasks (thousands) and try to insert messages into a queue, you'll hit the error above. This is because the default connection limit in ASP.NET apps is int.MaxValue, while you can only have 250 connections in Consumption mode. You'll even run into issues in other areas as well if you try to create this many connections.
The best solution to this would be to set your DefaultConnectionLimit to ~200 (or even lower) and let the system queue up the requests for you. But that's not possible today.

Sounds great! Is it worth making this user configurable? Perhaps it's better to have the runtime check WEBSITE_SKU or WEBSITE_COMPUTE_MODE to see if it's running in in dynamic mode and set the value automatically.
Long term, it might be worth getting Kudu to expose value of this limit as an environment variable (if it's not there already).

Part of the selling point for the dynamic tier is

Don’t worry about the infrastructure and provisioning of servers, especially when your Functions call rate scales up. (From https://azure.microsoft.com/en-us/services/functions/)

I used Functions so I could take advantage of this. But because of all the SocketExceptions, I had to switch to a Standard tier, in which case, I wish I would have just stuck with WebJobs so I could use real C# and not C# script.
If it's supposed to be dynamic, there shouldn't be a limit to developers at all. Azure Functions should quietly take care of that in the background.

Request filed: https://feedback.azure.com/forums/355860-azure-functions/suggestions/17927350-the-dynamic-tier-should-never-run-out-of-sockets

@MisinformedDNA -- Would you mind sharing your scenario with us? I'm curious whether you're making HTTP calls to hit your limit (in which case this fix would help).

I'm clearing this milestone so we can re-evaluate this.
My suggestion is that we lower this value automatically in the Consumption plan, which would prevent the Socket errors that people are seeing. I believe we're now allowed 300 connections per sandbox -- so setting this to something like 250 would automatically protect people from exhausting their connections (but cause requests to queue up -- likely a better scenario which would allow us to scale out). Exposing it via host.json would be nice as well for those that want to increase or decrease it.

I'm using BlobTrigger to process thousands of files, which then get sent to Azure Tables and/or queues and QueueTrigger is then used to continue the process, reading and writing to SQL as needed.
I do not make any direct HTTP calls. I use IBinder to access Azure Storage. And I use Entity Framework to access Azure SQL. I always try to wrap my code in a using block to close/dispose the resources.

Still looking for feedback on this.

Would you mind letting us see your code so I can try to figure out where the connections are leaking? I wouldn't think that the usage of Azure Storage would do this as we use a single client behind-the-scenes. It may be from EF, but I'd like to see how you're using it. If you don't want to post the code here, you can send it to the email listed in my GitHub profile (with no secrets included).

@MisinformedDNA quick ping on this, see Brett's question above.

Sent.

I just ran into this today while sending documents to Azure Search to index. I think I'm going back to WebJobs.

Is there a fix for this yet? I can't even do a basic Function like set up a QueueTrigger to write a single document to Azure Search, without running into this socket exhaustion problem.

@BowserKingKoopa -- a few questions:

Are you using the Consumption or App Service plans? I'm assuming Consumption but want to be sure.
Can you give me some sample code for what you're doing? Is it a lot of async network requests?
Are you creating and closing network connections (or creating a new HttpClient) in every function? A lot of clients work much better when you use a single static instance.

Yes, I'm on a Consumption plan. That's where the socket exhaustion happens. The same code in an App Service plan, or in WebJobs, doesn't fail.
My function is a queue trigger that reads a single blob from Azure Storage (this part never fails) and writes one document to Azure Search (this is the part that fails). So it's not a lot of network activity. All the queue properties (batch size etc.) are left at their default.
I'm using the Azure Search SDK so I don't know for sure how they're using HttpClient, but I imagine this is at the root of the issue. The Azure Storage SDKs never fail, and the Azure Search SDK fails quickly. Maybe the difference is how they're using HttpClient?
The HttpClient issue is an unfortunate one. I was always taught if it's IDisposable, dispose of it. Now it seems like the best thing to do is not dispose of HttpClient. But now you have to think through what problems does never disposing of it cause. There are some problems with not disposing of it too: https://byterot.blogspot.com/2016/07/singleton-httpclient-dns.html?showComment=1508380828048#c1331956876138948841

Some more questions --

I don't know much about the Azure Search SDK, but are you creating a new SearchServiceClient in each function call or using a single static one? If you're creating a new one, what if you switch it to static?
I'm guessing this doesn't happen with a single function invocation, but after some number of them are triggered? With the default settings you can be running up to 24 functions at a single time on a single machine (we run 16 at a time, and then fetch more when you are half done -- in this case, 8 -- so 16 + 8 = 24).

I'm creating a new SearchServiceClient each invocation and disposing of it when I'm done (it is IDisposable afterall). It's probably using HttpClient behind the scenes.

Same applies I think

The SearchServiceClient class manages connections to your search service. In order to avoid opening too many connections, you should try to share a single instance of SearchServiceClient in your application if possible. Its methods are thread-safe to enable such sharing.

I hit a similar issue: I tried increasing ServicePointManager.DefaultConnectionLimit as early as I could in my C# Azure Function, but testing locally I only see 2 HTTP requests completing concurrently. I have 1300 requests to send, so 2 at a time is very slow.
    public static class Settings
    {
        static Settings()
        {
            ServicePointManager.DefaultConnectionLimit = 200;
        }

@brettsam , @paulbatum the CLI version 1.0.9 started to provide the following warning when running locally:

ServicePointManager.DefaultConnectionLimit is set to the default value of 2. This can limit the connection throughput to services like Azure Storage. For more information, see https://aka.ms/webjobs-connections.

I was assuming until now that this was completely managed by Azure Functions considering that it is related to Webjob SDK (ref: https://github.com/Azure/azure-webjobs-sdk/issues/909).
I see that this issue is still open, so no way for us to tweak it, but I would expect Functions to follow this recommendation: https://aka.ms/webjobs-connections

It is managed by Functions as the production host increases this limit, but the CLI doesn't when you're running locally. This has already been fixed in the CLI; we just haven't pushed out a release yet: https://github.com/Azure/azure-functions-core-tools/pull/384.
So our next release won't show this warning anymore. Sorry for the confusion.

@brettsam I don't believe any additional follow up is required here. Can this be closed?

Yeah, we've handled this in different ways and no longer will expose this setting (as it doesn't help in .NET Core anyway).

authors: BowserKingKoopa MisinformedDNA SimonLuckenuik anthonychu brettsam dallancarr fabiocav mmaitre314 paulbatum


text:
Remove-AzsPlatformImage Does Not Return Anything

For the AzureStack modules that are used with AzureRM, when you run a command like this:
Remove-AzsPlatformImage -Location local -Offer UbuntuServer -Publisher Canonical -Sku 16.04-LTS -Version 1.0.0
Nothing is returned. However it reportedly should return a boolean according to its documentation:
https://docs.microsoft.com/en-us/powershell/module/azs.compute.admin/remove-azsplatformimage?view=azurestackps-2.0.2&viewFallbackFrom=azurestackps-2.5.0
Another issue is that it doesn't seem to remove the image immediately, but this is not documented anywhere. The command does not stall until the removal is complete, so either that feature should be implemented or a warning given to the user.
This issue should be verified with the AzureStack modules that are used with the newer Az modules as well.

@deathly809 @hannah-murphy-0  please provide inputs here

It looks like it never returned a boolean value which is weird.  It looks like it should delete asynchronously from the code.  I will keep looking.

@bganapa Isn't the powershell and documentation automatically generated?
If you look at the API spec we don't specify anything about booleans for .
Perhaps AutoRest made a mistake?
        "responses": {
          "200": {
            "description": "OK"
          }
        }

@deathly809 Sorry, I have been busy. Should the platform image be removed instantaneously? Last I remembered, it didn't. The command doesn't to wait until the resource is deleted and also gives no warning of taking time to remove the resource. I think it would be better user experience to make it more like Remove-AzResourceGroup where it waits for the resource to be deleted while also returning a Boolean explaining that the removal was successful.

I will create an internal task to see if we can get some cycles to look at this issue.

See if we can make the cmdlet work like Remove-AzsResourceGroup (wait for completion)
See why Remove-AzsPlatformImage is not returning a boolean.

Just to be clear, #2 is all in the PowerShell and is created using AutoRest.  I am not sure why it is treating the endpoint different.

@hannah-murphy-0  can you provide your inputs here?

@hannah-murphy-0  can you provide your inputs here?

authors: TheOnlyWei bganapa deathly809

repo: Azure/azurestack-powershell


text:
Enable RPs & users to announce upcoming changes

I was unable to find any related issue, so here it goes:
I'd like to request a feature to enable users (and ideally also the Azure Resource Providers) to issue warnings about upcoming changes. The idea would be that you deploy a template (for example DiagnosticSettings as a very recent example) and because of either something configured somewhere by the PG, or maybe the original creator of the template, a warning should show up in the logs during the deployment of the template.
This could look similar to how it is done in

Terraform: source

PowerShell: source

WARNING: Set-AzureRmVMBootDiagnostics: A property of the output of this cmdlet will change in an upcoming breaking change release. The StorageAccountType property for a DataDisk will return Standard_LRS and Premium_LRS

Azure CLI: source

I could see this being quite useful also for, for example, the Public Bicep Registry, or any Solution Maintainer, to notify consumers of changes ahead of time - simply by showing them custom messages in the log.
I'm aware that I'm essentially asking for 2 things here:

Enable template creators to embedd info messages in their templates that show up during deployments
Enable RPs to issue warnings of upcoming changes that show up during deployments

Having the first would already be great. The second then the icing on the cake - especially in response to those aformentioned changes in the backend with the diagnostic settings which all of a sudden started breaking all over the place if you didn't happen to read about the change in the docs ahead of time.

Thanks for the suggestion, @AlexanderSehr! I think this could be really useful, although I think the Terraform example you include is closer to what we would support than the az CLI or PS module examples are.
For template authors, we could support some way to mark a parameter, an output, or a type property as deprecated, potentially including a custom deprecation message. If a consumer of the template supplied a value for a deprecated parameter (or property) or accessed a deprecated output (or property), a warning could be surfaced:
module.bicep
@deprecated('Use \'name\' property of storageAccountConfig param instead')
param storageAccountName string?

param storageAccountConfig {
  name: string?

  @deprecated('This was a typo')
  namme: string?
}

resource sa 'Microsoft.Storage/storageAccounts@<api version>' existing = {
  name: (storageAccountConfig.?name ?? storageAccountConfig.?namme ?? storageAccountName)!
}

@deprecated('This output field will be removed in a future version of this module')
output foo string = <value>

main.bicep
module mod 'mod.bicep' = {
  name: 'mod'
  params: {
    storageAccountName: 'foo'             // <-- Would raise warning diagnostic with custom deprecation message
    storageAccountConfig: {
      namme: 'foo'                        // <-- Would raise warning diagnostic with custom deprecation message
      name: 'foo'
    }
  }
}

outputs modFoo string = mod.outputs.foo   // <-- Would raise warning diagnostic with custom deprecation message

We would only be able to do something similar for RPs if deprecation information is captured in providers' service models. It appears that field-level deprecated traits are only supported in OpenAPI 3.0+, and I believe most RP service models adhere to the Swagger 2.0 spec. I can check around to see if there are any Swagger extensions we could look for instead.

We would only be able to do something similar for RPs if deprecation information is captured in providers' service models. It appears that field-level deprecated traits are only supported in OpenAPI 3.0+, and I believe most RP service models adhere to the Swagger 2.0 spec. I can check around to see if there are any Swagger extensions we could look for instead. But even OpenAPI 3.0 only appears to support a boolean deprecated trait, so there may not be any way for RP teams to provide custom deprecation messages.

FWIW it feels to me like 'deprecated' fields goes against the current design principals for Azure APIs. Rather than supporting 2 ways of doing things on a single API version, RPs tend to just use API versions to "safely" introduce breaking changes.

We would only be able to do something similar for RPs if deprecation information is captured in providers' service models. It appears that field-level deprecated traits are only supported in OpenAPI 3.0+, and I believe most RP service models adhere to the Swagger 2.0 spec. I can check around to see if there are any Swagger extensions we could look for instead. But even OpenAPI 3.0 only appears to support a boolean deprecated trait, so there may not be any way for RP teams to provide custom deprecation messages.

FWIW it feels to me like 'deprecated' fields goes against the current design principals for Azure APIs. Rather than supporting 2 ways of doing things on a single API version, RPs tend to just use API versions to "safely" introduce breaking changes.

One would think so @anthony-c-martin, and every now and then you have cases such as the Diagnostic Settings Retention Policy (where they deprecated the feature across the board even a month before the announced schedule) or the Azure Purview Service (where all of a sudden the support for any location but the US was scrapped). 🤔
But overall I agree, why else have Api versions if you (usually) cannot rely on a stable support.
In any case, the ability to announce upcoming changes for future versions would help RP users too, not to speak of the other suggested feature, that is, to enable the template author to do the same. Like in case of [CARML]	(aka.ms/carml) it would have been great to use that feature as a means to announce it's upcoming migration the the Puic Bicep Registry (which is a accompanied by a landslide of breaking changes we try to be as visual about a possible).

@anthony-c-martin I did find several usages of "deprecated" in RP models, though it is only used as a trait on operations rather than on individual fields. Autorest does support the "deprecated" trait on fields and parameters, but it looks like no RPs are using it.

There is an open issue for adding a @deprecated() decorator: #3505

authors: AlexanderSehr anthony-c-martin jeskew

repo: Azure/bicep


text:
Resource IDs cannot be used within the resource itself

For example, Azure Front Door has many Resource IDs referring to Azure Front Door itself. This is used to link frontend pools, backend pools, and rules. E.g.:
            "properties": {
                "resourceState": "Enabled",
                "backendPools": [
                    {
                        "id": "[concat(resourceId('Microsoft.Network/frontdoors', 'MyFrontDoorNameHere'), '/BackendPools/www')]",
                        "name": "www",
                        "properties": {

When decompiling this with Bicep, you get something like:
    backendPools: [
      {
        id: '${afd.id}/BackendPools/www'
        name: 'WebApp'
        properties: {

However, the 'afd' resource cannot use 'afd.id' within its own definition, so the decompiled Bicep won't compile.
I feel that such self-references should work, because they're necessarily specified in the Bicep file! The name, id, and location should be usable in such a manner.

I think in this case the ID should just not be generated in the decompilation. Written in bicep a working FD definition looks like this:
resource frontdoor 'Microsoft.Network/frontDoors@2020-05-01' = {
  name: frontDoorName
  location: 'Global'
  properties: {
    backendPools: [
      {
        name: 'BackendAPIMs'
        properties: {
          backends: [
            {
              address: 'a.contoso.com'

This is related to #724. I definitely think there's scope for special-casing the 'deploy-time' properties (.id, .type, .name & .apiVersion) so that a resource can self-reference them.

I notice the examples area has no examples for either loadbalancer loadbalancingRules or inboundNatRules. Is it because of this self-referencing problem? Is there a workaround?

Yeah I agree that we should allow self-referencing for the properties mentioned above since they don't generate a true dependency.
The workaround would be to construct the resource id manually via the *resourceId() functions.

@majastrz the problem is that with inboundNat rules it is a lower-level item (the frontend configuration) you need to fetch. Is it possible to fetch this with resourceId? I thought it only worked for "top level" items and not sub items.

@JustinGrote I just built an LB. Didn't have time yet to post this as a proper example but maybe this helps you
resource loadBalancerInbound 'Microsoft.Network/loadBalancers@2020-06-01' = {
  name: name_loadBalancerInbound
  location: location
  sku: {
    name: 'Standard'
  }
  properties: {
    frontendIPConfigurations: [
      {
        name: loadBalancerFrontEndName
        properties: {
          subnet: {
            id: '${vnet.id}/subnets/${name_subnetPgbouncerLb}'
          }
          privateIPAllocationMethod: 'Static'
          privateIPAddress: '10.0.1.4'
          privateIPAddressVersion: 'IPv4'
        }
      }
    ]
    backendAddressPools: [
      {
        name: loadBalancerBackEndName
      }
    ]
    loadBalancingRules: [
      {
        name: 'roundRobinLBRule'
        properties: {
          frontendIPConfiguration: {
            id: resourceId('Microsoft.Network/loadBalancers/frontendIPConfigurations', name_loadBalancerInbound, loadBalancerFrontEndName)
          }
          backendAddressPool: {
            id: resourceId('Microsoft.Network/loadBalancers/backendAddressPools', name_loadBalancerInbound, loadBalancerBackEndName)
          }
          protocol: 'Tcp'
          frontendPort: 5432
          backendPort: 5432
          enableFloatingIP: false
          loadDistribution: 'Default'
          idleTimeoutInMinutes: 5
          probe: {
            id: resourceId('Microsoft.Network/loadBalancers/probes', name_loadBalancerInbound, loadBalancerProbeName)
          }
        }
      }
    ]
    probes: [
      {
        name: loadBalancerProbeName
        properties: {
          protocol: 'Tcp'
          port: 5432
          intervalInSeconds: 5
          numberOfProbes: 2
        }
      }
    ]
  }
}

@sebader thanks for posting the workaround.

@sebader this worked for me too. Thanks.

Closing as dup of #1852

Thanks @sebader
I did as your guide, it's working fine.

@sebader solution works for me also. Thanks. Maybe problem is not entirely in bicep. Maybe az bicep decompile should generate working bicep i.e. using @sebader solution. Although I'm not sure if you have used it and ended up here that way.

authors: JanneHarju JustinGrote alex-frankel anthony-c-martin hctru68 majastrz peter-bertok sebader


text:
Unable to run Azure Backup Vault bicep script twice as part of IAC

Bicep version
Bicep CLI version 0.4.613 (d826ce8411)
Describe the bug
Microsoft have assisted me with creating a Backup Vault bicep template with a PostgreSQL policy.
The initial deployment works fine but when I re-run the bicep script a 2nd time without making any changes, I receive the below errors.
I have a feeling that additional values are being written to the backend during the initial deployment and when I execute the 2nd deployment, my code is not consistent with whats already provisioned hence it thinks I am trying to modify the existing policy.
Azure Portal Deployment Error
{"code":"DeploymentFailed","message":"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.","details":[{"code":"UserErrorBMSUpdatePolicyNotSupported","message":"Update of existing policy is not supported."}]}
Azure DevOps Error
2021-11-03T02:41:29.7975462Z ERROR: {"status":"Failed","error":{"code":"DeploymentFailed","message":"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.","details":[{"code":"BadRequest","message":"{\r\n  \"error\": {\r\n    \"additionalInfo\": [\r\n      {\r\n        \"type\": \"UserFacingError\",\r\n        \"info\": {\r\n          \"message\": \"Update of existing policy is not supported.\",\r\n          \"recommendedAction\": [\r\n            \"Please create a new policy.\"\r\n          ],\r\n          \"details\": null,\r\n          \"code\": \"UserErrorBMSUpdatePolicyNotSupported\",\r\n          \"target\": \"\",\r\n          \"innerError\": null,\r\n          \"isRetryable\": false,\r\n          \"isUserError\": false,\r\n          \"properties\": {\r\n            \"ActivityId\": \"40695e30-d8b5-4652-8d3c-960d8f86f38b\"\r\n          }\r\n        }\r\n      }\r\n    ],\r\n    \"code\": \"UserErrorBMSUpdatePolicyNotSupported\",\r\n    \"message\": \"Update of existing policy is not supported.\",\r\n    \"target\": null,\r\n    \"details\": null\r\n  }\r\n}"}]}}
To Reproduce
Run the bicep template twice
Additional context
I have included my bicep script
portal_backupvault.txt
.

If the code has not been modified, then this is an idempotency issue (bad resource provider behavior). I would recommend opening a support case for this issue and see if this can be routed to the Azure Backup team.


text:
Proposal: VSCode Extension – Output outputs to Output panel after running Deploy Bicep File...

Current Situation
In my Bicep files I defined some outputs for debugging purposes.
When running the Deploy Bicep File... menu item in Visual Studio Code, though, I don't get to see the outputs I defined.
Desired Situation
Please output all outputs to the Visual Studio Code Output panel for the user to be able to review the result.

Great suggestion!

@bhsubra I though we emit the completed deployment response in "Bicep Operations"? This would include any outputs.

I checked, but I fail to see the output:

I'd like to add an additional improvement to this suggestion:
Being able to see the deployment's result in a tree view in a side panel (similar to the debugger's variable inspection panel) would be nice. This would provide features like the ability to collapse/expand dedicated parts of the result.

authors: SetTrend alex-frankel anthony-c-martin


text:
misc doc fixes

Fixes #1863 and corrects some of the out-of-date docs that @sam-cogan encountered
Contributing a Pull Request
If you haven't already, read the full contribution guide. The guide may have changed since the last time you read it, so please double-check. Once you are done and ready to submit your PR, run through the relevant checklist below.
Contributing to documentation

[x] The contribution does not exist in any of the docs in either the root of the docs directory or the specs

Codecov Report

Merging #1872 (c0fff8e) into main (12aa6f6) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #1872   +/-   ##
=======================================
  Coverage   95.11%   95.11%
=======================================
  Files         371      371
  Lines       21929    21929
  Branches       15       15
=======================================
  Hits        20857    20857
  Misses       1072     1072

Flag
Coverage Δ

dotnet
95.54% <ø> (ø)

typescript
26.61% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

This will be merged after this week's release?

This will be merged after this week's release?

It can wait if we'd like. I'm was operating with the assumption that if a feature is checked into main we can say it's no longer a todo item, but we're close enough to a release that we might as well wait.

TODO:

doc parent syntax
doc nested child resource syntax
doc :: access operator

authors: alex-frankel codecov-io majastrz


text:
[Bugfix] Fix the title view appearance for unnamed users

Purpose

Changed the background color for the title view when a user's name is empty and a microphone isn't muted.

Does this introduce a breaking change?

[ ] Yes
[x] No

Pull Request Type
What kind of change does this Pull Request introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

How to Test

Get the code

git clone [repo-address]
cd [repo-name]
git checkout [branch-name]
npm install

Test the code

1. Connect to a meeting
2. Connect to the same meeting on an another device without specifying your "Displya Name"
3. Unmute your microphone on the device from step 2
4. Check the title view on the device from the step 1

What to Check
Verify that the following are valid

a user's name and a mute status are shown correctly

@AmyL219 for unnamed participant, their name appears as "Unnamed Participant" in the participant list drawer. Just checking if we need check UX and follow the same naming for unnamed participant in this case. From this PR it looks like the participants would have no name labels if they turned the video on and stay unmuted. cc @vhuseinova-msft

ParticipantList should be bug free right now. For name labels, I think make it empty is expected. Similar to Teams behavior.

repo: Azure/communication-ui-library-ios


text:
unable to pull images

Hi, hopping the team is safe under the codiv-19 pandemic, i would like to report that i am unable to pull any image from
dockerhub.azk8s.cn
or
gcr.azk8s.cn
for a while now, the error is:
Error response from daemon: error parsing HTTP 403 response body: invalid character '<' looking for beginning of value: "\r\n403 Forbidden\r\n<body bgcolor="white">\r\n403 Forbidden\r\nnginx/1.14.0 (Ubuntu)\r\n\r\n\r\n"
Best regards.

Sorry, currently *.azk8s.cn could only be accessed by Azure China IP, we don't provide public outside access any more. If you have such requirement to whitelist your IP, please contact akscn@microsoft.com, provide your IP address, we will decide whether to whitelist your IP per your reasonable requirement, thanks for understanding.

repo: Azure/container-service-for-azure-china


text:
Add Cache properties to runtime config file with JSON Serialize/Deserialize

Why make this change?

first work attributed to #1618 #1617

What is this change?
Global Cache Config property cache

Adds global config property cache with value type of boolean in the runtime section:

{
  "runtime": {
    "cache": false
  }
}

Behavior:

Nullable and defaults to false.
When null, will not be written to the CLI created runtime config JSON

Entity Cache Config property/object cache

Adds entity specific config property cache in entity section:

{
  "entityName": {
    "cache": {
      "enabled": true,
      "ttl-seconds": 60
    }
  }
}

Behavior:

Nullable and defaults to "enabled": false, "ttl-seconds": 60
When an empty object -> caching disabled
When null -> caching disabled
ttl-seconds defaults to 60 regardless but due to private field state, tracks whether the value was user provided or set with the default value due to not being explicitly set in runtime config. This enables CLI runtime config creation to exclude the ttl-seconds property and value if not explicitly set by the user.

How was this tested?

[X] manually tested CLI handling of writing ttl-seconds to file. but CLI specific work will come in separate pr.
[X] Unit Tests -> System under test is RuntimeConfigLoader.TryParseConfig(string json, ...) such that I test the behavior of any json parsing that goes on. JSON parsing mechanisms are implementation details and aren't tested directly because the implementation can change. I explicitly test for the desired behavior. I test Behavior such as providing null and empty json objects in order to validate how CLI merge config will work. and to avoid regressions that have come up in the past due to improper/lackof null handling.

Sample Request(s)
Caching is not yet enabled. Behavior can be observed in unit test class CachingConfigDeserializationTests or you can create a config using the CLI:

Create a folder called dabconfigs at root of C:\ drive to work with these sample commands.
run DAB cli to create a config file and one entity called Book.

Microsoft.DataApiBuilder init --database-type mssql -c "C:\dabconfigs\dab-config.json"

Microsoft.DataApiBuilder add Book -c "C:\dabconfigs\dab-config.json" --source books --permissions "anonymous:create,read,update,delete" --graphql "book:books"

Modify config file directly to add cache config to entity.

    "Book": {
      "source": {
        "object": "books",
        "type": "table"
      },
      "graphql": {
        "enabled": true,
        "type": {
          "singular": "book",
          "plural": "books"
        }
      },
      "rest": {
        "enabled": true
      },
      "permissions": [
        {
          "role": "anonymous",
          "actions": [
            {
              "action": "*"
            }
          ]
        }
      ],
      "cache": {
        "enabled": true
      }
    }

add another entity, and validate that ttl-seconds is not added to the Book entity config because a non-explicitly set ttl should not result in a property/value being written to the config from CLI. Under the hood, the default 60 second value is used, which is validated in unit tests.

Microsoft.DataApiBuilder add Dog -c "C:\dabconfigs\dab-config.json" --source books --permissions "anonymous:create,read,update,delete" --graphql "dog:dogs"

/azp run

/azp run

/azp run

repo: Azure/data-api-builder


text:
fix: restore ability to catch broken scanner

Prior to the configmap changes, there was an e2e test, collector_ensure_scan designed to catch when the scanner is broken. The reason this is needed is that when the scanner isn't functioning properly, and deleteFailedImages is set to true, then scanning of all images will fail.
Because in most tests we delete those images for which scanning failed, this will create a false positive: all images will be removed, instead of just the vulnerable ones. That makes it impossible to tell whether or not the tests should be passing, because deleting all images will remove the vulnerable images along with the safe ones.
This PR restores the test to a working state, and is critical to catch when we break the scanner.
I have manually tested and confirmed that the modified test fails when the scanner is broken.
What this PR does / why we need it:
Which issue(s) this PR fixes (optional, using fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when the PR gets merged):
Fixes #
Special notes for your reviewer:

Codecov Report

Merging #706 (b37b2a1) into main (84fe191) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #706   +/-   ##
=======================================
  Coverage   14.58%   14.58%
=======================================
  Files          13       13
  Lines        1694     1694
=======================================
  Hits          247      247
  Misses       1419     1419
  Partials       28       28

Flag
Coverage Δ

unittests
14.58% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

test/e2e/util/utils.go
6.44% <ø> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

authors: codecov-commenter pmengelbert

repo: Azure/eraser


text:
interface: add v1 APIs

Description of your changes
This PR adds the v1 APIs for the GA task.
I have:

[x] Run make reviewable to ensure this PR is ready for review.

How has this code been tested
N/A.
Special notes for your reviewer

The v1 APIs at this moment are exactly the same with the v1beta1 APIs; per earlier agreements, we would be using the v1beta1 APIs as the storage version
No conversion strategy has been configured, so K8s API server will simply switch the API version as appropriate.

As discussed earlier, the override fields are marked as alpha; fields for other new features receive the beta tag.

repo: Azure/fleet


text:
Kubeapp (master)

Comparison branch here was based on the kubeapp branch. master was merged in, and conflicts resolved.
Another version of this was done pulling releases/v1 and has been opened as https://github.com/Azure/functions-action/pull/83. Since there is a gap between master and releases/v1, I was not sure which was preferable.

@mattchenderson Please remove node_modules in master PR as we checkin node_modules only in releases/* branches but not in master.

Codecov Report

Merging #82 (6975423) into master (a7fed43) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #82   +/-   ##
=======================================
  Coverage   77.24%   77.24%
=======================================
  Files          23       23
  Lines         668      668
  Branches      119      108   -11
=======================================
  Hits          516      516
  Misses        152      152

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a7fed43...6975423. Read the comment docs.

repo: Azure/functions-action


text:
bump release workflow sha

the current workflow uses a short hash which apparently isn't supported

Have you tested this in a fork? We should be testing this in a fork instead of against the main repo so we aren't clogging up the history

authors: OliverMKing davidgamero


text:
fix: Updated instanceTypeZones logic to handle non-zonal SKUs in zonal regions

Description
I'm working with the Kaito  team to integrate with Karpenter Azure Provider. They noticed that they were unable to use some GPU skus due to "insufficient capacity", but were able to confirm that the capacity was available and that this wasn't happening when provisioning nodes directly using AKS APIs.
It turns out that this was due to a small bug in retrieving availability zones for SKUs. We properly handle the case for non-zonal regions, but do not properly handle non-zonal offerings within zonal regions. I've updated the condition to handle this scenario.
I also have included the manual-nodeclaim.yaml that I use to test this. I think it will be helpful for future validations with Kaito, but I can remove it if needed.
How was this change tested?

manually by applying the manual nodeclaim
[WIP] added another unit test to account for this

Does this change impact docs?

[ ] Yes, PR includes docs updates
[ ] Yes, issue opened: #
[X] No

Release Note

NONE

Pull Request Test Coverage Report for Build 9576170731
Details

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 97.766%

Totals

Change from base Build 9573708617:
0.0%

Covered Lines:
36287

Relevant Lines:
37116

💛  - Coveralls

Pull Request Test Coverage Report for Build 9576589256
Details

6 of 6 (100.0%)  changed or added relevant lines in 1 file are covered.
3 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.008%) to 97.758%

Files with Coverage Reduction
New Missed Lines
%

pkg/providers/instancetype/instancetypes.go
1
88.37%

pkg/cache/unavailableofferings.go
2
95.45%

Totals

Change from base Build 9573708617:
-0.008%

Covered Lines:
36286

Relevant Lines:
37118

💛  - Coveralls

Pull Request Test Coverage Report for Build 9584893711
Details

6 of 6 (100.0%)  changed or added relevant lines in 1 file are covered.
3 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.008%) to 97.758%

Files with Coverage Reduction
New Missed Lines
%

pkg/providers/instancetype/instancetypes.go
1
88.37%

pkg/cache/unavailableofferings.go
2
95.45%

Totals

Change from base Build 9573708617:
-0.008%

Covered Lines:
36286

Relevant Lines:
37118

💛  - Coveralls

Pull Request Test Coverage Report for Build 9588996632
Details

6 of 6 (100.0%)  changed or added relevant lines in 1 file are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.002%) to 97.764%

Files with Coverage Reduction
New Missed Lines
%

pkg/providers/instancetype/instancetypes.go
1
88.37%

Totals

Change from base Build 9587074007:
-0.002%

Covered Lines:
36288

Relevant Lines:
37118

💛  - Coveralls

Pull Request Test Coverage Report for Build 9589013756
Details

6 of 6 (100.0%)  changed or added relevant lines in 1 file are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.002%) to 97.764%

Files with Coverage Reduction
New Missed Lines
%

pkg/providers/instancetype/instancetypes.go
1
88.37%

Totals

Change from base Build 9587074007:
-0.002%

Covered Lines:
36288

Relevant Lines:
37118

💛  - Coveralls

Pull Request Test Coverage Report for Build 9601903041
Details

4 of 4 (100.0%)  changed or added relevant lines in 1 file are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.002%) to 97.764%

Files with Coverage Reduction
New Missed Lines
%

pkg/providers/instancetype/instancetypes.go
1
88.3%

Totals

Change from base Build 9587074007:
-0.002%

Covered Lines:
36287

Relevant Lines:
37117

💛  - Coveralls

authors: coveralls rakechill

repo: Azure/karpenter-provider-azure


text:
Segmentation fault in converter

I have been having trouble getting the config converter to work. It always segfaults, with what looks like a null pointer and afterwards it silently "succeeds", because of the lock file.
Platform: Archlinux (5.15.55-1-lts)
Go version:  go version go1.18.4 linux/amd64
Distribution: https://aur.archlinux.org/packages/azure-kubelogin

I had been noticing this when using the program, but this morning I noticed it also fails when running the converter test (Which luckily seems to notice the lock file and no longer silently succeeds on the second attempt).
Any help/pointing in the right direction would be greatly appreciated.
The stacktrace:
unexpected fault address 0x0
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0x55c1d8ae89df]

goroutine 10 [running]:
runtime.throw({0x55c1d9935374?, 0x30?})
        runtime/panic.go:992 +0x71 fp=0xc0002ca0b8 sp=0xc0002ca088 pc=0x55c1d8ab6e51
runtime.sigpanic()
        runtime/signal_unix.go:825 +0x305 fp=0xc0002ca108 sp=0xc0002ca0b8 pc=0x55c1d8acdb65
aeshashbody()
        runtime/asm_amd64.s:1343 +0x39f fp=0xc0002ca110 sp=0xc0002ca108 pc=0x55c1d8ae89df
runtime.mapiternext(0xc000628d80)
        runtime/map.go:934 +0x2cb fp=0xc0002ca180 sp=0xc0002ca110 pc=0x55c1d8a8f7ab
runtime.mapiterinit(0x1?, 0x7?, 0x1?)
        runtime/map.go:861 +0x228 fp=0xc0002ca1a0 sp=0xc0002ca180 pc=0x55c1d8a8f488
reflect.mapiterinit(0x55c1d8a944a6?, 0x7ff2230f5a00?, 0x55c1d8b6cb47?)
        runtime/map.go:1373 +0x19 fp=0xc0002ca1c8 sp=0xc0002ca1a0 pc=0x55c1d8ae47d9
github.com/modern-go/reflect2.(*UnsafeMapType).UnsafeIterate(...)
        github.com/modern-go/reflect2@v1.0.1/unsafe_map.go:112
github.com/json-iterator/go.(*sortKeysMapEncoder).Encode(0xc0002227b0, 0xc000111120, 0xc00010f020)
        github.com/json-iterator/go@v1.1.10/reflect_map.go:291 +0x225 fp=0xc0002ca338 sp=0xc0002ca1c8 pc=0x55c1d8f3b285
github.com/json-iterator/go.(*placeholderEncoder).Encode(0x55c1d9c80c00?, 0x1?, 0xc00010f038?)
        github.com/json-iterator/go@v1.1.10/reflect.go:332 +0x22 fp=0xc0002ca360 sp=0xc0002ca338 pc=0x55c1d8f340a2
github.com/json-iterator/go.(*structFieldEncoder).Encode(0xc000222a20, 0x55c1d9b7e76d?, 0xc00010f020)
        github.com/json-iterator/go@v1.1.10/reflect_struct_encoder.go:110 +0x56 fp=0xc0002ca3d8 sp=0xc0002ca360 pc=0x55c1d8f489d6
github.com/json-iterator/go.(*structEncoder).Encode(0xc000222a80, 0x1500?, 0xc00010f020)
        github.com/json-iterator/go@v1.1.10/reflect_struct_encoder.go:158 +0x765 fp=0xc0002ca4c0 sp=0xc0002ca3d8 pc=0x55c1d8f493e5
github.com/json-iterator/go.(*OptionalEncoder).Encode(0xc00010f020?, 0xc000121310?, 0xc0002ca550?)
        github.com/json-iterator/go@v1.1.10/reflect_optional.go:70 +0xa4 fp=0xc0002ca510 sp=0xc0002ca4c0 pc=0x55c1d8f405e4
github.com/json-iterator/go.(*placeholderEncoder).Encode(0x55c1d9c80c00?, 0xc000628c01?, 0xc00010f038?)
        github.com/json-iterator/go@v1.1.10/reflect.go:332 +0x22 fp=0xc0002ca538 sp=0xc0002ca510 pc=0x55c1d8f340a2
github.com/json-iterator/go.(*structFieldEncoder).Encode(0xc00011a330, 0x55c1d9bb07dc?, 0xc00010f020)
        github.com/json-iterator/go@v1.1.10/reflect_struct_encoder.go:110 +0x56 fp=0xc0002ca5b0 sp=0xc0002ca538 pc=0x55c1d8f489d6
github.com/json-iterator/go.(*structEncoder).Encode(0xc00011a3f0, 0xc0001214f0?, 0xc00010f020)
        github.com/json-iterator/go@v1.1.10/reflect_struct_encoder.go:158 +0x765 fp=0xc0002ca698 sp=0xc0002ca5b0 pc=0x55c1d8f493e5
github.com/json-iterator/go.(*placeholderEncoder).Encode(0x55c1d9c80c00?, 0x55c1d8f48101?, 0xc00010f038?)
        github.com/json-iterator/go@v1.1.10/reflect.go:332 +0x22 fp=0xc0002ca6c0 sp=0xc0002ca698 pc=0x55c1d8f340a2
github.com/json-iterator/go.(*structFieldEncoder).Encode(0xc00011a660, 0x55c1d9b7e743?, 0xc00010f020)
        github.com/json-iterator/go@v1.1.10/reflect_struct_encoder.go:110 +0x56 fp=0xc0002ca738 sp=0xc0002ca6c0 pc=0x55c1d8f489d6
github.com/json-iterator/go.(*structEncoder).Encode(0xc00011a6c0, 0x55c1d9c30980?, 0xc00010f020)
        github.com/json-iterator/go@v1.1.10/reflect_struct_encoder.go:158 +0x765 fp=0xc0002ca820 sp=0xc0002ca738 pc=0x55c1d8f493e5
github.com/json-iterator/go.(*sliceEncoder).Encode(0xc000111638, 0xc000240478, 0xc00010f020)
        github.com/json-iterator/go@v1.1.10/reflect_slice.go:38 +0x2bd fp=0xc0002ca8d8 sp=0xc0002ca820 pc=0x55c1d8f4103d
github.com/json-iterator/go.(*structFieldEncoder).Encode(0xc00011b2c0, 0x55c1d9b83f4d?, 0xc00010f020)
        github.com/json-iterator/go@v1.1.10/reflect_struct_encoder.go:110 +0x56 fp=0xc0002ca950 sp=0xc0002ca8d8 pc=0x55c1d8f489d6
github.com/json-iterator/go.(*structEncoder).Encode(0xc00011b3b0, 0x0?, 0xc00010f020)
        github.com/json-iterator/go@v1.1.10/reflect_struct_encoder.go:158 +0x765 fp=0xc0002caa38 sp=0xc0002ca950 pc=0x55c1d8f493e5
github.com/json-iterator/go.(*OptionalEncoder).Encode(0xc0001ef720?, 0x0?, 0x0?)
        github.com/json-iterator/go@v1.1.10/reflect_optional.go:70 +0xa4 fp=0xc0002caa88 sp=0xc0002caa38 pc=0x55c1d8f405e4
github.com/json-iterator/go.(*onePtrEncoder).Encode(0xc0002271d0, 0xc000240420, 0xc0004f4150?)
        github.com/json-iterator/go@v1.1.10/reflect.go:219 +0x82 fp=0xc0002caac0 sp=0xc0002caa88 pc=0x55c1d8f33662
github.com/json-iterator/go.(*Stream).WriteVal(0xc00010f020, {0x55c1d9ce6460, 0xc000240420})
        github.com/json-iterator/go@v1.1.10/reflect.go:98 +0x158 fp=0xc0002cab30 sp=0xc0002caac0 pc=0x55c1d8f32978
github.com/json-iterator/go.(*frozenConfig).Marshal(0xc0001ef720, {0x55c1d9ce6460, 0xc000240420})
        github.com/json-iterator/go@v1.1.10/config.go:299 +0xc9 fp=0xc0002cabc8 sp=0xc0002cab30 pc=0x55c1d8f29309
k8s.io/apimachinery/pkg/runtime/serializer/json.(*Serializer).doEncode(0x55c1d9b650f2?, {0x55c1d9e0a6e8?, 0xc000240420?}, {0x55c1d9e02b08, 0xc000806a20})
        k8s.io/apimachinery@v0.21.3/pkg/runtime/serializer/json/json.go:306 +0x6d fp=0xc0002cac60 sp=0xc0002cabc8 pc=0x55c1d90803ad
k8s.io/apimachinery/pkg/runtime/serializer/json.(*Serializer).Encode(0xc0000aafa0, {0x55c1d9e0a6e8, 0xc000240420}, {0x55c1d9e02b08, 0xc000806a20})
        k8s.io/apimachinery@v0.21.3/pkg/runtime/serializer/json/json.go:301 +0xfc fp=0xc0002cacc0 sp=0xc0002cac60 pc=0x55c1d90802dc
k8s.io/apimachinery/pkg/runtime/serializer/versioning.(*codec).doEncode(0xc0001efa40, {0x55c1d9e0a698?, 0xc00010ef60}, {0x55c1d9e02b08, 0xc000806a20})
        k8s.io/apimachinery@v0.21.3/pkg/runtime/serializer/versioning/versioning.go:244 +0x8fa fp=0xc0002cb018 sp=0xc0002cacc0 pc=0x55c1d908ef9a
k8s.io/apimachinery/pkg/runtime/serializer/versioning.(*codec).Encode(0xc0001efa40, {0x55c1d9e0a698, 0xc00010ef60}, {0x55c1d9e02b08, 0xc000806a20})
        k8s.io/apimachinery@v0.21.3/pkg/runtime/serializer/versioning/versioning.go:184 +0x106 fp=0xc0002cb078 sp=0xc0002cb018 pc=0x55c1d908e646
k8s.io/apimachinery/pkg/runtime.Encode({0x7ff2203fb298, 0xc0001efa40}, {0x55c1d9e0a698, 0xc00010ef60})
        k8s.io/apimachinery@v0.21.3/pkg/runtime/codec.go:50 +0x64 fp=0xc0002cb0b8 sp=0xc0002cb078 pc=0x55c1d8f883e4
k8s.io/client-go/tools/clientcmd.Write(...)
        k8s.io/client-go@v0.21.3/tools/clientcmd/loader.go:466
k8s.io/client-go/tools/clientcmd.WriteToFile({{0x0, 0x0}, {0x0, 0x0}, {0x0, 0xc0007b78f0}, 0xc0007b7920, 0xc0007b7950, 0xc0007b7980, {0x55c1d99345b8, ...}, ...}, ...)
        k8s.io/client-go@v0.21.3/tools/clientcmd/loader.go:419 +0xa8 fp=0xc0002cb130 sp=0xc0002cb0b8 pc=0x55c1d90ba048
k8s.io/client-go/tools/clientcmd.writeCurrentContext({0x55c1d9e199b8, 0xc000204a00}, {0x55c1d99345b8, 0x3})
        k8s.io/client-go@v0.21.3/tools/clientcmd/config.go:415 +0x1a8 fp=0xc0002cb318 sp=0xc0002cb130 pc=0x55c1d90b70c8
k8s.io/client-go/tools/clientcmd.ModifyConfig({0x55c1d9e199b8, 0xc000204a00}, {{0x0, 0x0}, {0x0, 0x0}, {0x0, 0xc0003af500}, 0xc0003af530, 0xc0003af560, ...}, ...)
        k8s.io/client-go@v0.21.3/tools/clientcmd/config.go:197 +0x198 fp=0xc0002cba40 sp=0xc0002cb318 pc=0x55c1d90b59b8
github.com/Azure/kubelogin/pkg/converter.Convert({0xc00029a300, {0x55c1d9e19008, 0xc0003af5f0}, {{0x55c1d99394d5, 0xa}, {0x0, 0x0}, {0x0, 0x0}, {0x0, ...}, ...}})
        github.com/Azure/kubelogin/pkg/converter/convert.go:317 +0x2a47 fp=0xc0002cbd18 sp=0xc0002cba40 pc=0x55c1d992a247
github.com/Azure/kubelogin/pkg/converter.TestConvert.func1(0xc00020ba00)
        github.com/Azure/kubelogin/pkg/converter/convert_test.go:930 +0x479 fp=0xc0002cbf70 sp=0xc0002cbd18 pc=0x55c1d99319b9
testing.tRunner(0xc00020ba00, 0xc00007af00)
        testing/testing.go:1439 +0x102 fp=0xc0002cbfc0 sp=0xc0002cbf70 pc=0x55c1d8ba5f22
testing.(*T).Run.func1()
        testing/testing.go:1486 +0x2a fp=0xc0002cbfe0 sp=0xc0002cbfc0 pc=0x55c1d8ba6dca
runtime.goexit()
        runtime/asm_amd64.s:1571 +0x1 fp=0xc0002cbfe8 sp=0xc0002cbfe0 pc=0x55c1d8aeb661
created by testing.(*T).Run
        testing/testing.go:1486 +0x35f

goroutine 1 [chan receive]:
testing.(*T).Run(0xc00020b380, {0x55c1d993a1db?, 0x55c1d8ba5905?}, 0x55c1d9dfbae8)
        testing/testing.go:1487 +0x37a
testing.runTests.func1(0xc00020b380?)
        testing/testing.go:1839 +0x6e
testing.tRunner(0xc00020b380, 0xc000507cd8)
        testing/testing.go:1439 +0x102
testing.runTests(0xc000465d60?, {0x55c1da770360, 0x2, 0x2}, {0x7ff249bf0108?, 0x40?, 0x55c1da827ce0?})
        testing/testing.go:1837 +0x457
testing.(*M).Run(0xc000465d60)
        testing/testing.go:1719 +0x5d9
main.main()
        _testmain.go:49 +0x1aa

goroutine 6 [chan receive]:
k8s.io/klog.(*loggingT).flushDaemon(0x0?)
        k8s.io/klog@v1.0.0/klog.go:1010 +0x6a
created by k8s.io/klog.init.0
        k8s.io/klog@v1.0.0/klog.go:411 +0xef

goroutine 7 [chan receive]:
k8s.io/klog/v2.(*loggingT).flushDaemon(0x0?)
        k8s.io/klog/v2@v2.8.0/klog.go:1164 +0x6a
created by k8s.io/klog/v2.init.0
        k8s.io/klog/v2@v2.8.0/klog.go:418 +0xf6

goroutine 9 [chan receive]:
testing.(*T).Run(0xc00020b520, {0x55c1d994499c?, 0x55c1d994462c?}, 0xc00007af00)
        testing/testing.go:1487 +0x37a
github.com/Azure/kubelogin/pkg/converter.TestConvert(0xc00020b520?)
        github.com/Azure/kubelogin/pkg/converter/convert_test.go:904 +0x6f7c
testing.tRunner(0xc00020b520, 0x55c1d9dfbae8)
        testing/testing.go:1439 +0x102
created by testing.(*T).Run
        testing/testing.go:1486 +0x35f
FAIL    github.com/Azure/kubelogin/pkg/converter        0.024s

you have to use go 1.17 for now. I haven't merged the PR using 1.18

@wvanasten can you give #96 a try?

@weinong Yes, it works with #97.
As an aside: It appears that (one of?) the tests actually modifies the config file located in ~/.kube.

fixed by #97 and #113

authors: weinong wvanasten

repo: Azure/kubelogin


text:
feat: add chunk size parameter for copying java data to native

add chunk size parameter for copying java data to native
fix minor memory leak
increase default chunk size from 1000 to 10000, for most real scenarios this is actually still probably more on the smaller side of what it should be set to (the number of rows in the dataset, but we don't want to do a count beforehand since it is expensive)

/azp run

/azp run

repo: Azure/mmlspark


text:
Angular App with Azure Devops - Error : Failed to find a default file in the app artifacts folder (dist). Valid default files: index.html,Index.html.

Hi all, since Azure static web app went public preview, i just wanted to try deploying an angular application which i have deployed with github actions in the past using azure devops.
I tried different ways in configuring the app_location , but nothing seem to be working. What could be the issue?
Here is the error log with azure devops
Copy '/working_dir/node_modules' with all dependencies to '/working_dir/.oryx_all_node_modules'...
Copying production dependencies from '/working_dir/.oryx_prod_node_modules/node_modules' to '/working_dir/node_modules'...
Preparing output...
Copying files to destination directory '/ss-oryx/app'...
Done in 2 sec(s).
Removing existing manifest file
Creating a manifest file...
Manifest file created.
Done in 172 sec(s).
---End of Oryx build logs---
Finished building app with Oryx
Failed to find a default file in the app artifacts folder (dist). Valid default files: index.html,Index.html.
If your application contains purely static content, please verify that the variable 'app_location' in your workflow file (located in .github/workflows) points to the root of your application.
If your application requires build steps, please validate that a default file exists in the build output directory.
For further information, please visit the Azure Static Web Apps documentation at https://docs.microsoft.com/en-us/azure/static-web-apps/
If you believe this behavior is unexpected, please raise a GitHub issue at https://github.com/azure/static-web-apps/issues/
Exiting
Finishing: AzureStaticWebApp
Here is the YAML:
`trigger:

master

pool:
vmImage: ubuntu-latest
steps:

task: NodeTool@0
inputs:
versionSpec: '10.x'
displayName: 'Install Node.js'

task: AzureStaticWebApp@0
inputs:
app_location: "/"
api_location: "api"
output_location: "dist/meme4fun"
env:
azure_static_web_apps_api_token: $(deployment_token)

script: |
npm install -g @angular/cli
npm install
ng build --prod
displayName: 'npm install and build'
`

Here is the Angular App Repository : https://github.com/sajeetharan/meme4fun
Note : I have tried with all possible values for output_location and app_location as well. why does the error says .github/workflows when i am trying to deploy with azure devops?

@sajeetharan Can you run a GitHub Actions deployment with these inputs to confirm that this is still working with GitHub?
app_location: "/"
api_location: "api"
output_location: "dist/meme4fun"

In your workflow above, you are running a build after the deployment. Is there a reason for this?
We use the same container to build in both GitHub and DevOps. Looks like we need to clean up the error messages to be more environment agnostic. @miwebst

Thanks @anthonychu  seems there was a typo in the package.json , i was able to successfully deploy with azure devops.
Also thanks for the hint on the order in the YAML. it was not intentional
Published a blog on the same :  https://sajeetharan.com/2021/04/02/azure-static-web-apps-with-azure-devops/

hey @sajeetharan i am facing this same issue while deplyoing my Nextjs website as a static web app, i get the following error
Failed to find a default file in the app artifacts folder (.next). Valid default files: index.html,Index.html.
i also tried many possible values for the output location. none worked, hope you could help.

let's have a look!

This is the error

Hey, i found the fix
i was running  "build": "next build' instead of  "build": "next build && next export"`
:)

@DeepakR-28 Sorry just now I noticed, glad that you've found a fix

authors: DeepakR-28 anthonychu sajeetharan

repo: Azure/static-web-apps


text:
AVM-Review

Check for previous/existing GitHub issues

[X] I have checked for previous/existing GitHub issues

Module specific issue

[X] I confirm that this issue is about this AVM module and not about the resource itself, or how to use Terraform.

Issue Type?
I'm not sure
(Optional) Module Version
No response
(Optional) Correlation Id
No response
Description
Dear module owner,
As per the agreed module ownership requirements & responsibilities at the time of assignment, the AVM Team is opening this issue to request you to kindly review your module against the below AVM specs and confirm that they are met by the module. We appreciate if you don't close this issue till the review is complete. This review is required as a pre-req to be able to eventually publish the module as v1. AVM team would be happy to assist with the review and any questions that you might have around this.
Requested action is to complete below tasks and update the status column in the table below by editing this issue.
### Tasks
- [x] Per SFR2, kindly confirm your module is WAF aligned, in particular the service specific [WAF reliability](https://learn.microsoft.com/en-us/azure/well-architected/service-guides/) & [APRL](https://azure.github.io/Azure-Proactive-Resiliency-Library/services/) high priority recommendations are implemented by default if applicable.

#
Spec
Status [Y/N/NA]
Comments

1
ID: SFR1 - Category: Composition - Preview Services
Y

2
ID: SFR2 - Category: Composition - WAF Aligned
Y
NAT Gateway  is not zone redundant and will require us to create subnet for each node pool for a location with an availability zone.We have therefore agreed to use the load balancer for the meantime to resolve this  reduce the complexity of the module

3
ID: SFR3 - Category: Telemetry - Deployment/Usage Telemetry
Y

4
ID: SFR4 - Category: Telemetry - Telemetry Enablement Flexibility
Y

5
ID: SFR5 - Category: Composition - Availability Zones
Y
this is automatically deduced using the location and using the module https://github.com/claranet/terraform-azurerm-regions/blob/master/REGIONS.md

6
ID: SFR6 - Category: Composition - Data Redundancy
Y

7
ID: SNFR25 - Category: Composition - Resource Naming
Y

8
ID: SNFR1 - Category: Testing - Prescribed Tests
Y

9
ID: SNFR2 - Category: Testing - E2E Testing
Y

10
ID: SNFR3 - Category: Testing - AVM Compliance Tests
Y

11
ID: SNFR4 - Category: Testing - Unit Tests
see comment
Using the end to end tests for this

12
ID: SNFR5 - Category: Testing - Upgrade Tests
see comment
Using the end to end tests for this

13
ID: SNFR6 - Category: Testing - Static Analysis/Linting Tests
Y

14
ID: SNFR7 - Category: Testing - Idempotency Tests
Y

15
ID: SNFR24 - Category: Testing - Testing Child, Extension & Interface Resources
Y

16
ID: SNFR8 - Category: Contribution/Support - Module Owner(s) GitHub
Y

17
ID: SNFR20 - Category: Contribution/Support - GitHub Teams Only
Y

18
ID: SNFR9 - Category: Contribution/Support - AVM & PG Teams GitHub Repo Permissions
Y

19
ID: SNFR10 - Category: Contribution/Support - MIT Licensing
Y

20
ID: SNFR11 - Category: Contribution/Support - Issues Response Times
Y

21
ID: SNFR12 - Category: Contribution/Support - Versions Supported
Y

22
ID: SNFR23 - Category: Contribution/Support - GitHub Repo Labels
Y

23
ID: SNFR14 - Category: Inputs - Data Types
Y
confirm

24
ID: SNFR22 - Category: Inputs - Parameters/Variables for Resource IDs
Y
might not be applicable

25
ID: SNFR15 - Category: Documentation - Automatic Documentation Generation
Y

26
ID: SNFR16 - Category: Documentation - Examples/E2E
Y
samples for the deployments

27
ID: SNFR17 - Category: Release - Semantic Versioning
Y

28
ID: SNFR18 - Category: Release - Breaking Changes
Y

29
ID: SNFR19 - Category: Publishing - Registries Targeted
Y
once published

30
ID: SNFR21 - Category: Publishing - Cross Language Collaboration
Y

31
ID: RMFR1 - Category: Composition - Single Resource Only
Y

32
ID: RMFR2 - Category: Composition - No Resource Wrapper Modules
Y

33
ID: RMFR3 - Category: Composition - Resource Groups
Y

34
ID: RMFR4 - Category: Composition - AVM Consistent Feature & Extension Resources Value Add
Y

35
ID: RMFR5 - Category: Composition - AVM Consistent Feature & Extension Resources Value Add Interfaces/Schemas
Y

36
ID: RMFR8 - Category: Composition - Dependency on child and other resources
Y

37
ID: RMFR6 - Category: Inputs - Parameter/Variable Naming
Y

38
ID: RMFR7 - Category: Outputs - Minimum Required Outputs
Y

39
ID: RMNFR1 - Category: Naming - Module Naming
Y

40
ID: RMNFR2 - Category: Inputs - Parameter/Variable Naming
Y

41
ID: RMNFR3 - Category: Composition - RP Collaboration
Y

42
ID: PMFR1 - Category: Composition - Resource Group Creation
Y

43
ID: PMNFR1 - Category: Naming - Module Naming
Y

44
ID: PMNFR2 - Category: Composition - Use Resource Modules to Build a Pattern Module
Y

45
ID: PMNFR3 - Category: Composition - Use other Pattern Modules to Build a Pattern Module
Y
not using another pattern module

46
ID: PMNFR4 - Category: Hygiene - Missing Resource Module(s)
Y

47
ID: PMNFR5 - Category: Inputs - Parameter/Variable Naming
Y

48
ID: TFFR1 - Category: Composition - Cross-Referencing Modules
Y

49
ID: TFFR2 - Category: Outputs - Additional Terraform Outputs
Y

50
ID: TFNFR1 - Category: Documentation - Descriptions
N
Question in upstream template

51
ID: TFNFR2 - Category: Documentation - Module Documentation Generation
Y

52
ID: TFNFR3 - Category: Contribution/Support - GitHub Repo Branch Protection
Y

53
ID: TFNFR4 - Category: Composition - Code Styling - lower snake_casing
Y

54
ID: TFNFR5 - Category: Testing - Test Tooling
Y

55
ID: TFNFR6 - Category: Code Style - The Order of resource and data in the Same File
Y
Enforced by the pipeline

56
ID: TFNFR7 - Category: Code Style - The Use of count and for_each
Y

57
ID: TFNFR8 - Category: Code Style - Orders Within resource and data Blocks
Y
Checked automatically by the pipeline

58
ID: TFNFR9 - Category: Code Style - Order within a module block
Y

59
ID: TFNFR10 - Category: Code Style - Values in ignore_changes passed to provider, depends_on, lifecycle blocks are not allowed to use double quotations
Y

60
ID: TFNFR11 - Category: Code Style - null comparison as creation toogle
Y

61
ID: TFNFR12 - Category: Code Style - Optional nested object argument should use dynamic
Y

62
ID: TFNFR13 - Category: Code Style - Use coalesce or try when setting default values for nullable expressions

See comment

63
ID: TFFR14 - Category: Inputs - No enabled or module_depends_on variable
Y

64
ID: TFNFR15 - Category: Code Style - Order to define variable
Y

65
ID: TFNFR16 - Category: Code Style - Name of a variable MUST follow rules
Y

66
ID: TFNFR17 - Category: Code Style - Every variable MUST come with a description
Y

67
ID: TFNFR18 - Category: Code Style - Every variable MUST have an appropriate type
Y

68
ID: TFNFR19 - Category: Code Style - variable containing confidential data should be declared as sensitive = true
Y

69
ID: TFNFR20 - Category: Code Style - Declare nullable = false when it’s possible
Y

70
ID: TFNFR21 - Category: Code Style - MUST NOT declare nullable = true
Y

71
ID: TFNFR22 - Category: Code Style - MUST NOT declare sensitive = false
Y

72
ID: TFNFR23 - Category: Code Style - variable with sensitive = true MUST NOT have default value unless the default value represents turning off a feature, like default = null or default = []

73
ID: TFNFR24 - Category: Code Style - Deal with deprecated variable
Y

74
ID: TFNFR25 - Category: Code Style - All verified modules MUST have terraform.tf file and required_version MUST be set
Y

75
ID: TFNFR26 - Category: Code Style - Providers MUST be declared in the required_providers block in terraform.tf and MUST have a constraint on minimum and maximum major version
Y

76
ID: TFNFR27 - Category: Code Style - Declaration of a provider in the module
Y

77
ID: TFNFR28 - Category: Code Style - output MUST be arranged alphabetically
Y

78
ID: TFNFR29 - Category: Code Style - output contains confidential data should declare sensitive = true
Y

79
ID: TFNFR30 - Category: Code Style - Dealing with Deprecated outputs
Y

80
ID: TFNFR31 - Category: Code Style - locals.tf MUST contain only locals blocks
Y

81
ID: TFNFR32 - Category: Code Style - local should be arranged alphabetically
Y
we have multiple locals in the local file

82
ID: TFNFR33 - Category: Code Style - local should use types as precise as possible
Y

83
ID: TFNFR34 - Category: Code Style - Feature toggle MUST be used to ensure forward compatibility of versions and avoid unexpected changes caused by upgrades
Y
NA

84
ID: TFNFR35 - Category: Code Style - Changes that might be breaking change MUST be reviewed with caution
Y
NA

85
ID: TFNFR36 - Category: Code Style - Example code MUST set prevent_deletion_if_contains_resources to false in provider block
Y

86
ID: TFNFR37 - Category: Code Style - Module owner MAY use tools like newres
Y

@nellyk I have a doubt about TFNFR13. Do we need to change this code ?
https://github.com/Azure/terraform-azurerm-avm-ptn-aks-production/blob/2a5406b5dc3837aad7d11f790bd458205b324b69/main.tf#L258-L261
Maybe be need to use the coalescelist function ?

@zioproto  yes and we need to use this

@mbilalamjad & @matt-FFFFFF  we are now in a good place to get this reviewed as we have gone through the list

authors: mbilalamjad nellyk zioproto


text:
[Client emitter] Generate a metadata file while emitting

We want to save some metadata in a file along with the emitted code, that can be used for some automation purposes. For instance, @weshaggard would want to use it to build a mapping of package version with support api-version
Proposal
Create a file metadata.json that contains:
{
  "api-version": "2015-06-01"
}

This file is not generated by default, and is enabled if the flag emit-metadata: true is passed in the tspconfig.yaml.
Each emitter will need to do that code, as TCGC should not be responsible to write files on disk. We could have though TCGC building the dict for us, with a getMetadataInfo() that emitters just have to put on disk. This way, this is consistent cross-language.

I think the proposal makes sense. About the filename, since SDK users usually don't need care about it, we could mark it with _ to declare it is inner file so maybe _metadata.json is better.

though tcgc should be a lib depended by language's emitter, it has the ability to emit the metadata file if needed.

@srnagar is suggesting we're merging that with the current apiview_properties.json file, and I feel it makes sense to avoid having too much files

@srnagar is suggesting we're merging that with the current apiview_properties.json file, and I feel it makes sense to avoid having too much files

agree. emitter could use client.apiVersions[-1] to get the api version. @iscai-msft do you think we need to add more explicit property in SdkClientType to indicate the api version client generated from?

we have getDefaultApiVersion right now, I feel that's the best way to do it. We could add a defaultApiVersion property, but I think we're good for now

getDefaultApiVersion need the raw typespec namespace. i don't think it is a good way to get default.

Hmm that's a very good point, yes we can go with client.apiVersions[-1] for now / add another property, but I think we can go without adding the property for now

authors: iscai-msft lmazuel msyyc tadelesh

repo: Azure/typespec-azure