Hi - I'm migrating Pulumi EKS from v2 to v3 (cross...
# aws
s
Hi - I'm migrating Pulumi EKS from v2 to v3 (crosswalk) However I have issues with the extraNodeSecurityGroups did anyone see this issue before as I cannot find answer elsewhere online. the error message is misleading as I triple checked the existence of the security group
q
Hey @stale-tomato-37875, is the
securityGroup
a resource you're creating in the same stack or are you looking it up using
.get
? This sounds a lot like this bug https://github.com/pulumi/pulumi/issues/17515 which involves using
.get
in components.
s
Hi Florian! Thanks for looking into this. I used .get in this case
q
Got it! In that case it is caused by the bug I linked above. The good news is that a fix has been merged already, we're just waiting for the next release of pulumi. It should go out late this week or early next week. I'll keep you posted!
I'm gonna check if there's a workaround for you in the meantime
s
that's great to hear. beside, I also tested with a same stack resource something like below
Copy code
const test_sg = new aws.ec2.SecurityGroup("test_sg", {
  name: "allow_tls",
  description: "Allow TLS inbound traffic and all outbound traffic",
});
And I get below issues
Copy code
aws:iam:InstanceProfile (brainfish-au-instanceProfile):
    error: Expected an ID for urn:pulumi:au::brainfish-universe-eks::eks:index:Cluster$aws:iam/instanceProfile:InstanceProfile::brainfish-au-instanceProfile

  pulumi:pulumi:Stack (brainfish-universe-eks-au):
    error: eks:index:Cluster resource 'brainfish-au' has a problem: grpc: the client connection is closing
is this expected?
q
One potential workaround for the initial problem would be omitting the
extraNodeSecurityGroups
and using the
transforms
resource option to inject the security ID. For more details see https://www.pulumi.com/docs/iac/concepts/options/transforms/
The other issue is definitely not expected! I'd appreciate if you could cut an issue here and add a minimal repro that shows the problem so we can dig into it
s
sure, I'll raise an issue there if I couldn't resolve this tomorrow. but I'm pretty confused why the security group modification would involve InstanceProfile; besides does the gprc client connection closing signal anything other than a failed request, I'm confused if it's auth related stuff 🧐
q
The instance profile is created by the provider for the node groups. The security group modifications shouldn't affect this, given that you're migrating between major versions there might be other issues. What version of the provider where you using before migrating to v3? The messages related to the grpc connection are normal when the component provider hits an unrecoverable error, but I agree that it's confusing and potentially even distracts from the original error. I'll have a chat with the team to see if there's something we can do about this. Appreciate the feedback!
s
I upgrade pulumi eks from 2.2.1 to 3.6.0 directly by an npm install command 😂
btw what's the suggested way to migrate from v2 to v3? any specific path?
q
s
Hi Florian, I saw a new release v3.7.0 and it didn't solve my issue. Is the change you mentioned above included in this release?
q
No, this will be part of the next pulumi/pulumi, not the EKS provider
A new version of Pulumi has been released, can you try updating your CLI and pulumi dependency in your project to see if that fixes the issue for you? https://github.com/pulumi/pulumi/releases/tag/v3.145.0
s
Hi Florian, thanks for the reminder! I can confirm the
.get
issue has gone. However I still have a problem with upgrading the pulumi/eks from v2 to v3 The instanceProfile issue stays
Copy code
Diagnostics:
  aws:iam:InstanceProfile (brainfish-au-instanceProfile):
    error: Expected an ID for urn:pulumi:au::brainfish-universe-eks::eks:index:Cluster$aws:iam/instanceProfile:InstanceProfile::brainfish-au-instanceProfile

  pulumi:pulumi:Stack (brainfish-universe-eks-au):
    error: eks:index:Cluster resource 'brainfish-au' has a problem: grpc: the client connection is closing
Copy code
const securityGroup = aws.ec2.SecurityGroup.get(
  "default",
  defaultSecurityGroupId
);

const cluster = new eks.Cluster(`${ORG}-${stack}`, {
  vpcId: defaultVpcId,
  subnetIds: defaultVpcSubnetsIds,
  authenticationMode: "API",
  nodeGroupOptions: {
    minSize: config.EKS_MIN_WORKER_NODE_NUMBER,
    maxSize: config.EKS_MAX_WORKER_NODE_NUMBER,
    desiredCapacity: config.EKS_DESIRED_WORKER_NODE_NUMBER,
    nodeRootVolumeEncrypted: true,
    // amiId: config.EKS_NODE_AMI_ID, // pin Amazon EKS-optimized Amazon Linux 2 AMI to avoid accidental nodes destruction
    nodeRootVolumeSize: 100, // 100GB, reasonable default
    extraNodeSecurityGroups: [securityGroup], // remove this will resolve the issue
    instanceType: config.EKS_NODE_INSTANCE_TYPE,
    nodeRootVolumeType: config.EKS_NODE_ROOT_VOLUME_TYPE as
      | "standard"
      | "gp2"
      | "gp3"
      | "st1"
      | "sc1"
      | "io1",
  }
});
This is the key code snippet I believe by removing the look up for the extra security group, the issue will be resolved.
I still feel there is something wrong with the
@pulumi/pulumi
around aws.ec2.securitygroup https://github.com/search?q=repo%3Apulumi%2Fpulumi+%22Expected+an+ID+for%22&type=code I can only find the error was from step_generator
q
Do you by any chance have multiple copies of
@pulumi/pulumi
in your node modules? Nevertheless we should transfer this to a GitHub issue so our team can dig into it, do you mind opening an issue here and adding your repro to it, thanks!
s
Hi @quick-house-41860 I've raised the issue here and found the root cause! Lucky me haha not sure if it's an intentional breaking change tho
q
Thanks you so much for chasing this down! It's definitely not intentional! At a first glance
pulumi.all([args.extraNodeSecurityGroups]).apply(([sg]) => { ... })
and
pulumi.output(args.extraNodeSecurityGroups)
should behave the same way, but there might be some subtleties causing this issue. I'll start looking into this right away.