fix: disk id enumeration overwrite

[lsjostro]

this fixes a regression where disk ids get overwritten when you for example have a ide0 and scsi0 disk device.

[lsjostro]

was not that easy as the API will return the order randomly of the disks. so need to figure out a better solution.

[lsjostro]

need to search for disks in a predictable order

[mleone87]

rewrite some logic of disks handling in API is critical, actually is broken with more than a couple of disks

[lsjostro]

yes, I agree! but this fixes it at least and makes it predictable. but it might break for people upgrading that relay of a certain order. So what do use say? a big disclaimer somewhere? I think people will hit this mostly from the tf-provider?

[mleone87]

Fixing automatons will be up to user, priority is to fix it ;)

[lsjostro]

some issues still with this, don't know if this code or something with the tf-provider? so need to think about it over the weekend I guess. Feel free to think about it as well. 😄

[mleone87]

My point of view on this topic is to build a strong code base in the api to handle all disks use cases and the fix the provider side with changes, also breaking changes, we will handle that.

On API side we are open to any change unless they are stable enough

[Tinyblargon]

sorry to interject, but I've actually been working on a reimplementation of the qemu disks in #187 I can look into making it mergeable this weekend or sometime next week.

[mleone87]

hey @Tinyblargon glad to hear about that, I'll be more than happy to test and debug the code

[lsjostro]

That would be awesome @Tinyblargon!

[lsjostro]

moving ide to last works (proxmox cloudinit uses ide). but adding additional ide disks/devices will fail tf-provider. But it works in a predictable way at least. 😄. But as long as one pick any other device type it will work as expected.

[mleone87]

hey @lsjostro still needed now with big merge?

[lsjostro]

nope. :) I will close this one! cheers!