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

Plugin watcher getting notified of every Kubelet directory event #69015

Closed
vladimirvivien opened this issue Sep 25, 2018 · 30 comments · Fixed by #70494
Closed

Plugin watcher getting notified of every Kubelet directory event #69015

vladimirvivien opened this issue Sep 25, 2018 · 30 comments · Fixed by #70494
Labels
kind/bug Categorizes issue or PR as related to a bug. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. sig/node Categorizes an issue or PR as relevant to SIG Node.
Milestone

Comments

@vladimirvivien
Copy link
Member

Is this a BUG REPORT or FEATURE REQUEST?:

/kind bug
This is more of an enhancement.

What happened:
The Plugin Watcher is setup to trigger on file activities when they occur in the subdirectory that it scans. During startup, the Watcher is passed (from within the Kubelet) the Kubelet's root plugin directory as a location to scan for newly added plugins -

klet.pluginWatcher = pluginwatcher.NewWatcher(klet.getPluginsDir())

Because the kubelet's plugins subdirectory is also used by existing in-tree drivers (including csi) as a location to store plugins artifacts, the Plugin Watcher is getting triggered by directory/file activities occurring in that subdirectory that has nothing to do with plugin registration as shown in the output below:

> cat kubelog.txt | grep "plugin_watcher"
E0921 18:41:49.164687   81286 plugin_watcher.go:115] error dial failed at socket /var/lib/kubelet/plugins/csi-hostpath/csi.sock, err: failed to dial socket /var/lib/kubelet/plugins/csi-hostpath/csi.sock, err: context deadline exceeded when handling create event: "/var/lib/kubelet/plugins/csi-hostpath/csi.sock": CREATE
E0921 18:42:12.126656   81286 plugin_watcher.go:120] error could not find plugin for deleted file /var/lib/kubelet/plugins/csi-hostpath/csi.sock when handling delete event: "/var/lib/kubelet/plugins/csi-hostpath/csi.sock": REMOVE
E0921 18:42:12.127706   81286 plugin_watcher.go:115] error failed to get plugin info using RPC GetInfo at socket /var/lib/kubelet/plugins/csi-hostpath/csi.sock, err: rpc error: code = Unimplemented desc = unknown service pluginregistration.Registration when handling create event: "/var/lib/kubelet/plugins/csi-hostpath/csi.sock": CREATE
E0921 18:42:20.988913   81286 plugin_watcher.go:115] error error accessing path: /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8 error: lstat /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8: no such file or directory when handling create event: "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8": CREATE
E0921 18:42:20.989211   81286 plugin_watcher.go:120] error could not find plugin for deleted file /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8 when handling delete event: "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8": REMOVE
E0921 18:42:21.495810   81286 plugin_watcher.go:115] error failed to watch /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8, err: no such file or directory when handling create event: "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8": CREATE
E0921 18:42:21.495960   81286 plugin_watcher.go:120] error could not find plugin for deleted file /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8 when handling delete event: "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8": REMOVE
E0921 18:42:22.512498   81286 plugin_watcher.go:115] error failed to watch /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8, err: no such file or directory when handling create event: "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8": CREATE
E0921 18:42:22.512767   81286 plugin_watcher.go:120] error could not find plugin for deleted file /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8 when handling delete event: "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8": REMOVE
E0921 18:42:24.539679   81286 plugin_watcher.go:120] error could not find plugin for deleted file /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8/globalmount when handling delete event: "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8/globalmount": REMOVE
E0921 18:42:24.539725   81286 plugin_watcher.go:120] error could not find plugin for deleted file /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8 when handling delete event: "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8": REMOVE
E0921 18:42:24.539743   81286 plugin_watcher.go:120] error could not find plugin for deleted file /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8/vol_data.json when handling delete event: "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8/vol_data.json": REMOVE
E0921 18:42:24.539780   81286 plugin_watcher.go:120] error could not find plugin for deleted file /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8 when handling delete event: "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8": REMOVE
E0921 18:42:24.539612   81286 plugin_watcher.go:120] error could not find plugin for deleted file /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8/globalmount when handling delete event: "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8/globalmount": REMOVE
E0921 18:42:28.592695   81286 plugin_watcher.go:120] error could not find plugin for deleted file /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8/globalmount when handling delete event: "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8/globalmount": REMOVE
E0921 18:42:28.592728   81286 plugin_watcher.go:120] error could not find plugin for deleted file /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8/globalmount when handling delete event: "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8/globalmount": REMOVE
E0921 18:42:28.592752   81286 plugin_watcher.go:120] error could not find plugin for deleted file /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8 when handling delete event: "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8": REMOVE
E0921 18:42:28.592767   81286 plugin_watcher.go:120] error could not find plugin for deleted file /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8/vol_data.json when handling delete event: "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8/vol_data.json": REMOVE
E0921 18:42:28.592967   81286 plugin_watcher.go:120] error could not find plugin for deleted file /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8 when handling delete event: "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8": REMOVE
E0921 18:42:36.611609   81286 plugin_watcher.go:120] error could not find plugin for deleted file /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8/vol_data.json when handling delete event: "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8/vol_data.json": REMOVE
E0921 18:42:36.611485   81286 plugin_watcher.go:115] error error accessing path: /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8/globalmount error: lstat /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8/globalmount: no such file or directory when handling create event: "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8": CREATE
E0921 18:42:36.611575   81286 plugin_watcher.go:120] error could not find plugin for deleted file /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8 when handling delete event: "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8": REMOVE
E0921 18:42:36.611699   81286 plugin_watcher.go:120] error could not find plugin for deleted file /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8 when handling delete event: "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8": REMOVE
E0921 18:42:52.623501   81286 plugin_watcher.go:120] error could not find plugin for deleted file /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8 when handling delete event: "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8": REMOVE
E0921 18:42:52.623535   81286 plugin_watcher.go:115] error stat file /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8 failed: stat /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8: no such file or directory when handling create event: "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8": CREATE
E0921 18:43:24.698730   81286 plugin_watcher.go:120] error could not find plugin for deleted file /var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8 when handling delete event: "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8ff803a4bdef11e8": REMOVE

