Scratch that, on further research I have learnt a few things so I am re-asking my questions. In the time package, I see that the TF package has a provider function rfc3339_parse which is not present in the pulumi provider even though it is updated to include the latest tf provider. Looking at the pulumi-terraform-bridge codebase, it has provision for terraform provider resources and datasources but not functions. Is that the reason why the above function was not included? I also see that

ExtraFunctions

is a thing although i am not sure how to implement it. Would it be possible to implement this extra function in the TF provider as an

ExtraFunction

? Could we add another function to parse an unix timestamp too?

@cuddly-engineer-30016 I forwarded this ask to the engineers on our providers team.

Thanks Ringo, I know its a lot of questions but all of that arose from a single issue I am expecting to have 😅

@cuddly-engineer-30016 from my understanding what you wanna create is a so called

augmented provider

. https://github.com/pulumi/pulumi-terraform-bridge/blob/master/docs/new-provider.md#augmenting-a-terraform-provider For this the Terraform Bridge provides the

MuxWith

configuration. Please refer to the documentation for details. https://github.com/pulumi/pulumi-terraform-bridge/tree/master/docs For an example you can refer to my Pulumi Azure repository https://github.com/pulumi/pulumi-azure/compare/master...tmeckel:pulumi-azure:feat/mux-provider-go

@big-architect-71258 From what I read from the MuxWith docs, its used to combine another provider with the TF sourced provider. In my question, I am not looking at another provider except the time provider from Terraform. As in the screenshot, all "resources" are implemented except the "function". Am i misunderstanding something?

@cuddly-engineer-30016 If you wanna change, add a resource or data source (Pulumi function) to an upstream TF provider you have to implement those new functionalities in a separate provider an mux it with the upstream provider. You cannot change the upstream mappings directly. Well of course you can fork the upstream repo, change the code and create a wrapped Pulumi provider out of that. But I think that's not what you want at all.

Ah! now I get what you mean. Honestly, I dont want to touch the terraform provider repos, neither create new terraform specific functionality which is why I was confused on the need to mux with the existing pulumi time package. I was looking into directly creating a PR in the pulumi time package which adds a couple of `ExtraFunctions`in the

ProviderInfo

of the package like such

Looping in @ancient-policeman-24615 and @enough-garden-22763: any pitfalls lurking here if @cuddly-engineer-30016 will implement any (additional) functions?

Just to clarify, I am looking to implement 2 functions, 1. to parse a rfc 3339 timestamp and output its constituents including the unix timestamps 2. to parse a unix timestamp and output its constituents including the rfc 3339 timestamps I want to have this as 1. Some providers outputs unix timestamps and some other RFC 3339 where some providers input unix and others rfc 3339 and I need to convert between the 2 formats when passing outputs to inputs 2. I am using a declarative setup, hence yaml, hence I can't do it myself programatically, unless I am an idiot and missing something

@cuddly-engineer-30016 seems the data source

rfc3339_parse

(1) has been added with the 0.11.0 release. The provider is compiled with this version. So the data source should already be mapped to a Pulumi function. I'll check that on my side, why this is not the case. As I understand you (2) is missing even from the upstream provider. Right?

@big-architect-71258 the issue here is that besides

Resources

and

Datasources

in a TF provider, since TF 1.8, they also offer

Functions

. I dropped this question with the same two people you looped in, but on our corporate Slack since I'm not sure we support bridging functions already.

As I understand you (2) is missing even from the upstream provider. Right?

yep, if we want to keep 1:1 parity, I can try implementing it updstream first

@cuddly-engineer-30016 upstream first is always preferred for a wrapped provider, because more people will participate from the newly added functionality. But I'm not sure how quickly you'll get the stuff in with the people at Hashicorp. If you have any issues there we could implement the function in the Pulumi provider either by using

muxWith

or with

ExtraFunctions

as a fall back.

@big-architect-71258 right now, we are using a declarative setup for our infra and hence YAML was the way to go. I am ok with writing small scripts that can be invoked from the

Pulumi.yaml

but I dont think that's possible, is it? i really don't want to write and maintain a provider for utility functions.

@cuddly-engineer-30016 ah okay now we're getting the complete picture here. You can always use

pulumi convert

to convert your YAML program into a supported programming language of your choice without losing the connection to the state. A conversion is simply another representation of the stack in another language. Perhaps you reached the end of using YAML here in a meaningful way. If you don't wanna do that you could open a PR in the Pulumi STR provider which is exactly for that purpose: provide YAML programs with additional functions. https://www.pulumi.com/registry/packages/str/ You might add your missing functions there. Like parsing dates and stuff. Perhaps generating UUIDs as well.

Hi everyone, we've seen the Functions support in the 1.8 release notes but at a first glance it looked like a feature that's mostly adding value to TF users that's a bit less relevant to Pulumi users because you can always use your language stdlib to transform data, parse dates and so on. However there might be legitimate use cases to support these, perhaps to inform

pulumi convert

or perhaps because providers start publishing important functionality in the form of these functions. From the notes I gather one more use case is when targeting Pulumi primarily from YAML having access to these functions is even more important since there's no TypeScript-like escape hatch of just calling the stdlib. Let's perhaps start by filing a feature request in https://github.com/pulumi/pulumi-terraform-bridge about this and start correlating the use cases there, I can work with my team on getting this in the priority queue. If there's interest in contributing this feature that's also wonderful...

We want to stick with declarative infra code, and so, yaml is my only option. I understand the benefits that imperative can have but I love the fact that I won't need to worry about best practices in code in one more place. Anyway, if I am only using YAML, here are my options: 1. Wait and contribute to handling TF provider functions in the bridge. This will give me the function for rfc3999->unix but not the other way round, unless I add that provider function to the TF provider, which I doubt will be accepted given the times. 2. Contribute to the

pulumi-time

package and add the features as functions using

MuxWith

or

ExtraFunction

. The problem lies with how the addition of the features will play with future updates to the pulumi package and if something will break. 3. Contribute to the

pulumi-str

package. Its a package by the pulumi folks themselves and as far as I see, they contain some string manipulation functions. In my opinion, time formatting should not be present in string manipulation modules/packages. If the Pulumi folks are ok with adding function to convert the datetime formats from RFC3999 to Unix and vice versa, I am happy to open a PR. 4. Create my own private provider package that contains all the utility functions that I would need. Is this even possible? I know that I can point to a server in

pulumi plugin install

but does it work for a private repo?

Creating your own provider is of course possible and by far gives the most flexibility. You can use https://github.com/pulumi/pulumi-go-provider to make one. In terms of packaging the private binary, you build a Go binary you need to distribute and reference as in https://www.pulumi.com/docs/concepts/projects/project-file/#example-project-file-with-all-possible-attributes then you can use anything it defines. If you're not using TypeScript or Python then this pathway does not require worrying about the relevant language SDK distribution, it's just one Go binary.

@enough-garden-22763 you are absolutely correct. Adding these 2 functions as built ins should be the way to go as this problem is only present for yaml stacks. I think it could help others so I will prioritize creating a pr. Hopefully it gets accepted

Awesome! Thank you!

@enough-garden-22763 created a draft PR. I have implemented only 1 of the 2 functions and am yet to write the tests. Please note that I have no idea how to test this (other than the tests). If you are fine with the tests passing, then I will go ahead and write the second function too. Please do a review as I dont know the codebase at all and just using

toBase64

as an example