https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# golang
s
This message was deleted.
b
Hi Charles. I'm sorry this experience has been so frustrating
our SDK docs are autogenerated from types, and it looks like there's breakage here, I'll get someone to take a look
b
I did some digging around and the latest provider version I can find is v4.12.0, so I'm not sure how to coerce the system into using that version
b
with regards to your questions about 
GetVpc
, if you look in the docs here, you'll see the Go SDK actually mandates 
LookupVPC
- I agree it's not a great experience
b
From the VPC docs:
b
as for the versioning, we're actually in the process of releasing v4.13.0 https://github.com/pulumi/pulumi-aws/actions/runs/1038268020 It looks like you've run into a race condition whereby the SDK is published (because it uses Go modules, and the tag exists) but the release process hasn't finished publishing the binary. I'm sorry you ran into that
you'll need to pass the actual VPC id (for example, vpc-xxxxxx` as the id. The docs aren't great there, I agree with you there
I've opened an issue for this here: https://github.com/pulumi/docs/issues/6239
b
Hmm, because of typing you can't directly load that either
At least not in the 
GetVpc
call. I can pass the VPC Id as a string parameter to the containing struct for 
LookupVpc
b
as I mentioned earlier, the 
GetX
resources are actually rarely used, because most of the time you're not going to actually know the value of the resource and want to look it up. Most folks use the 
LookupVpc
methods which allows more filtering: https://github.com/pulumi/examples/blob/ca40203279f393c0c159dadcadc97c6007122997/aws-go-fargate/main.go#L21
b
Oh, I get that. The 
LookupVcp
is much easier to use, I just need to figure out how to specify which provider I want to use now. I think the docs should reflect that though rather than pointing me to the 
GetVpc
call.
b
agreed, and also I understand your frustration about the broken Godoc links
b
No worries, I get that it happens. Just not a great look for someone looking to convert from Terraform to Pulumi when basically everything was broken out of the gate.
b
re: the idinput problem, it seems we're incorrectly passing the wrong provider version. the link we generate is: https://pkg.go.dev/github.com/pulumi/pulumi/sdk/v4/go/pulumi#IDInput when it should be: https://pkg.go.dev/github.com/pulumi/pulumi/sdk/v3/go/pulumi#IDInput
this looks like a bug in our documentation generation, where it's pulling the provider version (pulumi-aws is on v4) rather than the pulumi SDK version. I've opened: https://github.com/pulumi/docs/issues/6240 to address it
b
Excellent, thanks
Do you have any examples on how to convert this:
Copy code
productionUSEast1, err := aws.NewProvider(ctx, "terraform-production", &aws.ProviderArgs{
			Region: pulumi.String("us-east-1"),
		})
So that I can use it as an input to LookupVpc?
b
all resources take a provider in their options struct, give me a sec
b
Ahhh, I have to wrap it. That makes sense
No I just need the provider to finish building and I think I'll be in good shape
Ok, I think I'm calling it. The type conversions are madness. Especially one like this: It's probably an easy fix but honestly, I'm already burned out trying to decode all the wild type conversions.
Copy code
cannot use ctx (variable of type *pulumi.Context) as *pulumi.Context
b
Sure thing, sorry you didn’t have a great experience. If you’re willing to open issues with repros we’ll get them fixed
b
It's likely that it's just me not grokking it, but I've been writing Go since the 1.4 days and this is painful. I imagine the Python version is fine since you don't have to worry about types overly much. But having to write closures and generators to convert strings to things like 
pulumi.StringArrayInput
with no direct built in conversions from 
pulumi.StringArray
makes for really messy code. I suspect this is related to the lack of generics in Go or some janky interface declarations. It's not difficult but if I threw a junior/mid at that code they'd be lost in a heartbeat.
For example:
Copy code
subnetIds                = pulumi.StringArray{
		pulumi.String("subnet-00a852a567a95c34e"),
		pulumi.String("subnet-0028f8824e50101fa"),
		pulumi.String("subnet-05fa2f619b658b49e"),
	}
