https://pulumi.com
Join Slack
This message was deleted.
# package-authoring
s
This message was deleted.
b
Had to disable autonaming (
prov.SetAutonaming(255, "-")
), because it created a SIGSEGV.
Okay, successfully created the initial drop of SDK packages for Typescript/Javascriptmeow party
e
Well that's progress! Let me tag a new version
b
Oh ... Too bad 😉 
warning: resource:mssql_azuread_service_principal.Docs received a non-zero custom value &{docs/resources/azuread_service_principal.md []     false} that is being ignored. Plugin Framework based providers do not yet support this feature.
But guys you did a great job with current version of PF!
e
I think I know what's going on with AutoNaming, I'll fix the panic and I now have a ticket to actually make AutoNaming work there's a bit of legwork there
🚀 1
❤️ 1
b
Yes it's definitely progress!!!
e
Yes I tried to emit Warnings on everything we're not sure we're supporting yet
👍🏼 1
@ancient-policeman-24615 thank you for set support!
🚀 1
🎉 1
Now I'd be curious if you get to a hello world with this provider working at runtime - that's the ultimate test.. Would love to unblock if you hit any issues on that path.
♥️ 1
b
Creating the SDK is the first part. Well see what happens when the provider has to to what it's supposed to do 😎 I'll keep you posted!
e
Yep
👍🏼 1
You can drive it from Pulumi YAML without an SDK even
But SDKs should be fine too - all that is mostly battle tested code, not the new code we're testing
👍🏼 1
b
Oh your're right! That's why YAML was so important for Pulumi!
To use it from YAML the provider must be located in the 
$HOME/.pulumi/bin
directory. Right? Or something else?
e
Anywhere in $PATH
🚀 1
b
I'll give that a try first then. Now I need some sleep. It's late over here 😂 CU!
🙏 1
@enough-garden-22763 Nice! 🙂
e
Thank you for confirming.
👍 1
Any luck with runtime use of the provider? Appreciate if you have any updates on that.
b
Right now working on it. Setting up a YAML project.
e
Ty!
b
Pulumi calls the provider. But I missed setting the version correctly and I saw that I didn't implemented the configuration settings either. But so far no crash!
Any hint where I've to put the semver compatible version in 
<http://resources.to|resources.go
of the provider to> satisfy Pulumi about this?
e
ProviderInfo struct has a Version field, if you stick a value in there that should work I think.
👍🏼 1
b
Or is this something that has to be done in the upstream Terraform provider?
Looks much, much better 😄 Didn't work and crashed because of the missing configuration I guess. I'll have to work this out.
I already realized that the provider isn't programmed will full proof in mind :-D
e
Ah interesting! Well this looks great, progress indeed
👍🏼 1
b
Yes! But I call it a day. Have a nice weekend. If I find some time I'll work on this on Sunday. I'll keep you posted for sure.
🙏 1
Oh, one last question. How do I specify Provider options, when I create them explicitly like so
Copy code
provider:
    type: pulumi:providers:azure
    options:
      version: 5.38.0

  provider-mssql:
    type: pulumi:providers:mssql
I mean configuration options, not this "Pulumi" options field 🙂
There is a very thin documentation around this. But unfortunately nothing about setting the provider configuration https://www.pulumi.com/docs/reference/yaml/#explicit-provider
In Typescript I'd simply pass them as parameters. No clue how to do this in YAML.
e
Ah interesting I don't remember off the top of my head, I'll pass this to the docs team.
I'm guessing 
provider
has 
properties:
subfield but nothing beats a good example.
We also have https://github.com/pulumi/pulumi-lsp but I don't have it handy to try out
a
Provider options for explicit providers are just passed as resource properties on the provider resource
e
Can you write a squick yntax example?
Realize this is a chatgpt kind of question, need to get a licence
a
Copy code
name: example
runtime: yaml
config:
  region: us-east-1
resources:
  aws:
    type: pulumi:providers:aws
    properties:
      region: ${region}
  bucket:
    type: aws:s3:Bucket
    options:
      provider: ${aws}