What you expected to happen:
The Plugin Watcher should not be getting triggered by file/directory activities not related to plugin registration/unregistration. One possibility is to have the Watcher scan one directory below plugins like /var/lib/kubelet/plugins/registration or something similar

How to reproduce it (as minimally and precisely as possible):
Run plugin watcher with a CSI driver.

cc @RenaudWasTaken @vikaschoudhary16

@k8s-ci-robot k8s-ci-robot added kind/bug Categorizes issue or PR as related to a bug. needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Sep 25, 2018
@vladimirvivien
Copy link
Member Author

/sig node

@k8s-ci-robot k8s-ci-robot added sig/node Categorizes an issue or PR as relevant to SIG Node. and removed needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Sep 25, 2018
@tossmilestone
Copy link
Member

@vladimirvivien I think you should only place the plugin socket file in the plugin registration directory but not the plugin data.

@tianshapjq
Copy link
Contributor

agree with @tossmilestone, we can only place the registration file in the specified path instead of placing all data into it. On the other hand, you can place data into the /var/lib/kubelet/plugins/registration even if registration created, that's a no-end loop.

@vladimirvivien
Copy link
Member Author

@tossmilestone
As I mentioned in issue, existing in-tree volume plugins were already using that directory as a location to store storage operation artifacts (not just csi). Here is a shortened list of driver locations that use /var/lib/kubelet/plugins in their code already:

And several more locations.

The fix would be to have plugin watcher scan a subdirectory of plugins (say /var/lib/kubelet/plugins/registration) instead of plugins directly as it is doing today.

The watcher functions as intended. Except now it picks up all directory activities whether related or not to plugin registration.

@RenaudWasTaken
Copy link
Contributor

RenaudWasTaken commented Sep 25, 2018

Well given the fact that the pluginwatcher is beta this is a bit of an issue. My understanding of the "beta" guarantees is that we want to be backwards compatible for all plugins published with the beta API.

Meaning that even if we move the registration directory to a new location, we'll need to keep scanning the old directory (to pick up v1beta plugins).

From a 10 000 feet point of view it seems easier to me if we move the in-tree volume plugin's data. Though it might be a lot of work.