Seems pretty straightforward, I don't love wrapping strings in custom types but it's easy to follow. The problem is when you're down here:
Copy code
groupArgs := &rds.SubnetGroupArgs{
			SubnetIds: subnetIds,
		}
It doesn't make a lot of sense to have to build a special closure or function to have to convert a simple list of strings to the 
pulumi.StringArrayInput
type. I would think that the inheritance model would you say 
type StringArray interface {}
Then have the input and output methods be attached to that interface where you can populate the data and have the implementation resolve correctly whichever one it needs
I'm reading this doc and realizing that the type conversions will just be all over the place https://www.pulumi.com/docs/intro/concepts/inputs-outputs/
With heavy use of reflection and type coercion which has a really gnarly code smell
FWIW, I think your product is awesome! I'm really looking forward to seeing how you all succeed, I really think you will. Honestly, I'll probably come back and try again at some point. I would love nothing more than to buy your product and rip out a ton of terraform and replace it with Pulumi using actual code rather than a DSL.
b
You’re right that this is due to a lack of generics. We’re excited about those because it will drastically remove a lot of the issues you’re talking about. I understand your frustration and I’ve felt it too, but it would be helpful to get some concrete, actionable issues opened so we can improve things. Regarding your RDS example with inputs, that doesn’t look like the right thing to have to do, but I’m unfortunately away for lunch now. Happy to try find the right way if needed. Appreciate the kind words at the end, and again, sorry you didn’t have a great experience
b
(Don't worry about this until after lunch, take some you time!) Oh, I really find your product compelling. Seriously, in general it's really well thought out. I'd love nothing better than to be able to actually have real TDD infra. Direct me to where to open issues and I'll get them posted, maybe if I can carve out some time I'll take a crack at building a PR to solve what I'm talking about. For now here's the issue that's bothering me. I'm trying to declare a subnetgroup that will be attached to an Amazon Aurora instance (next down the list if I can get the subnetgroup defined). I have a list of subnets I want to put it in, these already exist and are defined elsewhere. So I created this variable:
Copy code
subnetIds                = pulumi.StringArray{
		pulumi.String("subnet-00a852a567a95c34e"),
		pulumi.String("subnet-0028f8824e50101fa"),
		pulumi.String("subnet-05fa2f619b658b49e"),
	}
then I have:
Copy code
func main() {
	pulumi.Run(func(ctx *pulumi.Context) error {
		productionUSEast1, err := aws.NewProvider(ctx, "terraform-production", &aws.ProviderArgs{
			Region: pulumi.String("us-east-1"),
		})
		if err != nil {
			return err
		}
		groupArgs := &rds.SubnetGroupArgs{
			SubnetIds: subnetIds,
		}
		_, err = rds.NewSubnetGroup(ctx, "nextgen-data",groupArgs,pulumi.Provider(productionUSEast1),
		)
		return nil
	})
}
Which I know I need to convert the 
subnetIds
but that just seems..... antithetical to how it should work. Then the code is throwing an error about the 
ctx
not being of type 
*pulumi.Context
b
@brainy-rainbow-75025 I have a hunch that maybe you have some mixed versions of the Go SDK being used. I had the same error about Context when I had this by mistake (VS Code added the wrong package)
b
Ohhhh, interesting
I'm using VSCode, so that could be something
Do you remember what your solution is?
b
I just looked at my Go imports and ensured they were all the same version
eg v3 for the Go SDK for Pulumi, v4 for the aws provider etc
b
Oh, I'll be damned.
I take back all of it then, Mea Culpa. That cleared it right up
b
Yeah it is super confusing when it happens.
As @billowy-army-68599 said, the type conversions can be a bit annoying at times, especially for things like 
Apply
, but overall, it works reasonably well, and the productivity I’ve found with having things auto-complete, getting type errors, etc has been super helpful.
and the fact that it will error when I do something wrong type-wise is a big reason why I chose to do it in Go rather than Python (and TypeScript wasn’t really an option as I did not want to deal with async)
Glad it was reasonably sorted out though 🙂
b
Me too! I really want to love this product and I was hoping the evaluation would go well so I could start working up budgetary docs
👍 1
321 Views
Open in Slack
PreviousNext
Powered by