Karpenter: instance node role output always changes

[Feder1co5oave]

Describe the bug

Every time I change anything in my CDK project, the outputs (Node Role name and Instance Profile name) of Karpenter addon change name, because of the change introduced in #595.

cdk-eks-blueprints/lib/addons/karpenter/index.ts

Lines 400 to 413 in 263da03

	const clusterHash = md5.Md5.hashStr(clusterName);
	//Cfn output for Node Role in case of needing to add additional policies
	new CfnOutput(cluster.stack, 'Karpenter Instance Node Role', {
	value: karpenterNodeRole.roleName,
	description: "Karpenter add-on Node Role name",
	exportName: "KarpenterNodeRoleName"+clusterHash,
	});
	//Cfn output for Instance Profile for creating additional provisioners
	new CfnOutput(cluster.stack, 'Karpenter Instance Profile name', {
	value: karpenterInstanceProfile ? karpenterInstanceProfile.instanceProfileName! : "none",
	description: "Karpenter add-on Instance Profile name",
	exportName: "KarpenterInstanceProfileName"+clusterHash,
	});

The clusterHash is computed on the clusterName, which is a token that gets resolved only later. So, for example ${Token[TOKEN.907]} gets hashed instead, and the token placeholders change often non-deterministically.

May I suggest using Names.uniqueId(cluster) for all outputs instead?
This returns a unique name from the cluster's node path, such as eksblueprint85A195CC.

Expected Behavior

Output names should be more stable.

Current Behavior

Deploy a blueprint with Karpenter addon, then change anything in the stack and run cdk diff.
It always returns

[~] Output Karpenter Instance Node Role KarpenterInstanceNodeRole: {
  "Description":"Karpenter add-on Node Role name",
  "Value":{"Ref":"ekskarpenternoderole8897C336"},
  "Export":{"Name":"KarpenterNodeRoleName0aa68ce495587319d019d932d9f0f6ec"}
} to {
  "Description":"Karpenter add-on Node Role name",
  "Value":{"Ref":"ekskarpenternoderole8897C336"},
  "Export":{"Name":"KarpenterNodeRoleName0c2627510746e95b144ce7be3b090ff1"}
}

Reproduction Steps

Possible Solution

No response

Additional Information/Context

No response

CDK CLI Version

2.66.1

EKS Blueprints Version

No response

Node.js Version

v16.19.1

Environment details (OS name and version, etc.)

Other information

No response

[youngjeong46]

@Feder1co5oave Thanks for submitting the issue. I'll test the uniqueId and implement it in the latest PR.

[rverma-dev]

Yes, this is a big issue, in fact because of this the snapshot tests will not work

[youngjeong46]

@Feder1co5oave We pushed the PR into 1.6.1 release. Can you test and verify?

[Feder1co5oave]

@youngjeong46 I believe I've already tested this a couple of days ago when I upgraded to 1.6.1. Unfortunately because of #644 I decided to rollback until a fix is released so I can't double-check this right now.
Nonetheless, I trust that the fix works as intended, so we can close this.

[youngjeong46]

Closing as issue is addressed.