Do not recommend jet grouping if there is no native counterpart

[muvaf]

What problem are you facing?

We have released AWS, Azure and GCP providers built with Terrajet with provider-jet-* name and *.jet.crossplane.io group suffix in order to not conflict with native providers when they are installed in the same cluster.

However, we don't really need to do that for providers whose native counterpart does not exist. At the end of the day, the provider running in the cluster satisfies all Crossplane features, in fact, more than the native ones in some cases thanks to automation. Also, it's straightforward to switch to an implementation where external API is directly called instead of Terraform CLI, so we'll see providers who have a mix of controller variants and having to make a grouping change makes it a breaking change by nature.

So, unless there is a counterpart that calls APIs directly that we'd like to differentiate, I don't think we should recommend a naming convention different than usual Crossplane provider naming conventions. Overall, we shouldn't the cost of confusion if we don't have to.

How could Terrajet help solve your problem?

We can update the guide to use usual naming conventions, for example provider-<short name> instead of provider-jet-<short name>. Also update the defaults here.

[negz]

I'd prefer us to be consistent, and stick the the jet distinction even in cases where there is only a jet variant. My rationale:

• More consistent, is to me, less confusing. "Jet providers always have jet in the name" is conceptually simpler than "jet providers have jet in the name only when there is a conflict with an existing provider".
• I'm (still) not bought into the idea that we'll have single provider binaries that are a mix of jet generated controllers and other implementations. We've discussed this at some length before, but to me it comes down to wanting a clear distinction along the lines of operational characteristics. Invoking Terraform binaries for example presumably has debugging and performance implications that are different from making API calls via a native SDK.
• We think the long term future of providers does not involve wrapping Terraform. if provider-foo does wrap Terraform and we're not open to mixing and matching controller implementations inside a single package/binary then that leaves us stuck having to figure out what to call the not-Terraform variant of provider-foo when it eventually surfaces.

[muvaf]

Jet providers always have jet in the name

The point I'm trying to get across is that I don't think there is a concept called Jet providers. Today there are providers that call other CLIs because some APIs are not publicly documented or wrap C programs. All those methods have XRM and managed reconciler in common and we'd call them just Crossplane providers because that's what users care in their day to day operations.

Invoking Terraform binaries for example presumably has debugging and performance implications that are different from making API calls via a native SDK.

In my experience, the errors you see (except late-init ones we see when you first try the resource) are almost exactly the same since they are returned from the same API and I'm not sure if the debugging difference is worth the separation. In fact it's easier to debug the jet controllers since the operations are same in all controllers. And this has come up a few times, so I'd really like to see real demonstrations of this argument.

if provider-foo does wrap Terraform and we're not open to mixing and matching controller implementations inside a single package/binary then that leaves us stuck having to figure out what to call the not-Terraform variant of provider-foo when it eventually surfaces.

That's, in fact, what I'm trying to avoid but with the assumption that we will have to mix and match one way or another. Even if we strictly disallow mix and match, there will be cases where developers will want to use their own controller instead of calling Terraform provider because of a bug and the more resources you have, the higher probability there will be to get into a deadlock with the dependency, i.e. can't upgrade TF provider from 1.0 to 1.1 because of bug A in resource X but can't stay in 1.0 because of bug B in resource Y.

Another case where you'd want to mix and match is if you have fewer resources than 50 (almost all TF providers that are not the big three) and don't want to invest in a new provider from scratch because it won't be as attractive as the jet one until it gets to coverage close to the original one and also there will have to be a migration path once it is.

The mix and match, IMO, is inevitable, so we should decrease the cost of doing that to enable devs to provide the best UX. Instead of having to figure out what to call the not-Terraform variant of provider-foo, vendors will get stuck with provider-jet-foo even if all of the resources call APIs directly.

[turkenh]

I believe one of the key questions to make a decision here is whether we can see terrajet as an implementation detail. Because, if we could claim that, then having a single provider would be the best way to go simplifying to answer the following questions:

• As a platform developer, should I choose a jet or a native one while building my platform?
• As a platform developer, how can I migrate from jet to native or native to jet because of some reason.
• Would both be maintained or one would become uncared if the other option is good enough.
• As a cloud/saas provider, should I create/maintain a jet or native one?

So, I think the confusion that could be caused by having multiple flavors of the same provider is not less than the confusion caused by not being consistent with 3 big.

With all the effort done in Terrajet to provide a consistent XRM compliant API so far, I think we are quite confident to say Terraform is just an implementation detail. We all are on the same page on native controllers being better than the ones calling Terraform behind the scenes due to multiple reasons but from an API POV, not much changes between them.

In short, I believe we can provide the best user experience* by having a single one and could move to native in a per resource-based approach instead of having both options side by side.

*

• As a platform developer, I don't care how you're doing that, I just want this cloud resource with this desired state.
• As a platform developer, I don't want to deal with migration at some point.
• I know that this provider will be well maintained no matter it runs terraform or directly calls the API internally.
• As a cloud/saas provider, I can easily/immediately bootstrap a terrajet provider for my service. I can then move to native controllers resource by resource as needed.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.