Another less painful option, but a bit grey is the following: Enforce plugins to end with .sock this suffix is recommended for device plugins (though not enforced) and I believe is a convention on linux.
This is a bit grey because we would still be breaking v1beta users but since we're moving a convention from "recommended" to "enforced" it seems "less" breaking to me (and I haven't seen device plugins not using that extension).

What do you think @vladimirvivien ?

@vladimirvivien
Copy link
Member Author

@RenaudWasTaken I like the .sock suffix idea. It can be a recommendation (which csi is already doing).

@cpressland
Copy link

Hmm, I've just deployed a new k8s cluster on 1.12.0 and noticed this repeating in the logs on a few of our pods. Just for my own sanity, is this something I should be worried about or can I ignore it until a fix is released?

Oct 09 06:37:46 westeurope-worker-09 kubelet[19149]: E1009 06:37:46.003633   19149 plugin_watcher.go:115] error dial failed at socket /var/lib/kubelet/plugins/kubernetes.io/azure-disk/mounts/m856950613/diagnostic.data/metrics.interim.temp, err: failed to dial socket /var/lib/kubelet/plugins/kubernetes.io/azure-disk/mounts/m856950613/diagnostic.data/metrics.interim.temp, err: context deadline exceeded when handling create event: "/var/lib/kubelet/plugins/kubernetes.io/azure-disk/mounts/m856950613/diagnostic.data/metrics.interim.temp": CREATE
Oct 09 06:37:46 westeurope-worker-09 kubelet[19149]: E1009 06:37:46.003717   19149 plugin_watcher.go:115] error dial failed at socket /var/lib/kubelet/plugins/kubernetes.io/azure-disk/mounts/m856950613/diagnostic.data/metrics.interim, err: failed to dial socket /var/lib/kubelet/plugins/kubernetes.io/azure-disk/mounts/m856950613/diagnostic.data/metrics.interim, err: context deadline exceeded when handling create event: "/var/lib/kubelet/plugins/kubernetes.io/azure-disk/mounts/m856950613/diagnostic.data/metrics.interim": CREATE

@RenaudWasTaken
Copy link
Contributor

@cpressland you can ignore these errors.
@vladimirvivien if it's a recommendation then we'll keep spamming the logs with all the data files.

Another thing to keep in mind, it seems like CSI plugins puts a lot of data (and creates a lot of directories). It might be worth considering limiting the recursion to one level.

I'm concerned we might exhaust the amount of fds by tracking the plugins data.

@vladimirvivien
Copy link
Member Author

@RenaudWasTaken yeah CSI keeps track of volume operation metadata in the plugins dir. This probably will not change.

I understand this is beta. However, besides CSI and Device plugin, are there any other implementers out there for this feature ? Would it be possible to propose a new location (i.e. /reg/?

@vladimirvivien
Copy link
Member Author

@RenaudWasTaken let me know if you open a PR for this as discussed.

@figo
Copy link
Contributor

figo commented Oct 31, 2018

@vladimirvivien thanks for open the issue with detail logs, i can see two problems by looking at logs and code.

  1. plugin watcher trying to dial non-socket files.
  2. too many logs generated (CREATE and DELETE).

I added a suggestion to @RenaudWasTaken fix of this issue #70494
we can fix those problems by:

  1. check file mode when handle CREATE event, only attempt to dial file when file mode is socket.
  2. increase log verbose level for both 'handleDeleteEvent()' and 'handleCreateEvent()'

plugin watcher still has activity when any file create/delete under the directory, but they become light weighted (CREATE file will only trigger file mode check, DELETE file event will trigger plugin searching)

i am not sure we want to go further to limit directory depth where plugin can live.
it has two drawbacks IMO:

  1. it is hard to enforce, not sure everyone will read code/readme.
  2. it provides less flexibility to plugins: if want to organize many plugin socket files with directory.

@RenaudWasTaken
Copy link
Contributor

  1. check file mode when handle CREATE event, only attempt to dial file when file mode is socket.
  2. increase log verbose level for both 'handleDeleteEvent()' and 'handleCreateEvent()'

These are definitely good suggestions!

i am not sure we want to go further to limit directory depth where plugin can live.
it has two drawbacks IMO:

it is hard to enforce, not sure everyone will read code/readme.
it provides less flexibility to plugins: if want to organize many plugin socket files with directory.

It seems like there might be some confusion as to why we are thinking of doing this:

  • Most plugins use the plugin directory to store data (actually a lot of files / dirs)
  • Watching all the directories and files created inside the plugin directory puts more burden on the Kubelet in terms of cpu / memory consumption
  • Watching all the directories and files created inside the plugin directory quickly raises the number of fd consumed

By limiting the search of the plugins to one directory, we would be severely limiting the ability of the module to unintentionally harm the overall Kubelet.

It seems actually pretty easy to enforce, as it's a simple if condition. As for not everyone reading code / readme, we can add the documentation to the gRPC interface if this is a concern.

In terms of flexibility, is there a real need to create a plugin in a lower directory? Is there a plugin that has so many sockets that a single directory underneath the plugin directory isn't enough?

Naively it seems to me that $PLUGIN_DIR/vendor_name.io/socket_name-version.sock is enough for the different plugins we enable.

@RenaudWasTaken
Copy link
Contributor

ping @figo on the above :)

