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.

Pulumi Community

<@UHG09TH9S> 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. :slightly_smiling_face:

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

<https://github.com/knative/serving/releases/download/v0.4.0/serving.yaml>

<https://github.com/knative/build/releases/download/v0.4.0/build.yaml>

```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