https://pulumi.com
Join Slack
I'm using `pulumiverse_time.Rotating` for triggering rotation of a client credential. And now as soo...
# general
a
I'm using 
pulumiverse_time.Rotating
for triggering rotation of a client credential. And now as soon it expired it throws an error... • Can't run any pulumi operations • Removing the resource definition from code doesn't help • Explicitly destroying the Rotating resource 
pulumi destroy --target <the rotating urn>
doesn't work The state seems to be broken after this happened.
Copy code
Diagnostics:
  time:index:Rotating (rotate-credentials-lz-dev):
    error: Preview failed: Expected an Object, got: {<nil>}
Any ideas on how to resolve this?
m
I believe @big-architect-71258 maintains that package — any ideas Thomas?
b
@miniature-musician-31262 First off: never had such an error before with the Time provider. Secondly I updated the the Pulumi Time Provider 2 weeks to a new version of TF Bridge and bumped the upstream provider to v0.11.0. @adventurous-butcher-54166 if not already done please pin the Time provider to the last version v0.0.16 and run 
pulumi refresh
again. Please let us know the outcome. cc @enough-garden-22763
a
This happened originally on 
v0.0.16
and I had already tried updating to 
v0.0.17
without resolving the issue. 
pulumi refresh
doesn't work either – still getting the same error.
b
@adventurous-butcher-54166 what version of the Time provider you initially had in your Pulumi program?
a
pulumiverse-time = "0.0.16"
b
Oh and what's the reason behind destroying the rotating resource using the 
--target
command line option 
pulumi destroy --target <the rotating urn>
?
a
I tried that in an attempt to get rid of the Rotating resource completely
b
The resources from the Time provider only exist in the stack alone. Nothing gets deployed anywhere. So why not simply remove the code which created the resource. This should destroy and remove it from the stack.
a
Yeah I had already tried removing the Rotating declaration from code but that didn't help either.
b
That's definitely odd! Removing the resource from the code should indeed remove it from the stack. Just for the protocol: which programming language you're using? Aside that: if you have already removed the code for the rotating resource a 
pulumi destroy --target
won't work. If the resource is still present in the state, you must use 
pulumi state delete
to remove it.
Check 
pulumi state delete --help
how to use it and for valuable hints like how to find the resource URNs.
a
Ok I'm trying something here – in my Pulumi.yaml project configuration I have the refresh option set to always.
Copy code
options:
  refresh: always
When I disable refresh I'm able to run preview – so this seems to be connected with that.
b
🤔 Then a "manual" 
pulumi preview --refresh
shouldn't work either. Only to get it straight: 
pulumi preview
(without a refresh) works? And if so: what's the diff shown afterwards?
a
Yes – running pulumi preview/up with --refresh always triggered the error. I managed to run pulumi up (without refresh) and applied changes successfully to some other resources (which btw. have no dependencies or connection with Rotating. And now I'm actually able to run 
pulumi pre --refresh
and it will show Rotating will be created.
b
So now I'm quite baffled: I thought you removed the rotating resource from the code. I doubt Pulumi will create a resource just out of thin air 😮
a
Sorry – yeah I just removed the resource from code temporarily to see if that would work but then added it back so this run has it declared the same way as it was before.
So right now the Rotating resource is still in the state and rotation seems to be triggering – however it does not trigger without running with --refresh. And also, it is showing as create and not replace – is that expected behavior?
Ok I was able to reproduce this in a freshly created project: • Only one Rotating resource • Rotation set to 1 minutes • 
refresh: always
enabled 
__main__.py
Copy code
from pulumiverse_time import Rotating, RotatingArgs

rotation = Rotating(
    resource_name="rotation",
    args=RotatingArgs(
        rotation_minutes=1,
    ),
)
First I ran this with 
v0.0.17
installed and after 1 minute had passed it replaced the Rotating resource successfully. However after destroying the stack and creating again with 
v0.0.16
installed the error will show up when running after the rotation expiration time has passed. Relevant runtime information: • Pulumi CLI version 3.112.0 • Go version go1.22.1 • Python version 3.12.2 • Arch: Apple Silicon Darwin/arm64
b
> So right now the Rotating resource is still in the state and rotation seems to be triggering – however it does not trigger without running with --refresh. And also, it is showing as create and not replace – is that expected behavior? Yes that's the expected behavior because that's how Terraform and it's providers work. No, refresh, no change on the resource. But I wanna loop in @enough-garden-22763 and @ancient-policeman-24615 here, because they have more in-depth knowledge of the Pulumi Terraform Bridge and if it might be possible to have wrapped resources like the ones from the Time provider to change/trigger without a refresh.
However after destroying the stack and creating again with 
v0.0.16
installed the error will show up when running after the rotation expiration time has passed.
Seems to me that 
v0.0.16
is broken. If you create and destroy by sticking to 
v0.0.17
, will the error show up as well?
Perhaps we should create a native Pulumi Provider instead of wrapping the TF provider. I have the suspicion that this approach would be better suited to Pulumi's lifecycle, as the time provider's resources are very special. @ancient-policeman-24615
a
When creating from v0.0.17 - the error does not show up.
b
So that's (partly) good news, because, to me, this indicates that the version of Pulumi Terraform Bridge compiled into the Time provider handles the case correctly instead the older versions 👍🏻
a
Yep exactly – hopefully this will be okay now that I've replaced the Rotation with v.0.0.17.
👍🏻 1
a
Yes that’s the expected behavior because that’s how Terraform and it’s providers work. No, refresh, no change on the resource. But I wanna loop in @enough-garden-22763 and @ancient-policeman-24615 here, because they have more in-depth knowledge of the Pulumi Terraform Bridge and if it might be possible to have wrapped resources like the ones from the Time provider to change/trigger without a refresh. (edited)
I think the correct way to implement Rotation is with Diff, not refresh (both for pulumi and terraform). If this doesn’t work well with TF without refresh, it’s not going to work super well with Pulumi unless refresh is used. There aren’t any bridge hooks to override this kind of behavior yet. If 
time
works correctly in TF without refresh, then it’s just a bridge bug and we can fix it.
Perhaps we should create a native Pulumi Provider instead of wrapping the TF provider. I have the suspicion that this approach would be better suited to Pulumi’s lifecycle, as the time provider’s resources are very special. @ancient-policeman-24615
Given ☝️, I’m sure that you can build a native provider that works better then the bridged version.
👍🏻 1
b
If this doesn’t work well with TF without refresh
@ancient-policeman-24615 I think the TF Time provider is build around the lifecycle of TF and thus relies on the refresh cylce that TF always carries out. Currently they use a plan modifier to force an update on the resource when the rotation time is over. https://github.com/hashicorp/terraform-provider-time/blob/536dec8b9dd951e3045d575c0d8c159f3fa782e9/internal/provider/resource_time_rotating.go#L262 Not sure though when the modifier is called. My suspicion is that it only gets called on refresh.
a
TF does allow you to disable refresh, but many of their providers break when you do. 
pulumi-aws
maintains it’s own global tags implementation because TF’s version doesn’t work with refresh disabled.
🤣 1
b
@ancient-policeman-24615 so the suspicion here is that, when you disable 
refresh
for TF with the TIME provider it'll behave like the wrapped provider when running without an refresh using Pulumi. Right?
a
Yes. If not it’s just a bridge bug.
👍🏻 1
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by