@figo
Copy link
Contributor

figo commented Nov 5, 2018

In terms of flexibility, is there a real need to create a plugin in a lower directory? Is there a plugin
that > has so many sockets that a single directory underneath the plugin directory isn't enough?
Naively it seems to me that $PLUGIN_DIR/vendor_name.io/socket_name-version.sock is enough for > the different plugins we enable.

@RenaudWasTaken i can not speak from plugin developer, but both below looks reasonable to me $PLUGIN_DIR/vendor_name.io/plugin_type/socket_name-version.sock, or $PLUGIN_DIR/venderName_pluginType_socketName-version.sock
as long as we can communicate to plugin developers clearly and effectively (gRPC interface documentation is needed), the directory depth restriction is reasonable to me.

@vladimirvivien
Copy link
Member Author

@figo @RenaudWasTaken I like $PLUGIN_DIR/vendor_name.io/plugin_type/socket_name-version.sock. However, why not put plugin_type one level up as $PLUGIN_DIR/plugin_type/vendor/socket_name-version.sock. For instance $PLUGIN_DIR/csi/kubernetes/hostpath.sock

@saad-ali
Copy link
Member

saad-ali commented Nov 8, 2018

Is the suggestion to hard code the number of levels that the recursion algorithm will search to 3? Or just expect a socket only at a hard coded level (e.g. socket must be nested 3 deep)?

Copying my comment from #70810 (comment) for consistency:

Ideally the directory that the plugin sockets are dropped in should be different from the directory where mounts happens.

