https://pulumi.com logo
Powered by
q

quiet-magazine-16687

03/30/2019, 8:56 AM
@creamy-potato-29402 ^^
c

creamy-potato-29402

04/01/2019, 7:28 AM
@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

quiet-magazine-16687

04/01/2019, 9:57 AM
@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
Powered by