Support more resource types

[KnVerey]

We only selected a few that our own apps commonly use for the initial rollout. Currently unrecognized types will be kubectl applied and a warning will be logged about the fact that the script does not know how to check whether they actually came up.

[KnVerey]

I've now seen StatefulSet, DaemonSet and Secret 😱 in use by our apps (the latter for a case that should be using a configmap). Some people have also tested HPAs, but I'm not sure anyone is using them for real yet.

[wfarr]

Maybe a default fallback handler that does a fire-and-forget kubectl apply? Most of these resource types probably don't need custom blocking behavior.

[KnVerey]

Maybe a default fallback handler that does a fire-and-forget kubectl apply?

That's exactly what already happens (and it logs a warning that it did so). 😄

[karanthukral]

Daemon Sets also use ownerReferences and revision to match with pods. We should be able to replicate the logic currently used by deployments currently

[jpatters]

+1 for HPA support

[dturn]

HPA support has been merged #305.

[KnVerey]

With HPA in, I think we can actually close this. I don't see any unsupported resources left that actually report a status, i.e. where supporting them explicitly would actually improve deploy behaviour. For example, there are a bunch of policy objects (LimitRange, PodSecurityPolicy, Role, RoleBinding...) we don't model, but they're typically controller-managed, and we could trivially add them on-demand if others say they do want to use kubernetes-deploy to manage them. Adding resources like those effectively just suppresses the warning.