search

pulumi / pulumi-terraform-bridge

A library allowing Terraform providers to be bridged into Pulumi.
Apache License 2.0
194 stars 43 forks source link

Automatically release providers when the bridge is released #2267

Open VenelinMartinov opened 2 months ago

VenelinMartinov commented 2 months ago

What happened?

~The last released has not kicked off releases of the providers.~ ~https://github.com/pulumi/pulumi-gcp/pull/2243 seems to be lacking the needs-release label~ ~This has prevented the bridge fixes from going out to users.~

Maybe this never worked and I am misremembering. It would be great to have this and it'd be quite easy - bridge update PRs need the needs-release label applied.

This will ensure all the latest bridge fixes make it to providers.

Example

.

Output of pulumi about

.

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction. To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

t0yv0 commented 2 months ago

Not a fan of triggering releases unless there're important features to flush out. @mjeffryes may recall if we documented this anywhere but prior discussions suggested a stale policy that is having a constraint that providers should be on the bridge version no older than X weeks, not necessarily latest, and we release to catch up.

VenelinMartinov commented 2 months ago

If I recall correctly, we currently release providers if they haven't been released for 2 weeks.

What's wrong with having providers on the latest bridge? They could be patch releases and could be opt out for AWS if desired.

The upside is that if the bridge was released in providers automatically, there'd be less stuff to keep track for maintainers, who already have quite a few things to keep track of. I've missed releasing providers with bridge fixes at least a few times.

VenelinMartinov commented 2 months ago

Example https://github.com/pulumi/pulumi-gcp/issues/2096 - we fixed the bridge issues some time ago but this didn't make it to the provider for more than a week (5 days due to bridge release delay, 5 due to GCP release delay)

https://github.com/pulumi/pulumi-terraform-bridge/issues/1940 was another one, which was deemed a P1 - (passing a string for an int type was broken) and this affected all providers. We have no mechanism of triggering a release in all providers, even if we wanted to. This means that the fix took weeks to propagate.

t0yv0 commented 2 months ago

I'm all for having it fully automated so maintainers do not spend time on this. The gradual rollout is a feature, not a bug though, similar to blue-green deployments of changes in high-traffic prod systems we could use a staggered strategy, which I think we have now by accident of how the system works. Releasing the bridge updates immediately in all providers would move to a 0->100 strategy. If we can keep up with fixes/rollbacks quickly it can be good, but there's something to be said for staggering to reduce bug impact to customers of the more widely deployed providers.

VenelinMartinov commented 2 months ago

Would it make sense to automate Tier 2 and 3 providers and keep tier 1 to manual? This mostly achieves this staggering effect without adding any complexity to the deployments?

t0yv0 commented 2 months ago

Possibly, that's not bad. I suggest fleshing out a concrete proposal on exactly how the automated upgrades will work in a doc to thread through providers ideation to get comments. Can be brief, just a paragraph or two. Definitely can work something out here.

  1. here's how it works now
  2. here's how we want it to work
  3. what's better about this
  4. any risks or downsides
t0yv0 commented 4 days ago

One very useful ability is hotfixing the providers that is propagating an emergent bridge fix.