azure-rest-api-specs
azure-rest-api-specs copied to clipboard
Azure
Failed to process request content for Container Group when LogType is ContainerInstanceLogs
After tested, I found it failed to process request content for Container Group from service side when LogType is ContainerInstanceLogs. Could you help to have a look? Thanks. Http request:
PUT https://management.azure.com/subscriptions/xx-xx-xx-xx/resourceGroups/acctest-cgtest/providers/Microsoft.ContainerInstance/containerGroups/backend
{
"location": "westeurope",
"properties": {
"containers": [
{
"name": "backend",
"properties": {
"image": "microsoft/aci-helloworld",
"command": [],
"ports": [
{
"protocol": "TCP",
"port": 80
}
],
"environmentVariables": [],
"resources": {
"requests": {
"memoryInGB": 1.5,
"cpu": 1
}
}
}
}
],
"restartPolicy": "Always",
"ipAddress": {
"ports": [
{
"protocol": "TCP",
"port": 80
}
],
"type": "Public"
},
"osType": "linux",
"volumes": [],
"diagnostics": {
"logAnalytics": {
"logType": "ContainerInstanceLogs",
"metadata": {},
"workspaceId": "xx-xx-xx-xx",
"workspaceKey": "xxxxxxxxx"
}
}
},
"tags": {}
}
Error message:
containerinstance.ContainerGroupsClient#CreateOrUpdate: Failure sending request: StatusCode=400 -- Original Error: Code="InvalidRequestContent" Message="The request content was invalid and could not be deserialized: 'Error converting value \"ContainerInstanceLogs\" to type 'System.Nullable`1[Microsoft.Azure.CloudConsole.Providers.Common.Entities.LogAnalyticsLogType]'. Path 'properties.diagnostics.logAnalytics.logType', line 1, position 441.'."
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @dkkapur.
Valid value is “ContainerInstance” not “ContainerInstanceLogs”, @neil-yechenwei
@macolso, thanks for your response. After tested, it still failed with "ContainerInstance" and threw below error message. Seems it didn't pass the property validation according by the error message. Could you take a look for this issue? If it's api bug, please fix it asap since we're blocked now. Thanks. Http request:
PUT https://management.azure.com/subscriptions/xx-xx-xx-xx/resourceGroups/acctest-cgtest/providers/Microsoft.ContainerInstance/containerGroups/backend
{
"location": "eastus2",
"properties": {
"containers": [
{
"name": "backend",
"properties": {
"image": "microsoft/aci-helloworld",
"command": [],
"ports": [
{
"protocol": "TCP",
"port": 80
}
],
"environmentVariables": [],
"resources": {
"requests": {
"memoryInGB": 1.5,
"cpu": 1
}
}
}
}
],
"restartPolicy": "Always",
"ipAddress": {
"ports": [
{
"protocol": "TCP",
"port": 80
}
],
"type": "Public"
},
"osType": "linux",
"volumes": [],
"diagnostics": {
"logAnalytics": {
"logType": "ContainerInstance",
"metadata": {},
"workspaceId": "xx-xx-xx-xx",
"workspaceKey": "xxxxxxx"
}
}
},
"tags": {}
}
Error message:
containerinstance.ContainerGroupsClient#CreateOrUpdate: Failure sending request: StatusCode=400 -- Original Error: Code="LogAnalyticsMetadataNotAllowed" Message="Log Analytics metadata is not allowed for log type: 'ContainerInstance'.
And The rest api spec still instructs that valid value is ContainerInstanceLogs. Could you also fix this issue on rest api spec?
BTW, I am using go sdk as client.
@neil-yechenwei, we'll fix the issue with the REST API and reflect thisin the documentation. If you remove the metadata field, you should have a successful deployment.
Hi @macolso. Thanks for the issue identification :) Do you know if Azure plans to release a new API schema and eventually improve its testing / validation? Imho, the API specs are widely used to autogenerate code and is considered as a source of truth. Patching auto-generated code does not seem a good practice to me.
This issue is blocking all consumers of the API spec (e.g. Terraform, Go, Rust) from creating containers that log directly to Azure Monitor/Log Analytics. As far as I can tell, the underlying API implementation does support this and it is just the spec that needs updating. Can we please have an update on this?
its been quiet for a long time, any update on this? its blocking indeed a lot of people of sending logs/history to Azure Monitor/Log Analytics.
Ping pong as somebody else mentioned this is blocking at least Terraform still..
It's been 3 years already and the issue yet remains.
hashicorp/azurerm == 3.59.0 snippet:
resource "azurerm_container_group" "this" {
name = "${var.project_environment}-${var.project_name}-cg"
location = var.project_location
resource_group_name = var.resource_group
ip_address_type = "Public"
os_type = "Linux"
tags = local.tags
diagnostics {
log_analytics {
log_type = "ContainerInstanceLogs"
workspace_id = azurerm_log_analytics_workspace.llm.workspace_id
workspace_key = azurerm_log_analytics_workspace.llm.primary_shared_key
}
}
container {
name = "inference-server"
image = local.docker_inference_image
cpu = "3.5"
memory = "13"
ports {
port = 5001
protocol = "TCP"
}
}
}
Error:
│ Error: creating Container Group (Subscription: "xxx"
│ Resource Group Name: "yyy"
│ Container Group Name: "zzz"): performing ContainerGroupsCreateOrUpdate: containerinstance.ContainerInstanceClient#ContainerGroupsCreateOrUpdate: Failure sending request: StatusCode=0 -- Original Error: Code="LogAnalyticsMetadataNotAllowed" Message="Log Analytics metadata is not allowed for log type: 'ContainerInstanceLogs'."
│
│ with azurerm_container_group.this,
│ on container_group.tf line 20, in resource "azurerm_container_group" "this":
│ 20: resource "azurerm_container_group" "this" {
Including metadata = {} in order to drop any possible metadata that is populated automatically did not help.
I wonder why such an approach travels across the latest official documentation pages when it's already been broken for 3 years.
Ran into the same issue, with provider[registry.terraform.io/hashicorp/azurerm] ~> 3.65.0
Same problem here.. How come such a problematic bug is still unresolved more than 3 years later? (hashicorp/azurerm ~> 3.75.0)
This issue is blocking all consumers of the API spec (e.g. Terraform, Go, Rust) from creating containers that log directly to Azure Monitor/Log Analytics. As far as I can tell, the underlying API implementation does support this and it is just the spec that needs updating. Can we please have an update on this?
I also stumbled across this using terraform - my (albeit a bit ugly) workaround was the dosed use of the az-api provider with the azapi_update_resource: https://registry.terraform.io/providers/Azure/azapi/latest/docs/resources/azapi_update_resource The storyline is:
- create your containerinstance using the azurerm-provider without the logging parameters
- create an azapi_update_resource referencing the URI of the containerinstance and just setting the parameters to change (in this case the json part properties.diagnostics.logAnalytics); in this case, there's no validation against the api definition.
- azapi_update_resource under the hoods fetches the original resource and patches it with the given snipplet. The only caveat is that missing parts of the resource get request also have to be supplied; an example for these missing resources are confidental data like secrets.
My full solution is looking like that:
resource "azurerm_container_group" "mycontainer" {
name = var.mycontainer_name
location = var.location
resource_group_name = var.rg
ip_address_type = "None"
os_type = "Linux"
image_registry_credential {
server = var.docker_registry_server
username = var.docker_registry_username
password = var.docker_registry_password
}
container {
name = "mycontainer"
image = "${var.image}"
cpu = "0.5"
memory = "1"
environment_variables = {
"MY_VARIABLE" = var.my_variable
}
secure_environment_variables = {
"MY_SECRET" = var.my_secret
}
}
}
# necessary because of: https://github.com/Azure/azure-rest-api-specs/issues/9768
resource "azapi_update_resource" "room_certbot_diagnostics" {
type = "Microsoft.ContainerInstance/containerGroups@2023-02-01-preview"
resource_id = azurerm_container_group.mycontainer.id
body = jsonencode({
properties = {
"containers" : [
{
"properties" : {
"environmentVariables" : [
{
"name" : "MY_VARIABLE",
"value" : var.my_variable,
},
{
"name" : "MY_SECRET",
"secureValue" : var.my_secret,
}
],
}
}
],
diagnostics : {
logAnalytics : {
"logType" : "ContainerInstance",
"workspaceId" : azurerm_log_analytics_workspace.log_workspace.workspace_id,
"workspaceKey" : azurerm_log_analytics_workspace.log_workspace.primary_shared_key
}
},
"imageRegistryCredentials" : [
{
"password" : var.docker_registry_password,
"server" : var.docker_registry_server,
"username" : var.docker_registry_username
}
]
}
})
}
Has this been resolved in 2024? Having the same issue now...
