https://pulumi.com logo
Join Slack
Powered by
(also we shoudl thread responses, apologies)
# golang
b
(also we shoudl thread responses, apologies)
👍 1
t
Copy code
name: eks_go_aws
runtime: go
description: eks stack using aws sdk instead of eks
curious - what are u using Pulumi for (I mean which sdk / llibs) ?
b
Similar, AWS, EKS, Postgres, etc
What version of Pulumi are you running?
Seems like latest, just double checking
t
yes
Copy code
➜  eks_go_aws git:(feature/eks_go_aws) ✗ pulumi version
v3.24.1
b
Regardless, the Pulumi resource/plugin model is a bit complicated, and there are some things that are the frontend of the plugin (resource definitions, etc) which are implemented per language, and then there’s the stuff that is the backend (the actual logic), which I believe is typicaly implemented in Go
t
in this case (eks) it appears that the backend is in ts I guess.
Possibly because it was implemented in ts first
b
yeah, I’m not sure, since the EKS package I believe is just a component resource around core AWS packages
t
also what do your eks stacks look like? do u see granular resources within a cluster - such as security groups (e.g.) - I see those with the ts sdk but not with Go
b
So I’m not sure it really has a backend in the same sense.
t
I switched to using the low level aws sdk in Go.. and the stacks are very "thin"
b
Yes, the Go SDK generates them as well
This is 
pulumi-eks
, not the the core AWS 
eks
package
t
Copy code
✗ ls /home/vikas/.pulumi/plugins/resource-eks-v0.37.1                  
node_modules  package.json  package-lock.json  PulumiPlugin.yaml  pulumi-resource-eks
there is a Go binary in there.. but a buncha node modules also
what I mean by "thin" stack is:
Copy code
➜  eks_go_aws git:(feature/eks_go_aws) ✗ pulumi up   
Previewing update (eks-test):
     Type                     Name                 Plan       
 +   pulumi:pulumi:Stack      eks_go_aws-eks-test  create     
 +   ├─ pulumi:providers:aws  janus_test_east1     create     
 +   ├─ aws:eks:Cluster       test-east1           create     
 +   ├─ aws:eks:NodeGroup     default              create     
 +   └─ aws:eks:NodeGroup     observability        create     
 
Resources:
    + 5 to create

Do you want to perform this update?  [Use arrows to move, enter to select, type to filter]
  yes
> no
  details
