provider-azure bootDiagnostics for VM not working

[techny210]

What happened?
VM can't be created from a simple k apply -f vm.yaml , it errors out with the following:
LinuxVirtualMachine in version "v1beta1" cannot be handled as a LinuxVirtualMachine: strict decoding error: unknown field "spec.forProvider.bootDiagnostics.storageAccountUri"

How can we reproduce it?
Create a vm with bootDiagnostics enabled

What environment did it happen in?
Crossplane version:
latest 1.14.5

kube vesion 1.28.3 on microk8s Ubuntu 22.04 LTS

apiVersion: compute.azure.upbound.io/v1beta1
kind: LinuxVirtualMachine

it is set correctly but for some reason, API does not recognize it as such
API docs on the website clearly show this option

bootDiagnostics:
storageAccountUri:

k get providers
NAME INSTALLED HEALTHY PACKAGE AGE
provider-azure-compute True True xpkg.upbound.io/upbound/provider-azure-compute:v0.40.0 8d
provider-azure-storage True True xpkg.upbound.io/upbound/provider-azure-storage:v0.40.0 8d

[techny210]

Update:
So pretty sure this is a bug. I have investigated further, enabled boot diagnostics manually from the portal (bad idea but appropriate for this test), and then looked at how the VM looked from crossplane perspective (or kubectl rather).
It was fine and running but the entries for bootDiag revealed this:

bootDiagnostics:

• storageAccountUri: ""

So, the first one according to the manual is an array, fine. The storageAccuntUri is a string but here is the catch it cannot be empty field or it will bark about a bad value. One would think that not existing string and an empty string would be the same thing but it ain't. (at least in my brain it was)
So for those who stumbled upon this the same way I did the answer is: Include the quotes " " and define an empty stirng and viola, you will have your bootDiag enabled and be able to see any error messages if you need to.
In the end, I'm still not sure what is the proper value of this field. I tried the short name of the storage account from the same yaml, then full resourceID : /subscriptions/xxx-xxx-xxx/resourceGroups/xxx/storagename to no avail.
it would be nice to have storageAccountRef here...
Long story short, the docs should specify in more detail what this should be, and if there is no value treat it as an empty string and maybe use some regex like s//""/g or something.
Anyway, hope this will help someone. Feel free to do as you wish with this ticket.

[turkenf]

@techny210, could you please give us the used MRs and reproduction steps so we can reproduce the bug?

[techny210]

There was no MR per se. You can reproduce it by creating a vm with bootDiagnostics enabled. I could not.

[turkenf]

Could you please share the sample manifest of the resource you are trying to create, as follows:

apiVersion: compute.azure.upbound.io/v1beta1
kind: LinuxVirtualMachine
metadata:
  annotations:
    meta.upbound.io/example-id: compute/v1beta1/linuxvirtualmachine
  labels:
    testing.upbound.io/example-name: example
  name: example
spec:
  forProvider:
    adminSshKey:
    - publicKey: <....>
    adminUsername: adminuser
    location: West Europe
    networkInterfaceIdsRefs:
    - name: example
    osDisk:
    - caching: ReadWrite
      storageAccountType: Standard_LRS
    resourceGroupNameSelector:
      matchLabels:
        testing.upbound.io/example-name: example
    size: Standard_F2
    sourceImageReference:
    - offer: UbuntuServer
      publisher: Canonical
      sku: 16.04-LTS
      version: latest

[techny210]

kind: LinuxVirtualMachine
metadata:
  annotations:
    meta.upbound.io/example-id: compute/v1beta1/linuxvirtualmachine
  labels:
    deployment-name: crossplane-test
  name: testvm
spec:
  forProvider:
    adminSshKey:
    - publicKey: ssh-rsa ...   
    username: mgn
    adminUsername: mgn
    allowExtensionOperations: true
    availabilitySetId: ""
    bootDiagnostics:
    - storageAccountUri: ""   # <--- This is the part that MUST be here, found it the hard way
    location: East US
    networkInterfaceIdsRefs:
    - name: testvm-nic
    osDisk:
    - caching: ReadWrite
      storageAccountType: Standard_LRS
    resourceGroupNameSelector:
      matchLabels:
        deployment-name: crossplane-test
    size: Standard_B1ms
    sourceImageReference:
    - offer: 0001-com-ubuntu-server-jammy
      publisher: Canonical
      sku: 22_04-lts-gen2
      version: latest
    userData:...

[turkenf]

@techny210, I cannot reproduce the error with the information you provided:

> k get linuxvirtualmachine.compute.azure.upbound.io/example -o yaml -w
apiVersion: compute.azure.upbound.io/v1beta1
kind: LinuxVirtualMachine
metadata:
  annotations:
    ...
  labels:
    testing.upbound.io/example-name: example
  name: example
  resourceVersion: "127892"
  uid: 2988e613-87c2-4a5b-9f7c-089db79ca991
spec:
  deletionPolicy: Delete
  forProvider:
    adminSshKey:
    - publicKey: ssh-rsa ...
        [email protected]
      username: adminuser
    adminUsername: adminuser
    allowExtensionOperations: true
    bootDiagnostics:
    - storageAccountUri: ""
    computerName: example
    disablePasswordAuthentication: true
    extensionsTimeBudget: PT1H30M
    location: West Europe
    maxBidPrice: -1
    networkInterfaceIds:
    - /subscriptions/038f2b7c-3265-43b8-8624-c9ad5da610a8/resourceGroups/example/providers/Microsoft.Network/networkInterfaces/example
    networkInterfaceIdsRefs:
    - name: example
    osDisk:
    - caching: ReadWrite
      storageAccountType: Standard_LRS
    patchAssessmentMode: ImageDefault
    patchMode: ImageDefault
    priority: Regular
    provisionVmAgent: true
    resourceGroupName: example
    resourceGroupNameRef:
      name: example
    resourceGroupNameSelector:
      matchLabels:
        testing.upbound.io/example-name: example
    size: Standard_F2
    sourceImageReference:
    - offer: UbuntuServer
      publisher: Canonical
      sku: 16.04-LTS
      version: latest
  initProvider: {}
  managementPolicies:
  - '*'
  providerConfigRef:
    name: default
status:
  atProvider:
    ...
    ..
    .
  conditions:
  - lastTransitionTime: "2024-01-22T06:36:12Z"
    reason: ReconcileSuccess
    status: "True"
    type: Synced
  - lastTransitionTime: "2024-01-22T06:37:11Z"
    reason: Available
    status: "True"
    type: Ready
  - lastTransitionTime: "2024-01-22T06:37:03Z"
    reason: Success
    status: "True"
    type: LastAsyncOperation

Please try with v0.41.0 and let us know.

[github-actions]

This provider repo does not have enough maintainers to address every issue. Since there has been no activity in the last 90 days it is now marked as stale. It will be closed in 14 days if no further activity occurs. Leaving a comment starting with /fresh will mark this issue as not stale.

[techny210]

Old issue, upgrade fixed it