Replace Pulumi "role" fix with one from upstream #16
Conversation
There was a problem hiding this comment.
LGTM.
In general, I'd love to take updates that bring us fully up-to-date with the TF provider (as in, merge 1.7.1 release into our fork).
In this case though, we had already diverged, and this cherry-picked fix brings our divergence inline with mainline so that seems fine to do as a one-off.
BTW - Do we know if #12 is still an issue, and if so whether we need to open a bug on the TF provider for this?
|
Is there any reason we wouldn't just merge 1.7.1 into our fork and kill two birds with one stone, while avoiding diverging and maintaining our own special mixture of cherry picked changes? |
|
Merging in a new TF AWS provider is just more potentially disruptive. But now's as good a time as any to take that. I'll open a PR now to just merge in 1.7.1. |
|
Great. I understand this approach more disruptive, but it's less manual work (ideally we'd never have to cherry pick), in line with where we want to go (we want to keep pushing ahead on versions), and we should be moving fast at this point (ideally not breaking things, but hey, it happens). |
|
i agree (with everything) luke said ... it does prompt a q on my part ...
since we normally trade off a fix for a new set of "unknowns" ... is there
anything "special" we should do when taking a TF update?
(for example, we could have a stress test that we don't run every day that
does a LOT more creating deletion, etc ... with various timings ... or
randomly assigns values to property bags ... or runs our own regression
tests exclusively for TF problems we've found.)
i am fine if consensus is that we don't want to spend the effort to do
something "special" here, however, i want to make sure that we make a
deliberate choice (whatever the decision) ... personally, i might advocate
this is a good way to protect ourselves ... however, i understand that
slowing down to go faster might not be a consensus move right now.
…On Mon, Jan 22, 2018 at 9:38 AM, Luke Hoban ***@***.***> wrote:
Merging in a new TF AWS provider is just more potentially disruptive.
But now's as good a time as any to take that. I'll open a PR now to just
merge in 1.7.1.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#16 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AH_5wsiLFovX0ZbqlFYkvLid7hfDZrQsks5tNMengaJpZM4RlWCy>
.
|
|
Agreed on all points - hence why I raised this point above :-). PR for merging in v1.7.1 on it's way now... |
Ideally - we would run all integration tests all the way up the stack - in pulumi-aws, pulumi-cloud, home, pulumi-ppc, pulumi-service, etc. Today, we don't have any reasonably easy way to do that up front, so our approach is just to integrate the changes quickly up the stack so that we find out about any issues within a day or so of taking a new drop (and taking corrective action if we find any issue). This is not unique to TF provider, it's the same approach as for any potentially broadly impactful changes we make in low layers of our system. |
|
again, if we decide to live with what we do today, i'm fine ... i'm a
little more concerned about 3rd party changes up and down the stack, and
again, i think we'd do something 'special' (iow, new tests, not just
'eventually running everything we have.') ... if you're a hard pass on
this, that's truly fine, you won't hurt my feelings ... i just feel that
the disruption is potentially greater over time without this, since
ideally, we'll know what we are doing to ourselves, however, won't quite
know exactly what to expect with TF, and as you point out, we want a good
window (since confidence is low) for TF update.
i'll let others have the last word.
…On Mon, Jan 22, 2018 at 9:46 AM, Luke Hoban ***@***.***> wrote:
since we normally trade off a fix for a new set of "unknowns" ... is there
anything "special" we should do when taking a TF update?
Ideally - we would run all integration tests all the way up the stack - in
pulumi-aws, pulumi-cloud, home, pulumi-ppc, pulumi-service, etc. Today, we
don't have any reasonably easy way to do that up front, so our approach is
just to integrate the changes quickly up the stack so that we find out
about any issues within a day or so of taking a new drop (and taking
corrective action if we find any issue). This is not unique to TF provider,
it's the same approach as for any potentially broadly impactful changes we
make in low layers of our system.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#16 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AH_5wj0kVh9K6-tIBq25MDgKWkrg7JIRks5tNMlrgaJpZM4RlWCy>
.
|
|
#17 brought in 1.7.1, which included the fix tracked in this PR - so I'll close this one out now. |
#5
obsoleted by
hashicorp/terraform-provider-aws#2983