
Remove default "terraform" partner_id - ZikkZakk
https://github.com/terraform-providers/terraform-provider-azurerm/issues/4747
======
mitchellh
Hi everyone,

I'm the founder of HashiCorp.

I want to make something clear up front that this does NOT allow us to see
resource usage by Terraform user and does NOT result in credits or revenue
sharing at all. HashiCorp has no direct access to this information in any
form.

Before explaining "why" we do this, I do want to apologize and say that adding
this without proper explanation was a mistake. It isn't clear why it's there
and I think enough companies have hurt users with features like this that
defaulting to a negative reaction makes sense. I'm sorry. I promise (and will
explain) that our usage is not nefarious, and even further this ID does not
give us access to anything directly.

The "why": the partner ID lets Microsoft better track Terraform usage
internally (with data they already have access to, just lets them filter it by
Terraform). Microsoft does share aggregate information with us ("x% of all
Azure workloads") but does not go any more granular than that.

This information is used by Microsoft to gauge how much investment to make
into Terraform as well as what resources are a priority to fix any issues or
make improvements to. Microsoft is a big partner of ours[1] and as part of
that partnership they employ full-time people to improve the Terraform
provider. Part of making that partnership successful is measuring the output
of it and this is one mechanism that allows them to do that. I can say that
the usage information given by this partner code has directly resulted in more
headcount being assigned to the "azurerm" Terraform provider that may not have
been otherwise assigned.

Note that all this partner ID does is let Microsoft filter by "Terraform."
They already have and use all information around what resources are being spun
up by accounts (as you would expect any IaaS or even SaaS to do). This doesn't
introduce anything else other than that easier filter for them.

The partner ID used by Terraform was provided directly by Microsoft and
generated by them. It is not associated with our Azure accounts at all. This
is an extra assurance that we don't have access to any partner information
using this ID.

Some have pointed out that the docs specifically state that this is used for
credit/revenue sharing. That is a feature of the partner ID but not one that
we use. Azure is a large, complex platform and features are overloaded for
different use cases. In our case, the partner ID does NOT provide us with any
information, credits, or revenue. Zero.

Going forward, we will be building an option to opt out of using this partner
ID. It was already noted in other comments that we made it configurable since
there are other use cases for it that a Terraform user might want to set. We
haven't made a direct option to opt-out and we will do that in the next
release. As a workaround today, you can set any partner ID you want (an
invalid value) and we will send that and that will function similarly.

Note that for years all our providers have also sent a custom user agent that
notes Terraform and the version of Terraform being used. We haven't been
secret about this (I've publicly tweeted about it many times), but it feels
important to call out in this comment as well. This information could also be
used by providers to determine Terraform usage. Similarly, HashiCorp has no
direct access to this information.

I'm happy to answer any questions, and once again I'm sorry about how this
wasn't communicated up front.

EDIT (2 hours after posting): We've opened a PR for adding the opt-out
behavior which also includes an environment variable you can set. We plan to
include this as part of the next patch release. [https://github.com/terraform-
providers/terraform-provider-az...](https://github.com/terraform-
providers/terraform-provider-azurerm/pull/4751)

[1]: [https://www.hashicorp.com/blog/hashicorp-and-microsoft-
exten...](https://www.hashicorp.com/blog/hashicorp-and-microsoft-extend-multi-
year-collaboration-agreement/)

~~~
orvtech
> ...Going forward, we will be building an option to opt out of using this
> partner ID...

One should be opted out by default and the option should be build to opt in.

~~~
kraig
i dont know why this is getting downvoted

~~~
paulddraper
Because people think it's a fine default.

Just like I think "User-Agent: curl/7.58.0" is a fine default.

~~~
colechristensen
Given the amount of fingerprinting and screwing with the content based on
platform, I'd be happy to do away with user-agent completely. I'm tired of
websites that are completely broken on mobile and force you to use the app (or
_constantly_ remind you about their app) and everybody returning a globally
unique identification which is so hard to scrub.

------
freedomben
This does indeed look bad, but I'd like to give Hashicorp the benefit of the
doubt and allow them to respond before grabbing any pitchforks/torches. Let's
not forget they've added a ton of value to many of our lives and have never
required a cent (for the free version).

~~~
mitchellh
Thank you. I'm hijacking this top comment at the moment to share that I have
responded:
[https://news.ycombinator.com/item?id=21389908](https://news.ycombinator.com/item?id=21389908)

I hope that makes it very clear what this is, why it's there, and what we're
doing about the GitHub issue raised. If there are any questions, please
respond to that thread and I'll be happy to respond.

------
davidu
Isn't this what Partner ID is designed for?

"Injects" is a strong word.

Maybe "Hashicorp provides an Azure Partner ID in Terraform deployments for
deployment stats, and some users may not want that" would be a better title.

~~~
acruns
By adding their partner ID, they get revenue based on the usage in Azure.

~~~
kstrauser
I _think_ I'm OK with that? If it doesn't increase my costs, and Hashicorp
gets paid because I used their tools to deploy my services, and Azure is
getting paid more because I probably deploy more services because it's easier
thanks to Terraform, doesn't everyone win?

~~~
Townley
I'm mostly okay with it, though the deployment plan isn't the proper place for
what's essentially a referral code.

Hashicorp is facilitating the purchase of Azure products, and deserves a cut
of the revenue. But this should be handled on the account level, either on
sign-up or as an account field (a-la Amazon Smile)

I'm less okay with the tracking for analytics purposes, but if Terraform finds
some way to make it easy for me to tell cloud providers who sent me, that
seems fair.

~~~
taftster
If it's a referral code at the account level, then you can't easily have
multiple providers supplying tools for the client. Whereas, if it's part of
the deployment itself, the utilization of one partner tool can be
distinguished over another.

Or in other words, the "cut of the revenue" needs to be in proportion to the
usage of Azure resources generated by the partner tool. I think that's why its
designed this way.

------
manigandham
It's a random GUID that lets the company track how much their tool is used in
deployments in Azure. It's about as noninvasive as it gets.

~~~
NegativeLatency
Feels sort of like a User Agent string to me.

~~~
CobrastanJorji
I agree. I'm not mad at cURL for setting a user-agent string, and I don't see
how this is much different unless I'm missing something.

------
jaboutboul
This is a non-issue and PURE FUD. They are anonymously tracking usage of their
product on azure. BFD.

------
royletron
I wonder how much the outraged individual has contributed financially to what
is a fabulous tool that all DevOps engineers benefit directly from. I get that
it should have been discussed, but even still - the code is there for all to
see and read whenever they can be bothered too. They can even fork and build
it without this. It's this level of open source snobbery that makes me think
that eventually only the big companies will contribute and open source
projects - and only because it brings developers onto their platforms.

~~~
mynameisvlad
This sets a dangerous precedent. You shouldn't need to contribute financially
to file an issue about an open source product you use.

Edit: cleaned up the wording a bit by removing the "raise a concern" bit.
Hopefully that removes any ambiguity in the comment.

~~~
BookPage
> or file an issue about an open source product you use.

Are you kidding me? This is literally the mechanism to provide feedback to the
contributors.

~~~
mjlee
I think the statement is meant to be read as:

> You shouldn't need to contribute financially to [...] file an issue about an
> open source product you use.

~~~
mynameisvlad
Yes, sorry, I had an extra bit in there that I removed before posting the
comment, and in the process made it a bit harder to read. This is definitely
what I was intending.

------
sargram01
How is this different than a web server reporting itself as Jetty? Or a web
browser repotting it’s Chrome?

~~~
koolba
A better example may be nginx which does not provide an out of the box way to
disable the “Server” header. It’s part of a non-core addon.

------
eitally
It's there because of the kind of partner agreement ISVs have with the cloud
provider. There are two things at play: 1) How does the cloud provider know
what the ISV is selling, in order to credit them for it (discounts,
incentives, program membership, etc)?

2) How do the sales reps get paid on related deals? This goes both ways: the
ISV's reps get paid regardless but they need a way to tag the cloud-based deal
in their own CRM, and the cloud sales reps need to be able to get paid base on
the ISV partner's cloud deals, and that's really hard unless there is a
concrete way to relate the ISV's sales deal to cloud consumption associated
with the end customer.

One of the ways to do this is on the front end via deployment tracking (like
this Terraform ID). Another way is to do it on the back end through billing
account linkages. In any case, the end customer shouldn't really care one way
or another -- these are just mechanisms to ensure the partner relationship
between ISV and hyperscaler is well understood.

------
nops
Please edit title - only applies to Terraform using the azurerm provider

~~~
pm90
Agreed, the title is spreading FUD and is very clickbaity.

------
CaliforniaKarl
I admit I don’t closely follow Hachicorp commits, blogs, changelogs, etc.. Is
it possible that there was another commit providing a rationale for the
change? Maybe a changelog entry explaining what the UUID represents and how it
benefits Hachicorp, Microsoft/Azure, and end users?

------
tus88
How is this different to a web app that uses a Google Maps api key (for
example)?

------
dimitar
It sucks that you cannot have several partner ids. Partners have to fight over
who will get their partner id at the end. Hashicorp at least allow to specify
a different one in their software.

------
trpc
Thanks for the swift response from the founder, I just don't understand those
types of sneaky github issues that surprisingly get very rapidly to the HN
frontpage as smear campaign against startups, when even setting the
application name and version in the user agent header in a FOSS application
that can be opted-out is considered spying, then everything can be spying

------
c3534l
Anyone know if this causes users to become noncompliant with GDPR, FedRAMP, or
similar regulatory protections?

~~~
dewey
Did you read what the issue is even about? It's about setting the string
"terraform" in a config file. It's not some personal data or evil tracking
token.

~~~
tedshroyer
I believe you are mistaken. It appears to inject a tracking token.
[https://docs.microsoft.com/en-us/azure/marketplace/azure-
par...](https://docs.microsoft.com/en-us/azure/marketplace/azure-partner-
customer-usage-attribution)

~~~
dewey
It's not a user-specific tracking token, it's a tool specific token
([https://github.com/terraform-providers/terraform-provider-
az...](https://github.com/terraform-providers/terraform-provider-
azurerm/pull/4663))

All users of terraform will look the same, it's to get a general idea of "how
many terraform using instances are there".

------
giancarlostoro
If its free you are (or can be) the product. I dont see this one as an issue
so long as its not flooding personal information to Microsoft outside of what
you provide them when you register to Azure.

~~~
judge2020
The concern is Hashicorp receiving data about deployments even outside of the
Azure marketplace, although the documentation makes it look like it'll only be
in aggregate/will be anonymized

> ISV partners will receive reporting for deployments from the Azure ISV
> Customer Usage Attribution program. Data may be anonymized for deployments
> from outside of Azure Marketplace.

------
karambir
I love Terraform and in general Hashicorp but this is not acceptable. Changes
like these should be discussed with the community first.

They should also state clearly what information they are getting from
Microsoft. Azure docs on this is way too generic and filled with "maybes".

~~~
rossmohax
Hashicorp is kinda well known for not engaging with community whatsoever :)

~~~
karambir
I am not sure about this. Till recently I have mostly used their products with
just needing to read some docs and initial guides. Only recently I was using
Terraform and Packer so much that I had fumbled on some issues and saw the
community discussions on those. Hashicorp was engaging there atleast.

~~~
rossmohax
You'll see when you open small bugfix PR and they let it rot or when stumble
upin years old issue, discussed over and over again without any resolution in
sight.

~~~
bdcravens
I've had an issue (in my case the VWWare provider for Vagrant) that didn't get
the resolution I wanted, but on the whole, I feel they do a good job. As a
smallish company, they have to be very selective WRT resource allocation.

------
jcims
Decision-making like this is the kind of thing that diminishes support for
open source in large old-guard type organizations.

Why should terraform get credit for the infrastructure? It doesn’t drive
demand. If they want a piece of that, leave it commented with a hat-in-hand
appeal.