so the stack does not get more granular than "cluster" and "nodegroup"
b
that looks liek the core AWS package
t
it is
b
which is not the same as 
pulumi-eks
(which will create many more ersources)
t
the pulumi-eks package kept blowing up for me 🙂
b
That’s a different problem, but I think that’s equivalent to what you were likely doing with TS.
t
(in Go I mean, not in TS)
yea ure probably right that it's a different problem.
b
In your repro code you have:
Copy code
cluster, err := eks.NewCluster(ctx, clusterName, &eks.ClusterArgs{
What does the import of 
eks
look like?
I have a feeling that the way you’re calling 
GetRole
is not really valid.
The public API to lookup an existing role is via 
LookupRole
to the best of my knowledge (in Go): https://www.pulumi.com/registry/packages/aws/api-docs/iam/getrole/
and if Ihad to guess, the Role you’re getting back is not fully initialized in a way that’s important to using it as an input
But it’s a wild guess.
But the 
aws
package’s 
eks
subpackage is not equivalent to 
pulumi-eks
(the latter wraps the former)
t
you are again probably right on.. I fought with that call (GetRole vs LookupRole) quite a while - it does not seem to map 1-1 with the TS version.
b
Yeah, I think TS 
getRole
is equivalent to Go’s 
LookupRole
(per docs)
t
yea but they return different / incompatible data structures .. eks cluster args needs a Role object not a 
LookupRoleResult
- which contains a string role Arn
unlike getRole in ts - which does return a 
Role
. so GetRole seems closer in that regard.
b
Yes, though my guess is that somewhere there is where your issue is with the Go side. The TS typesystem allows for a lot more flexibility in this regard, so it likely is OK
t
I don't think this is about TS flexibility.. in TS the getRole function (which per the doc is implemented as LookupRole in Golang) returns a Role object. TS is strongly typed, so u cannot mix/match specific types unless you explicitly make the (upcasted) type a generic type like Object. e.g. you cannot assign an Int to a String etc (just like Golang). Here is what happens if I use the LookupRole function in Go and pass the result to eks.NewEksCluster (which expects a *iam.Role, not a *iam.LookupRoleResult:
Copy code
eksCluster.go|63 col 26 error| InvalidIfaceAssign: cannot use instanceRole (variable of type *iam.LookupRoleResult) as iam.RoleInput value in struct literal: missing method ElementType
b
Understood - my point on TS is that 
NewEksCluster
in EKS takes a type union (I think it’s called 
pulumiIamRole
that I don’t know how it is defined), so it can handle a greater span of types. This is not possible in Go.
t
Not really. These are the args expected in TS:
Copy code
instanceRole?: pulumi.Input<aws.iam.Role>;
    /**
    serviceRole?: pulumi.Input<aws.iam.Role>;
And in Go:
Copy code
InstanceRole iam.RoleInput
ServiceRole iam.RoleInput
b
I may have been delirious when I looked at it 🙂
t
To me this just seems like an oversight on the Go sdk side, and I am about to abandon my Go efforts 😕 seems like too much of a battle and not enough reward to make it worthwhile.. thanks for engaging, and for your insights.
b
Ah yes - here is why I thought this: https://www.pulumi.com/registry/packages/eks/api-docs/cluster/#instancerole_nodejs Not sure why the doc gen is wrong here on what the type should be.
t
🤷
b
FWIW, we do have quite a bit of code (all in Go) with Pulumi, including for EKS and things work fine. We don’t have your particular use case of passing in a pre-existing role though - we create the role as part of our Pulumi program
Copy code
cluster, err := eks.NewCluster(ctx, "...", &eks.ClusterArgs{
		VpcId:            networkConfig.VPC.ID(),
		PrivateSubnetIds: pulumi.ToStringArrayOutput(networkConfig.Subnets.PrivateSubnetIDs),
		EnabledClusterLogTypes: pulumi.StringArray{
			pulumi.String("api"),
			pulumi.String("audit"),
			pulumi.String("authenticator"),
		},
		SkipDefaultNodeGroup: pulumi.BoolPtr(true),
		InstanceRoles: iam.RoleArray{
			eksClusterInstanceRole,
		},
		NodeAssociatePublicIpAddress: pulumi.Bool(true),
		Version:                      pulumi.String("1.20"),
		UseDefaultVpcCni:             pulumi.Bool(true),
		CreateOidcProvider:           pulumi.Bool(true),
		ProviderCredentialOpts: eks.KubeconfigOptionsArgs{
			RoleArn: pulumi.String(okeraCfg.Require("assume-role-arn")),
		},
	}, pulumi.Provider(awsProvider))
	if err != nil {
		return nil, err
	}
Copy code
eksClusterInstanceRole, err := createEKSClusterRole(ctx, awsProvider, "...")
t
yea I was considering that as well. That was not an option for us until recently due to internal governance restrictions, but it may be now. In any case, this experience, coupled with the fact that ts code seems to be used anyway, (plus my admitted bias against Go syntax 😬) is making me seriously reconsider continuing this effort.
Thanks for sharing your code and experience.
b
Of course. Happy to help. I do think Go’s type system gets somewhat in the way at times, which can be very frustrating. There’s also the question of what 
iam.GetRole
actually does in Go, and why it’s causing the panic you’re seeing (or at least, that’s the hunch on the panic cause).
t
Thanks for all your input / advice @bored-table-20691 👍 After going back / forth a bit, I found that the ts eks lib is a bit behind in api support for managed nodegroups. I am now trialing a Go version of our IaC with stack-created iam roles, and so far it's working well!
4 Views
Open in Slack
PreviousNext
Powered by