https://pulumi.com
Join Slack
This message was deleted.
# general
s
This message was deleted.
c
@quiet-magazine-16687 I think we’d have to have a very good reason to allow “skipping” resources that exist. It’s contrary to our model is so many ways, it’s hard even to see how it might work…
Like: when a chart or application asks you to create a specific version of a resource, and your resource version differ, what should we do? What happens if someone deletes that CRD out from under you? What happens if they delete it and you run 
pulumi up
? And so on.
Besides all that, when this does happen it’s virtually certain to be a bug in the chart or app. I very seriously doubt that what you really want is for pulumi to choose arbitrarily between the two versions of a resource when there’s a conflict. 🙂
q
@creamy-potato-29402 thanks for the thoughts
i see your point on skipping but thinking if we an do a 
apply
. the create causes the issue here while if we do apply kubectl will naturally does not do anything as there is no change
e.g.
both these yamls has a CRD called like
Copy code
apiVersion: <http://apiextensions.k8s.io/v1beta1|apiextensions.k8s.io/v1beta1>
kind: CustomResourceDefinition
metadata:
  name: images.caching.internal.knative.dev
spec:
  group: caching.internal.knative.dev
  names:
    categories:
    - all
    - knative-internal
    - caching
    kind: Image
    plural: images
    shortNames:
    - img
    singular: image
  scope: Namespaced
  subresources:
    status: {}
  version: v1alpha1
since these two can be installed individually they tend to have same CRDS
but when deploying together it fails with duplicate error
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by