🎉 2
👍 1
b
@ancient-policeman-24615 many thanks. Looks good 👍🏼 If I've time I'll add a PR to the docs repo to have this approach documented.
🙏 2
🎉 1
@enough-garden-22763 The MSSQL provider is working! 🎉meow party🚀Of course, there is still work to be done to create a real release. I also need to submit some PRs to the Terraform provider. At the moment I am working with a customized version.
e
Excellent news!
👍🏼 1
b
Yes, even better. Right now no need for me to submit any PRs to the upstream provider because they already upgraded the provider to use version 1.1.1 of the Terraform Plugin Framework. One question though: I want to ensure that at least the hostname of the SQL server is set, when the provider is called or created by Pulumi as a resource. I know there is the 
PreConfigureCallback
, but when is this function called? Only on a 
pulumi up
or as well on 
pulumi pre
? I only got to fail a `pulumi pre`when I mark the `hostname`configuration property as 
required
using 
MarkAsOptional: tfbridge.False()
. The 
PreConfigureCallback
seems not to be called on a 
preview
. Do I miss something?
e
Is that not a required property? If you make it required it should enforce being set I think?
PreConfigureCallback is not supported yet but backlogged, you can upvote that if you really need it
(that helps prioritize)
it's a small thing to support but we've got a fair bit of priorities 😓 PRs are welcome too
Is your code something that is possible to publish say at https://github.com/pulumiverse/pulumi-mssql ?
b
Yes, I could publish a pre-alpha? But something not really I wanna publish. Like to run some more tests. And perhaps wait for a some details that are currently not implemented in PF TF Bridge
e
Perhaps on a branch?
I'd just love to have a look myself as well as point people internally at Pulumi to a success story, even if it's early 🙂
D'you know which PF TF bridge features block you that's super helpful for me also to prioritize
b
For the PF TF bridge features (screenshot) and you in addition currently can't override the path to the doc files. Not things that are real blockers.
Let me ensure that the code compiles on an empty system so that I can be sure that everybody is able to run 
make provider
. I'll like to add some YAML example code as well.
e
Yeah very nice. SO the the default one is this one https://github.com/pulumi/pulumi-terraform-bridge/issues/938
👍🏼 1
I had a hunch we'll need that soon but nice to have confirmation
can't override the path to the doc files.
This one I'm not sure I'm tracking would love to understand that better, care to expand a little bit?
b
If the doc files are not setup like expected by TF Bridge you can override the path to a MD file for a resource or data source by setting the 
Docs
property of the 
tfbridge.ResourceInfo
struct.
I gave 938 a thumbs up
e
Got it, noting
❤️ 1
b
I didn't create the SDKs yet. I don't like a noisy branch 😄
You can find an example in the `example/yaml`folder
e
Huh, touche. Nice.
😀 1
♥️ 1
Yeah I sometimes wonder why we check in generated SDKs, the amount of pain in managing Git Repos is formidable as we take this off the beaten path and are fighting the tooling.
👍🏼 1
However there is an advantage I guess that code scanning tools can consume the generated content.
Also for existing Pulumi providers we can't move the Go files because user programs link against them.. So we're a bit locked into this approach of having to generate SDKs
We had some early conversations about some kind of system that publishes all the language SDKs for you, well for Go this would mean this system likely will need to manage "sidecar" GitHub repositories for the Go SDKs
b
I definitly understand why the SDKs have to be published and versioned inside the provider's Git repo. But during that initial development phase when you start to wrap a new TF provider this really clutters up you commits, when you keep constantly create the SDKs.
Oh no, please no deviations especially with Go SDK (module) stuff.
e
Noted 🙂
👍🏼 1
😂 1
Well there's possibility to ease some of the pain with tooling, even if the SDKs stay in the same repo layout. Like GHA that auto-regenerates them. Or excluding them from being visible in GitHub diffs.
b
The only way to exclude diff from Git is to use 
.gitignore
but how you'll make sure they get updated on a new release. Well perhaps with a GitHub Workflow step or something automated.
e
That's true. There was some GitHub specific feature that configures their diff viewer, but it's niche.
Yeah GitHub Workflow step would be more foolproof.
👍🏼 1
b
When I try to build the go SDK for the MSSQL provider the following error (warning) is generated.
Copy code
warning: unable to convert HCL example for Pulumi entity '#/functions/mssql:index/getSchemas:getSchemas': 1 error occurred:
        * failed to convert HCL for #/functions/mssql:index/getSchemas:getSchemas to go: invalid Go source code:

package main

import (

"<http://github.com/pulumi/pulumi/sdk/v3/go/pulumi|github.com/pulumi/pulumi/sdk/v3/go/pulumi>"
"<http://github.com/pulumi/pulumi-mssql/sdk/go/mssql|github.com/pulumi/pulumi-mssql/sdk/go/mssql>"
)
func main() {
pulumi.Run(func(ctx *pulumi.Context) error {
example, err := mssql.LookupDatabase(ctx, &mssql.LookupDatabaseArgs{
Name: "example",
}, nil);
if err != nil {
return err
}
all, err := mssql.GetSchemas(ctx, &mssql.GetSchemasArgs{
DatabaseId: pulumi.StringRef(example.Id),
}, nil);
if err != nil {
return err
}
ctx.Export("allSchemaNames", %!!(MISSING)v(PANIC=Format method: fatal: A failure has occurred: unlowered splat expression @ #-functions-mssql:index-getSchemas:getSchemas.pp:7,11-30))
return nil
})
}
: 22:30: expected operand, found '%!'(MISSING) (and 5 more errors)
Is this related to the PF support in TF bridge?
e
Ugh, no but I think it's a Pulumi bug related to documentation examples rendering
👍🏼 1
b
Python has a similar problem:
Copy code
warning: unable to convert HCL example for Pulumi entity '#/functions/mssql:index/getQuery:getQuery': 1 error occurred:
        * :0,0-0: cannot iterate over a value of type union(list(map(string)), none);
e
Yeah.
We've got a fair bit of tehse
👍🏼 1
This bit of the product is not quite on par with some of the other bits
I can say there's some work done on this but I'm sorry it still affects your build
You can mostly safely ignore
What happens it that an example is ignored from documentation strings in the generated code.
Because the rendering pipeline fails to cross-compile it from HCL to say Python
Safely as in - it's unfortunate but it does not affect runtime behavior of the provider or Python SDK
👍🏼 1
b
Yes I know that I can mostly ignore those issues around documentation and examples. But nevertheless it's a good thing that the folks at MSSQL Provider are using all of Terraform's new features.
👍 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