-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
generate_name prefix seems to not be honored #2539
Comments
Hello @jforest, Thank you for raising this issue. In Kubernetes, the However, in Pulumi, when resources don't explicitly contain a name field, they are auto-named by default. This Pulumi behavior is causing the To resolve this issue, we will need to implement a check to ensure that auto-naming doesn't occur when the |
I have also run into this. I am going to work around it by generating our own names but I would appreciate if a fix could be prioritised. This should operate in the same way as |
I would add another reason for prioritizing this: If you have several levels of nested component resources, then the names pulumi generates can become so long they are rejected by the apiserver. |
This comment was marked as outdated.
This comment was marked as outdated.
<!--Thanks for your contribution. See [CONTRIBUTING](CONTRIBUTING.md) for Pulumi's contribution guidelines. Help us merge your changes more quickly by adding more details such as labels, milestones, and reviewers.--> ### Proposed changes <!--Give us a brief description of what you've done and what it solves. --> This PR changes the provider's await logic to get the object name from the output properties rather than the input properties, since the inputs may or may not contain an object name, to prepare to support `generateName` field (see #2539). Note that auto-naming populates the inputs, whereas generateName doesn't. The awaiters continue to look to the inputs (not the live object) for the `skipAwait` and `timeout` annotations. ### Related issues (optional) <!--Refer to related PRs or issues: #1234, or 'Fixes #1234' or 'Closes #1234'. Or link to full URLs to issues or pull requests in other GitHub repositories. --> Related: #2539
<!--Thanks for your contribution. See [CONTRIBUTING](CONTRIBUTING.md) for Pulumi's contribution guidelines. Help us merge your changes more quickly by adding more details such as labels, milestones, and reviewers.--> ### Proposed changes <!--Give us a brief description of what you've done and what it solves. --> This PR implements support for `.metadata.generateName` in CSA mode, based on #2790. 1. Adjust the auto-naming logic to consider `.metadata.generateName` to be a variant of auto-naming. Pulumi will not assign an auto-name to a new resource that has `generateName`, and upon delete will use the replace-then-delete technique. 2. Use outputs rather than inputs to fetch the live object or to obtain the live object's name. 3. Fix an autonaming bug where the old auto-name would erroneously be adopted, overwriting a new computed name. ### Tests 1. A new integration test is provided to test the use of `metadata.generateName`. It tests creation, update, replacement, and promotion from `.generateName` to `.name`. ([ref](https://github.com/pulumi/pulumi-kubernetes/pull/2808/files#diff-7e85ce707283b1d281d971a8e5b0c49b959b0803ba3437dc9dbd422552326835R269)) 2. New test cases for the await logic. 3. The existing autonaming test is enhanced to test how autonaming takes precedence over `generateName`, in the update case. This is to ensure backwards compatibility, e.g. in the edge case that an existing object has a `generateName` field (which Pulumi ignored until now). ### Related issues (optional) Closes #2539
I see this has been closed but I can't seem to find any record of why this was only fixed for CSA and not SSA (and disallows the field in YAML rendering mode). Is there a reason or will be this be supported later? |
What happened?
I have both a
pv
andpvc
being created, I specify thepulumi_kubernetes.meta.v1.ObjectMetaArgs
generate_name
attribute on each which should specify a prefix for the name. But the name that results is not using my specified prefix, it appears to be using theresource_name
of the object as the prefix instead.Expected Behavior
For example, my code for generating a
pvc
from thepv
I created beforeI would expect the name of the
pvc
to beworkbench-pvc-<randomstring>
but instead I get<cluster_name>-workbench-pvc-<randomstring>
our cluster name is
internal-eks01
in this caseSteps to reproduce
Create a
pvc
from apv
using the code belowit will not use the
generate_name
prefix, it instead uses theresource_name
as a prefixOutput of
pulumi about
Additional context
versions of pulumi libraries:
I would like to upgrade
pulumi-kubernetes
to 4.1.0, butpulumi-kubernetes-cert-manager
will not allow versions greater than 3.x. pulumi/pulumi-kubernetes-cert-manager#21 and pulumi/pulumi-kubernetes-cert-manager#22Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).
The text was updated successfully, but these errors were encountered: