They're sweet and perfectly fine most of the times. Most self-healing clusters with sophisticated permission models are perfectly replacable by one Debian/RedHat instance.
If you tell me which ones are wrong I'd be happy to look into them again. :)
We can't guarantee that all of the posts are 100% correct, although we try to confirm all of them before posting. Most of these are things we encountered during our daily work, and yes, many of them are possibly just documentation errors. But when you can't figure out how to do something in a reasonable amount of time... that's not great either.
We use Terraform as our primary Azure client, but I'd argue most of the problems with Terraform are because of fuck-ups in the underlying Azure API or Azure resource providers.
To use an example: The AppGW TLS cert/KeyVault issue.
If it works manually, but not via Terraform, it's the fault of Terraform (or possibly the underlying Go SDK, small disclaimer). The ARM API is used by the Azure portal, as well as all the SDK's.
Of course it's totally possible it doesn't work manually. It did last time I checked, and it's a pretty foundational functionality - so I'd be surprised if it didn't.
> If it works manually, but not via Terraform, it's the fault of Terraform (or possibly the underlying Go SDK, small disclaimer). The ARM API is used by the Azure portal, as well as all the SDK's.
that's not true. sure the portal uses the same APIs, mostly. it also uses its own hidden APIs for some functionality. so it is entirely possible for it to work via the portal, but not work via any API mechanism.
e.g. uploading PKCS12 certs to (IIRC) automation accounts. the UI requires a password, and also sends the cert to some back end middleware to change the cert itself. while via the REST API you can upload the cert without a password, and it remains unmodified. (without the modification process some valid PKCS12 certs will not show up on the runners, and therefore can't be used for auth.)
Note: Azure support was not helpful in resolving this matter, since if it worked via PowerShell (the cert generation and upload), then it was considered an issue with our code (ignoring the fact that our code (and libraries used) remained unchanged throughout). though changing API behavior even when specifying an API version in the request is typical for Azure.
I'm not quite sure what you mean by "not used for deployment" when they are for some cases, like the example I gave. trying to "deploy" an automation runbook that needs authentication. it'd be part of a greater solution, sure, but it'll still be part of the deployment
The AZ module is using the REST API QED - it supports the password.
In this case probably what you need to do to sniff out how it is working with the REST API is to run it in powershell with -verbose -debug and see what it is doing (or configure powershell for the fiddler proxy).
My point - just to remind you (I can almost hear you typing) - is that it's more likely to be the fault of Terraform. Undocumented Portal API's from what I have personally seen are all "read" not "write".
I think you misunderstand. the problem isn't to do with the password necessarily. I want to not have a password, which is fine. however the cert I generate and upload does not work (rather, started to stop working). if the same cert is given a password (as the portal requires it), then, uploaded via the portal, the portal changes the certificate via a hidden API (I can see it via dev tools). that cert then works fine.
that's the issue.
I believe I also tried uploading the cert I generated via PowerShell (both with and without a password), and the same problem was there. It was narrowed down to 1. certs generated by PowerShell are fine. 2. The portal uses that hidden API to transform the cert before uploading it. which neither PowerShell or the REST API do.
It might be possible to do through the API, but there is no documentation available on what you need to do. There are only PowerShell examples, which you could look into and try to replicate on your own using the API.
The shit part about this:
- Can't do it through the Azure Portal
- Can't do it through Terraform
- Docs only give you PowerShell examples
- Docs don't explain you WHY you need to do this, they just expect you to suck it up
- Why is Application Gateway only supporting user-managed identities and not system-assigned identities for this feature?
Sorry, I don't really care about which part of the Azure ecosystem is at fault here. It's a shitty experience.
As a Platform Engineer who has to work with Azure on a daily basis, I am so tired of their APIs and services making exceptions left and right, sometimes for their own shitty clients. The result is a Patchwork product suite, services never work as expected but deviate from their documentation (or rather what they are claiming is their documentation).
