I’m seeing an issue with the new k8s auto aliasing...
# general
I’m seeing an issue with the new k8s auto aliasing. I have a resource of type
being created, it’s getting the following aliases that seem to be coming from a different resource altogether:
Copy code
"aliases": [
resulting in an error like this:
Copy code
panic: fatal: An assertion has failed: Two resources ('urn:pulumi:mirror::mirror::kubernetes:apps/v1:Deployment::traffic-mirror' and 'urn:pulumi:mirror::mirror::kubernetes:autoscaling/v2beta2:HorizontalPodAutoscaler::traffic-mirror') aliased to the same: 'urn:pulumi:mirror::mirror::kubernetes:apps/v1:Deployment::traffic-mirror'
@millions-judge-24978 working on this now
👍 1
@millions-judge-24978 I don’t think I understand this, actually
where are those aliases coming from?
Me either honestly haha. This happens with the new pulumi kubernetes 1.2
I mean, what code did you write that causes this
in the code for HPA, it is clear that those aliases aren’t in the alias list
so they must be coming from outside. your code? somewhere else?
I just boarded a plane unfortunately. I am not using the alias functionality at all in my code. It seems to be a bug in the new auto API version aliasing
The resource it happens on is just chance based on whatever is last or something
are you using python or TS
Not necessarily the HPA if I get rid of something else. TS
I don’t see where we could be introducing those aliases. no code you can share until you land, I guess?
I probably can share in a bit on the flight. Flying to Japan lol
ok, sounds good
if I can reproduce the issue I can fix it really quick
It's basically just a mixed bag of k8s resources though.
yeah, I just mean, if I have the code I can run it and sett the problem, which usually means i can debug in ~15 minute
Yeah ofc, will share when I can, thanks!
I can’t tell for sure what the problem is from the info you provided, but my best guess would be that you have two
Deployments in the stack that have different apiVersions. This change effectively means that the apiVersion isn’t part of the URN anymore, so it would cause a conflict in that case.
Sorry travel got a bit crazy, this is the code: https://gist.github.com/timmyers/7ffbb5856c8337725bff43626e2f0ab2
There’s only one deployment