Currently the plugin socket directory is: /var/lib/kubelet/plugins/)
The mounts directory is /var/lib/kubelet/pods/[poduid]/volumes/... (so far so good).
Problem is the "global mount" directory is also /var/lib/kubelet/plugins/... :(

So options are:

  1. Drop recursively scanning like @msau42 suggested, and say plugins will can only be directly under /var/lib/kubelet/plugins/
    • This will break existing plugins, for example, the GCP plugin is at /var/lib/kubelet/plugins/com.google.csi.gcepd/csi.sock (see link).
  2. Keep recursively scanning but change the plugin socket directory to /var/lib/kubelet/plugins/sockets/?
    • This will also break existing plugins, like the GCP one pointed out above.
  3. Leave the plugin dir the same, and leave recursion in, but put a limit on depth of plugin directory as suggested by @figo.
    • This is ugly but may be the cleanest solution.

Another option I can think of:

  1. Keep recursively scanning but before scanning a directory check if it is mounted (mounter.IsLikelyNotMountPoint(...)). This will be backwards compatible and will prevent scanning of volume data

Thoughts?

@figo
Copy link
Contributor

figo commented Nov 8, 2018

Another option I can think of:

  1. Keep recursively scanning but before scanning a directory check if it is mounted (mounter.IsLikelyNotMountPoint(...)). This will be backwards compatible and will prevent scanning of volume data

Thoughts?

i like this idea better if it is always the case that: volume data is mounted, we can modify the watcher code to not watch the mounted directory in the first place.

@vladimirvivien
Copy link
Member Author

Skipping mounted dir along with restructuring search path to known (shallow) dir sounds like a good plan. Though with the new suggested paths, sockets will be placed at a location where mounts should not exist.

@saad-ali
Copy link
Member

saad-ali commented Nov 8, 2018

i like this idea better if it is always the case that: volume data is mounted, we can modify the watcher code to not watch the mounted directory in the first place.

I think that would be a safe assumption. The plugin directory is only used as a target path for global mounts.

@msau42
Copy link
Member

msau42 commented Nov 8, 2018

Ephemeral volume types may not need to mount, it could just be a symlink or plain directory. Can we assume any ephemeral volume CSI driver won't implement global mount?

@saad-ali
Copy link
Member

saad-ali commented Nov 8, 2018

Ephemeral volume types may not need to mount, it could just be a symlink or plain directory. Can we assume any ephemeral volume CSI driver won't implement global mount?

Yes, in-tree ephemeral volumes today don't do a global mount so the mounts directory is /var/lib/kubelet/pods/[poduid]/volumes/... which is not the plugin dir. So no issue there.

For CSI the NodeStageVolume staging_target_path will be the global mount path (this plugin dir).
Emphermal volumes shouldn't implement NodeStageVolume call -- but nothing prevents them from doing so.

Maybe let's start with just checking for mount and ignoring mount directories. If it is still an issue we can consider adding a configurable black list of paths. Thoughts?

@vladimirvivien
Copy link
Member Author

That sounds good. Also, putting the socket files in a specific location that does not clash with mounts will also help (i.e. $PLUGIN_DIR/csi/kubernetes/hostpath.sock)

@AishSundar
Copy link
Contributor

/milestone v1.13
/priority important-soon

@k8s-ci-robot k8s-ci-robot added the priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. label Nov 9, 2018
@k8s-ci-robot k8s-ci-robot added this to the v1.13 milestone Nov 9, 2018
@RenaudWasTaken
Copy link
Contributor

I just want to point out that one of the issue we have with recursively watching all directories is that it will significantly increase the amount of fd consumed.

Given that plugins actually store data there and in a dynamic way my fear is that it will exhaust the available fds for no real good reasons.

Limiting the depth sounds like a reasonable solution to that issue.

@gree-gorey
Copy link

btw, because of this verbosity kubelet in my cluster writes 5G logs every day and filled up my rootfs (which is small). Is there any way to decrease this verbosity?

@saad-ali
Copy link
Member

Given that plugins actually store data there and in a dynamic way my fear is that it will exhaust the available fds for no real good reasons.

Limiting the depth sounds like a reasonable solution to that issue.

We can do both. Don't search mounted dirs, and max depth of search. Who is working on this?

@saad-ali
Copy link
Member

@gree-gorey That's pretty bad, can you open another issue to track that.

@RenaudWasTaken
Copy link
Contributor

RenaudWasTaken commented Nov 14, 2018

@saad-ali we have a PR in flight discussing this issue (recursive scanning) here: #70494

Thinking more about this, the fact that too much logs is generated is clearly linked to this specific issue and how we process plugins.

In any case I'll be fixing that issues too

@AishSundar
Copy link
Contributor

@RenaudWasTaken how confident are we in getting this fixed by Code freeze tomorrow? 5pm PST

@RenaudWasTaken
Copy link
Contributor

I expect things to wind up today, changes in the above PR aren't very contentious and don't involve significant changes

hectorhuertas added a commit to utilitywarehouse/tf_kube_ignition that referenced this issue Dec 19, 2018
hectorhuertas added a commit to utilitywarehouse/tf_kube_ignition that referenced this issue Dec 19, 2018
Temporal workaround for kubernetes/kubernetes#69015

(cherry picked from commit 6d32980)
hectorhuertas added a commit to utilitywarehouse/tf_kube_ignition that referenced this issue Dec 19, 2018
hectorhuertas added a commit to utilitywarehouse/tf_kube_ignition that referenced this issue Dec 19, 2018
Temporal workaround for kubernetes/kubernetes#69015

(cherry picked from commit b6d1341)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. sig/node Categorizes an issue or PR as relevant to SIG Node.
Projects
None yet
Development

Successfully merging a pull request may close this issue.