5 ms·

There is a lot to complain about on Azure. But a lot of his posts are wrong (he just could not figure it out - a documentation problem likely) or complaining n

by RajT88 3y ago

There is a lot to complain about on Azure. But a lot of his posts are wrong (he just could not figure it out - a documentation problem likely) or complaining not about Azure, but Terraform.

marcyb5st 3y ago
About the terraform part, I am not sure about how it works for Azure, but GCP providers are developed /maintained by Googlers. Assuming it's the same, terraform problems are actually Azure problems (IMHO). Disclaimer: Googler but working nowhere close to Google's Terraform efforts.
- RajT88 3y ago
  I don't believe that's the case here. The Azure RP AFAIK is maintained by Terraform folks. Possibly there's a few MSFT contributors.
empuxr 3y ago
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.
- RajT88 3y ago
  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.
  - ElephantAndARat 3y ago
    > 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.
    - RajT88 3y ago
      The hidden API's are a corner case. They are not generally used for deployment. My point is valid.
      - ElephantAndARat 3y ago
        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
        RajT88 3y ago
        You're wrong about that anyways. It appears to be a documentation miss in the REST API doc. https://learn.microsoft.com/en-us/powershell/module/az.automation/new-azautomationcertificate?view=azps-11.3.0 https://learn.microsoft.com/en-us/powershell/module/az.autom... 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". Yes, the docs suck.
mingus88 3y ago
I can concur. At an old job we had a slack channel filled with terraform issues like these. We were an AWS shop. Terraform tends to be one of those things that can quickly become a nightmare if you take up it’s offer to manage everything in your infrastructure.
- quesera 3y ago
  I've been feeling this lately. A new guy came in and Terraformed the crap out of a very consistent and reliable AWS infrastructure. I don't know whether to blame the tool or the implementation, but the injection of unpredictability is extremely unwelcome! We're only using it on the non-production account so far, fortunately. I prefer boring systems. The more boring, the better.
  - kikimora 3y ago
    What do you use instead, CF?
viraptor 3y ago
A documentation problem is an Azure problem. A problem with support is an Azure problem. It's all part of a package.
codingdave 3y ago
Bad documentation as a root cause is still a bad experience running on the platform, so I'm not sure how that would make the posts wrong.
nunez 3y ago
After having used Azure for a year, I believe every single post on this thread.

by RajT88 3y ago

There is a lot to complain about on Azure. But a lot of his posts are wrong (he just could not figure it out - a documentation problem likely) or complaining not about Azure, but Terraform.

marcyb5st 3y ago

About the terraform part, I am not sure about how it works for Azure, but GCP providers are developed /maintained by Googlers. Assuming it's the same, terraform problems are actually Azure problems (IMHO). Disclaimer: Googler but working nowhere close to Google's Terraform efforts.

RajT88 3y ago
I don't believe that's the case here. The Azure RP AFAIK is maintained by Terraform folks. Possibly there's a few MSFT contributors.

empuxr 3y ago

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.

RajT88 3y ago
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.
- ElephantAndARat 3y ago
  > 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.
  - RajT88 3y ago
    The hidden API's are a corner case. They are not generally used for deployment. My point is valid.
    - ElephantAndARat 3y ago
      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
      - RajT88 3y ago
        You're wrong about that anyways. It appears to be a documentation miss in the REST API doc. https://learn.microsoft.com/en-us/powershell/module/az.automation/new-azautomationcertificate?view=azps-11.3.0 https://learn.microsoft.com/en-us/powershell/module/az.autom... 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". Yes, the docs suck.

mingus88 3y ago

I can concur. At an old job we had a slack channel filled with terraform issues like these. We were an AWS shop. Terraform tends to be one of those things that can quickly become a nightmare if you take up it’s offer to manage everything in your infrastructure.

quesera 3y ago
I've been feeling this lately. A new guy came in and Terraformed the crap out of a very consistent and reliable AWS infrastructure. I don't know whether to blame the tool or the implementation, but the injection of unpredictability is extremely unwelcome! We're only using it on the non-production account so far, fortunately. I prefer boring systems. The more boring, the better.
- kikimora 3y ago
  What do you use instead, CF?

viraptor 3y ago

A documentation problem is an Azure problem. A problem with support is an Azure problem. It's all part of a package.

codingdave 3y ago

Bad documentation as a root cause is still a bad experience running on the platform, so I'm not sure how that would make the posts wrong.

nunez 3y ago

After having used Azure for a year, I believe every single post on this thread.