Skip to content
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

Fixes in how the provider handles CRDs and CRs #271

Merged
merged 3 commits into from
Nov 14, 2018
Merged

Commits on Nov 14, 2018

  1. Allow CRDs and CRs to be created in the same Pulumi app

    Currently, if a CRD is created after the CRs that depend on it, the CRs
    will fail. The main reason for this is that our caching discovery client
    does not refresh after a CRD is created, so when asked about a G/V/K, it
    will fail because it thinks the server does not know about it.
    
    To fix this, this commit will cause us to mark the cache as invalid
    any time a CRD is created. This means that the CR, when a create
    operation is retried, will update its view of the server before
    creation.
    hausdorff committed Nov 14, 2018
    Configuration menu
    Copy the full SHA
    c4b217e View commit details
    Browse the repository at this point in the history
  2. Consider NotFound CRs to be deleted

    Currently, if a CRD is deleted before we have a chance to delete
    dependent CRs, we could fail because the the G/V/K is no longer
    registered with the API server.
    
    This commit corrects this by considering `NotFound` to be equivalent to
    a successful delete. The rationale behind this is that we must have
    previously successfully created the resource; hence, if the G/V/K is
    missing, it was successfully deleted.
    
    Importantly, if the user accidentally switches active contexts, a
    `pulumi up -r` will register all of these as deletes. We will be working
    on this scenario in the future.
    hausdorff committed Nov 14, 2018
    Configuration menu
    Copy the full SHA
    e67e99b View commit details
    Browse the repository at this point in the history
  3. Default to foreground deletion only in Kubernetes 1.6

    Background deletion was broken for much of Kubernetes 1.6, and our code
    accordingly manually sets deletion to "foreground" after 1.6. This
    causes pain when deleting CRDs with finalizers, which will hang until
    the GC has a chance to delete them and all their dependencies, which is
    quite likely to be a time longer than our timeout period.
    
    This assumption is outdated for newer verions of Kubernetes, so this
    commit will default to whatever the user has set for all versions > 1.7.
    hausdorff committed Nov 14, 2018
    Configuration menu
    Copy the full SHA
    8bebb90 View commit details
    Browse the repository at this point in the history